Trash + DOM = Treasure?

I was browsing the popular links on del.icio.us today and stumbled onto Nifty Corners and (via that page) More Nifty Corners. I have to say that I am incredibly impressed with the scripting, but I fear there is something wrong with this picture.

Lately, there have been some border wars over the CSS :hover pseudo-class and its forays into the behavior layer. Sure, it’s easier to have CSS do the work sometimes, but that doesn’t make it right. Frankly, I agree with the concept that behavior should be separated from presentation, just as presentation should be separated from content (which is why I use JavaScript to open and close the faux-<select> in my <select> Something New series).

I am also a big believer in clean, semantic markup, so I become concerned when anyone is adding superfluous code to the document to force a design issue. I know some might say I live in a glass house, but when I see someone putting code like this

<div id="container">
<b class="rtop">
<b class="r1"></b> <b class="r2"></b>
<b class="r3"></b> <b class="r4"></b>
</b>
<!–content goes here –>
<b class="rbottom">
<b class="r4"></b> <b class="r3"></b>
<b class="r2"></b> <b class="r1"></b>
</b>
</div>
view raw lame.html hosted with ❤ by GitHub

into their document (even if it is via the DOM), I begin to shudder. Maybe it’s the nagging purist in me, but that just seems wrong.

Are we falling into the old patterns again, forcing design issues through hacky markup? Does the use of non-semantic markup (taking a page from Eric, no doubt) make it OK? Does the fact that it’s inserted via the DOM make it any more valid? Where do we draw the line?

I don’t have the answer, but I think we need to have the conversation.

Like it? Share it

Share on LinkedIn

Share on Google Plus

Comments

  1. Okay, let’s have it! :-P

    Actually I think <code class=“css”>:hover</code> should be behaviour if you want to build things more advanced than a simple <code class=“css”>a:hover</code> with it. The support is simply not there to do that using <abbr title=“Cascading Style Sheets”>CSS</abbr> (and there are other downsides, too), but it is by far the easiest and most reliable solution for <code class=“html”>a</code> tags.

    As for inserting non-valid elements into the <abbr title=“Document Object Model”>DOM</abbr>: only as a hack. But the thing is, you need this hack! If you want to insert Flash movies using the <abbr title=“Document Object Model”>DOM</abbr> <code class=“html”>object</code> won’t save you.

    At the end of the day I’d like to be a pragmatist who solves the problems for virtually all browsers, instead of a theorician which gets it to work the right way in but a few.

  2. P.S. Why does the comment preview use paragraphs, and the final result <code class=“html”>br</code>?

  3. OK, I’d agree with being pragmatic (heck I use Geoff Stearns’ FlashObject). I do, however, feel strongly about inserting a ton of “bad” code into a document to get rounded corners. It is not impossible to do with CSS (and have it degrade gracefully) and perfectly valid (and semantic) markup, so why sully the document, even is it is via the DOM. I guess my feeling is that you have to draw the line somewhere and, in the case of getting Flash content to appear, I would argue for using FlashObject if the Flash was a necessary piece of content, but if it was “window dressing” and not necessary for the page to be understandable/usable, I’d let browsers which don’t implement <code class=“html”>object</code> correctly do without.

    As for the <code class=“html”>br</code> <abbr title=“versus”>vs.</abbr> <code class=“html”>p</code>, I’m new to WordPress and I hadn’t noticed that, but I will work on fixing it.

  4. At the risk of remaining off-topic for one more comment, here’s the skinny on the comments:

    Regarding the comment preview issue, the only thing I can figure is that it was part of the comment preview I have been using (ComPreVal), coincidentally co-authored by one Mr. Mark Wubben ;-)

    I didn’t have the time to figure out the error, so I rewrote the form and switched over to one of the live preview plugins (Live Comment Preview) and everything seems to be working pretty well now. That said, I think I may alter the form a little more later to offer a preview fallback for those who do not have JavaScript enabled.

  5. Uhm, yeah, I wrote that, a long time ago. It worked fine for me though ;-)

  6. I think it’s a good thing to hold this discussion indeed. There are still quite a few things that need to be said about it, I think.

    I’ll probably make a post on it soon, because it’s too much to stuff in a comment here. In short, though, I think that some level of purism is great, but it shouldn’t be taken to extremes. Adding markup for design hookups is sometimes inevitable, because CSS still has a fair amount of limitations. See my site right now for an example (current latest post has a bit about it, too)

  7. It is not impossible to do with CSS (and have it degrade gracefully) and perfectly valid (and semantic) markup, so why sully the document, even is it is via the DOM.

    I believe the answer lies in context. Inserting extra elements via the DOM might be a solution to be implemented when you want your content to stay as clean as possible - perhaps if someone else is maintaining the content? I can see where keeping the extra hooks out of it makes sense in that case as it makes it easier for the novice to maintain. Having said that, I wonder if it really makes much difference—I mean, what happens if JS is off? It still degrades gracefully. If CSS is off or not supported, what happens? again, it will still work.

    Perhaps it is an issue of convenience then, for the developer? If the technique I choose has little to no impact on the people viewing the site, and it helps me, then why not?

  8. It’s always up to you to draw the line when you feel that the extra HTML hooks are ok for CSS and other purposes, and when it’s just too much.

    Like with the CSS Zen Garden HTML, it might be useful to easily re-style the web page/site without altering the HTML code.

    However, I personally try to keep my HTML as lean as possible and very rarely add elements through DOM scripting (depends on the purpose, of course). When it comes to interaction, my standpoint is pretty clear in my post you linked to.