[development] Drupal 5.0 Theme - v2

[Morbus Iff]

> Pedantry aside, this remains a religious argument.  Terms like "pollute" 
> and "mucking" are subjective, emotional terms that do not directly 
> represent anything of objective value.  Taking your example, it is still 
> possible to query the DOM to find all chapters or contents.

And? Finding the paragraph in a morass of HTML "tag soup" is has always 
been possible (and, in fact, there is a very strong parser called 
TagSoup that does so for dirty HTML) but that has stopped no one from 
heralding CSS as a godsend, the w3 validators as scripture, and clean 
markup as a badge of honor.

[1] http://en.wikipedia.org/wiki/Tag_soup
[2] http://home.ccil.org/~cowan/XML/tagsoup/

Is this a religious argument? Quite probably, but were I to write emails 
like, say, a chatroom, many folks would complain about the lack of 
punctuation, capitalization, readability, and forethought. I don't care 
what is generating my markup - I treat HTML as a representation of my 
data, and if the data is not in a clean form (with no element misused or 
semantically described), then I regard it as wrong.

> And here's the flaw:  It's not your document;
 > it's a transient, internal representation.

I still control the storage of the data and the transformation of that 
data into a version suitable for your client's interpreter -- and, much 
like I may complain to my printing press that this is not PANTONE 
NUTSACK #23, I will complain to my software that there is absolutely no 
reason to have an empty <div> in our comments HTML output (last I 
checked). Your interpreter can interpret it however you'd like; as can 
mine and anyone else's. One of my interpreters is "View Source" and my 
brain. One of my interpreters is  an archiving utility (such like the 
Library of Congress or archive.org). Another is my text editor, which 
doesn't so much "interpret" it as just display it to me verbatim.


> The separation of presentation from content makes perfect sense when the 
> HTML is the data.  And that's the way things were in the early days, or 
> with tools like FrontPage.  But that's not the case for Drupal, where 
> the data model is the SQL, and the presentation layer is the theme.  The 

I disagree. The meaning and use of data, and its storage, are different 
things. You can store a book in a tank of water, but that doesn't make 
the book very usable as data. I can store data in a database, but 
without a transformation of that data (to a CSV for reading via Excel, 
to HTML for reading via a browser, to Docbook for conversion to a 
Framemaker document), it is not entirely useful.

> not necessarily.  Or you get into arguments over whether a decision to 
> visually emphasize a word is a semantic or presentational issue.

I do, actually. I take a very hardline against the use of <b> and 
<strong> vs. <i> and <em>. It drives me nuts that browser wysiwigs, like 
TinyMCE, show a "B" button representing "bold" and then write <strong> 
as an HTML tag. It makes absolutely no sense. How does it know that I 
wanted to semantically emphasize the word vs. merely make it stand out 
more in the presentation layer?

> Rather than going down this rathole, it just makes more sense to deal in 
> real value.  Does using clever HTML/CSS for rounded corners make it 
> harder to maintain the theme?  more so than other CSS cleverness?  Does 
> it create problems for the person looking at it?  Is it harder to do 
> client-side JavaScript because of is?  In other words, focus on the 
> impact on people, and not the impact on theoretical models.

My focus on real value is whether the document is structurally sound and 
easily reusable when I have no way of accessing the data in another way 
(say, making my own SQL queries against your database). I wrote an 
entire book [3] on how to scrape and spider data from the Web, because 
the structure of the data was either a) not transparently usable to me 
or others, or b) because the underlying sites expected (or enforced) 
their data as being useful to nothing but a web browser.

This is folly; I liken HTML+CSS to XML+XSLT. You'd never think of 
putting useless elements in an XML document solely to satisfy the XSLT 
transformation, and I take the exact reasoning on HTML and CSS.

-- 
Morbus Iff ( relax have a happy meal )
Technical: http://www.oreillynet.com/pub/au/779
Culture: http://www.disobey.com/ and http://www.gamegrene.com/
icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus