W3C Approves DOM Level 2

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."

Comments

Cross-browser scripting

[CMU_Nort]

cross-browser DOM scripting should become a thing of the past

Umm, isn't cross-browser DOM scripting what we *want* in the future?

Re:Cross-browser scripting

[techsoldaten]

Depends on what you mean. With a single, unified DOM, there is no need to script for several browsers. Therefore, one would be writing code for the DOM, not a browser.

On the other hand, you really end up with an extra browser for a while, since DOM 2 is not backwards compatible.

M

DOM 2 *is* backwards compatible.

[CMU_Nort]

From the article:
"This means that developers who build applications using DOM Level 2 won't be building products compatible with current DOM browser technology. This could be a problem," he said.

It's backwards compatible, but not *downwards* compatible. Just like Windows 2000 can run old DOS programs, but you can't run Win2K programs on DOS.

Wimps!

[Anonymous Coward]

Level 2? Man, I've gotten all the way to the top level of DOOM! The W3C must really suck at first-person shooters or something.

Incorporation into Browsers

[cbv]

The payoff for Web developers, once this recommendation has been incorporated into browsers [...]

... 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:Incorporation into Browsers

[Tumbleweed]

Preach it, brother!

I just got done making an XHTML 1.0/CSS2-based site, which validated perfectly on both XHTML and CSS validators. The site worked perfectly in IE/Win, and when I went to make sure it worked in Mozilla, guess what - no workie! Geez. And here I thought if I had it working in IE, it'd for sure work in Gecko-based browsers.

I'm going back to HTML 4.01 transitional - I can make that shit work immediately, and it works in every browser down to Navigator v2. Yeesh.

Re:Incorporation into Browsers

[Nicopa]

Mozilla already supports almost all of this (if not all). Check the DOM support in Mozilla.

Re:Incorporation into Browsers

[ttfkam]

And there are quite a few Unix variants that don't have 100% support for POSIX either. This doesn't mean that a working subset isn't widely available and in common use.

Same thing goes for DOM2. Does any browser support all of that spec? No. Do Opera, Mozilla, IE, Konqueror, etc. support most of the common DOM 2 idioms? Yes.

With regard to CSS 2 support, yes, there is a great variability in support. But every browser in common desktop use supports

position: absolute;

and that's in the CSS 2 spec. I use that all of the time. 100% support is nice, but lacking that, 75% will work in a pinch. 75% isn't great, but it's a damn sight better than 0% standards support.

Standards?

[sabNetwork]

I don't mean to troll, but who cares about standards when Microsoft doesn't care about standards? We can't push standards on WinIE.

Throwing the baby out with the bathwater

[ttfkam]

The validators just check that you use the spec, not that you're using the spec correctly.

For example:

while(hasmore = 1){
do_stuff();
has_more = 0;
}

Technically correct and it compiles, but it doesn't do what you would necessarily want it to do. Testing against IE is most definitely not testing against a W3C standard for rendering. IE has its share of bugs too -- sometimes bugs that only show up when viewed in another possibly more standards-compliant browser.

And why dump XHTML (I'm assuming "strict") for HTML 4.01 transitional? They are basically the same thing only XHTML transitional is well-formed XML. Since you already went through the trouble of making the site well-formed, why dump it for HTML? That's like saving up money for a BMW, not ending up with enough money, and choosing a used Ford Pinto. What about the middle ground?

Re:Throwing the baby out with the bathwater

[Tumbleweed]

Sorry, I misstated my problems. They're with CSS, not with XHTML. But if you go with strict XHTML, you really shouldn't be doing placement with tables, etc., as is common with HTML-based sites.

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

[chrisv]

Sorry, I misstated my problems. They're with CSS, not with XHTML. But if you go with strict XHTML, you really shouldn't be doing placement with tables, etc., as is common with HTML-based sites.

All true.

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.

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...), 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.

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_.

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:

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd ">
<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:

#LeftColumn { position: absolute; left: 0; width: 32%; margin: 0; padding: 0; }
#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:

<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.

DOM Level 2 HTML

[ttfkam]

...is not the same as DOM Level 2. DOM Level 2 (core, views, events, style, and traversal & range) became a recommendation two years ago.

This is the DOM Level 2 spec as applied to HTML and XHTML.

From the DOM Level 2 HTML recommendation:

This section extends the DOM Level 2 Core API [DOM Level 2 Core] to describe objects and methods specific to HTML documents [HTML 4.01], and XHTML documents [XHTML 1.0]. In general, the functionality needed to manipulate hierarchical document structures, elements, and attributes will be found in the core section; functionality that depends on the specific elements defined in HTML will be found in this section.

that's great

[Kanasta]

instead of having one case for each browser that exists, we first have to check which version were using and then have one case for each browser that exists

it's no longer about waiting for everybody to support the standard, now it's about waiting for everybody to drop support for the old standard, which takes much longer

Re:Only standards are HTML 2.0, 3.0 and 3.2

[Nicopa]

Evidently your knwowledge of these things is pretty limited.

A web page in HTML4 and CSS can be much lighter than one coded in HTML 3.2. The reason for that is that using tables and the font tag is *very* verbose. With CSS you can replace several kB's of <font> along all your site with just a:

.brochure {
font-family: sans-serif;
font-size: larger; }

Then every <div class=brochure> would have these styling attributes. Suppose you want to make the heading in a brochure red:

<div class=brochure><h2>Buy this!</h2> ....

You don't even need to modify your HTML! You just add to the CSS (shared by all your site):

.title h1 {
color: red;
}

That should be read as "h1 inside .title".

As you see, HTML and CSS makes web pages smaller, and more maintainable.