You know what bugs me? When people talk about keeping the source clean and then go and do something like this. (No offense to the author, as it was just the first example I found and because obviously a clean source is important.)
The point is, it’s not about the source, it’s about the DOM. When I point my obscure-yet-relevant-standards-conformant tool at your page—be it lynx (bad example, so make that lynx-made-perfect), a screenreader, or even just my Firefox-with-a-userContent.css-file—it should work. And to do that you need a clean DOM the whole way through: start with a clean DOM (clean source), and then when you do your styling and your scripting, keep it clean.
So, after briefly looking at the source of the nifty corners page, what I think you’re speaking out against is the assignment of style (x.style.property=value), rather than providing a class? I guess I’m just looking for exactly what you’re crying out against (you weren’t very specific)
I agree with your premise. Clean markup creates a clean DOM. And clean markup doesn’t end with HTML. It ends with javascript, because you’re adding elements to the DOM. So – in principle – don’t make javascript insert tags into the DOM that you wouldn’t have inserted yourself in the HTML.
Take a look at the example page in Mozilla/Firefox’s DOM Inspector. You’ll see this:
<DIV id="nifty"> <B class="rtop"> <B class="r1"/> <B class="r2"/> <B class="r3"/> <B class="r4"/> </B> <!-- content --> <B class="rbottom"> <B class="r4"/> <B class="r3"/> <B class="r2"/> <B class="r1"/> </B> </DIV>(actually, you won’t see that. You’ll see a DOM tree of that)
That’s the problem I have with this particular example.
Funny you should use Alessandro’s page as an example.
I made some comments about not messing with the source code simply to apply a visual style in relation to some of Alessandro’s recommendations here: http://web-graphics.com/mtarchive/001602.php#chatty004990
You must really hate this JavaScript VectorGraphics library then. :-p
Hi, just a quick answer. In my humble opinion, it’s better to have the html clean instead of a markup mess (such as tables or six nested divs like someone do..) and adding the elements via DOM to get rounded corners. Nifty Corners are at the moment the cleaner way to get rounded corners without extra markup, especially on fluid boxes.
If we can’t use the DOM to add unsemantical, and most of all empty and meaningless elements that doesn’t affect accessibility nor content, then we just have to sit and wait about 5 years for CSS3 to come…
I am with Alessandro on this one. It is a lot cheaper, flexible, and elegant to keep your markup semantically valid and use DOM scripting to hack and “pollute” DOM on the client-side than to generate the invalid markup on the server-side.
… with a disclaimer that this should only be done once you’ve exhausted all other options and these are the only two choices left on the table.
That’s the whole point behind the my TILT thingamajigy.
I’ll take a clean DOM and squared corners, over ‘perdy’ effects and a valid, yet soupy mess. Sometimes it’s worthwhile stepping back and actually evaluating whether you *really* need rounded corners, or is it worth sacrificing a little sexiness for less hassle? Chances are only 30% will notice it, and after the first ‘ooh’ it’s all about the content ..
Oli and Dolphin, I believe one could choose the (best, right, proper) way to use javascript. But if you choose not to add elements in the dom tree, then you should throw out of the window 90% or more of the existing scripts.
One of the reason DOM was invented I believe is to add and play with the page elements leaving the markup intact, semantical and unobtrousive
Think about it. Perhaps reading
this article will help you.
Alessandro, there’s nothing wrong with adding elements to the DOM. If you need to add a paragraph, add a paragraph. If you need to emphasize a piece of text, emphasize that piece of text. The point, though, is that like the original DOM, the new DOM must also be semantic.
Javascript and the DOM weren’t invented solely for “normal” browsers—if I add a paragraph to my page, I want screenreaders to read that paragraph, too. There are so many different devices that read HTML that the only way to make your documents work on all of them is to keep it entirely semantic. The same is true of scripting. If you add a bunch of
<b>elements to a page through script just for the purpose of presentation, a screenreader won’t understand them. Neither will a braille device, or lynx, or anything that does presentation differently than you expected.Now, I’m not against using Javascript to change presentation (I’m going to write about that soon), but I am against changing the semantics of the document to get that presentation.