W3C Approves DOM Level 2 29
techsoldaten writes "Web developers rejoice! W3C announced yesterday the DOM Level 2 specification has become a full recommendation. Article about it on Infoworld. The payoff for Web developers, once this recommendation has been incorporated into browsers, is cross-browser DOM scripting should become a thing of the past and XHTML will be available as a means of handling some data-related tasks within a Web page. One hole in the silver lining: the specification is not backwards compatible with DOM Level 1."
Re:Cross-browser scripting (Score:3, Interesting)
On the other hand, you really end up with an extra browser for a while, since DOM 2 is not backwards compatible.
M
Incorporation into Browsers (Score:4, Interesting)
... which will be like, uhm, dunno, never?
There's not even ONE browser available TODAY, that FULLY implements HTML4 or CSS2 - regardless that their respective developers say otherwise.
Re:Cross-Browser (Score:1, Interesting)
I don't get this holier than thou attitude regarding NS vs IE, Netscape CORPORATION tried to pull as many stunts as MS, but MS just so happened to be better at pulling off hinky manuevers than NS and got the market share.
<snip>You guys remember Java Script, and HTML right?</snip>
What was that supposed to mean?
Re:Throwing the baby out with the bathwater (Score:3, Interesting)
I can make an HTML 4 site using tables for placement that works well (pixel-pefect in most cases) with the vast majority of browsers, more quickly, and with less code, than I can with XHTML/CSS, because you have to specify so many different things via CSS, it takes up a lot of code.
Yes, it makes it harder to update, but most sites don't get updated all that much, anyway. And I can make sites that are fairly easy to update with regular HTML, anyway. Making a clearly-commented HTML template that my customers can then edit later on is a LOT easier than the equivalent with XHTML/CSS. This stuff is just way too complicated, now, and defeats one of the great things about HTML, that it was _easy_.
Re:Throwing the baby out with the bathwater (Score:2, Interesting)
All true.
And I can make an XHTML 1.0 Strict site using CSS for layout that works well (read, also pixel-perfect if I want it to be, which I usually don't want. Read on for why.), that also works in the vast majority of browsers, degrades well, and write it just as fast as you can write your table based layout, and in less code than your table based layout. And less for people to download.
Pixel-perfect layout is a Bad Thing, because you are effectively screwing users in the process. You've made your site unusable for a lot of people with disabilities (since, pixel-perfect usually also entails that you have made it such that fonts, for example, are specified in absolute sizes of one form or another, and the layout itself doesn't flow to the size of the window you're actually working with in the first place). If you're using tables for layout, that's a double-whammy, since not only have you made it so that fonts can't be resized easily, you've also neglected users of non-traditional browsers (screen readers and Lynx, for a few examples) by presenting them with layout that means absolutely nothing to them. Tables are not for layout. They never were.
CSS is for layout. Anyone reasonably versed in web development of any sort can tell you that. And unless you're actively trying to present the same design in Netscape 4 as you do to everyone else (Why trying to make sites render identically in Netscape 4 is a Bad Thing... [alistapart.com]), it doesn't take more code than a table layout that's otherwise identical. The other nice thing about CSS is that it doesn't have to be embedded in the code. Yes, it does make it easier to update, but that's not actually the point. It's something that only has to be downloaded once, not on every page, so you've just made your load time faster after the first hit to the site. And you don't have to use all of the attributes that are provided by CSS. They do have their purposes, but for 90% of the things you'll end up doing, they aren't necessary.
You've just negated yourself there. If HTML is easy, why make it harder to change?
And, making a clearly-commented CSS file isn't that difficult. It's not all that complicated, no more so than, for example, a 3 column layout in pure HTML compared to the same with XHTML and CSS:
3-column.html:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dt
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>3 column layout in XHTML+CSS</title>
<link rel="stylesheet" type="text/css" href="3-column.css"
</head>
<body>
<div id="LeftColumn">
<p>This is the left column of your layout</p>
</div>
<div id="MiddleColumn">
<p>This is the middle column of your layout</p>
</div>
<div id="RightColumn">
<p>This is the right column of your layout</p>
</div>
</body>
</html>
3-column.css:
#MiddleColumn { position: absolute; left: 33%; width: 33%; margin: 0; padding: 0; }
#RightColumn { position: absolute; left: 67%; width: 32%; margin: 0; padding: 0; }
Or, the equivalent in tables: 3-column-tables.html:
<head>
<title>3 column layout in HTML</table>
</head>
<body>
<table width="100%" cellpadding="1" cellspacing="0" border="0">
<tr>
<td width="33%">This is the left column of your layout</td>
<td width="33%">This is the middle column of your layout</td>
<td width="34%">This is the right column of your layout</td>
</tr>
</table>
</body>
</html>
Granted, the XHTML+CSS might look a bit more complex given the simplicity of what I just presented. But when you go to filling it in, and trying to locate which column was which width and change it for some reason or another (say, to make the columns the same width as those here, for example), they'll be almost impossible to find. And with the former, you can also change the ordering of your columns to suit what's best for users who aren't getting the columns, for example.
Either way of doing it is fairly easy, all things considered. Until you have to use one of them in a real-world situation.