Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
The Internet

W3C Approves DOM Level 2 29

Posted by timothy from the next-is-the-decon-level dept.
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."
This discussion has been archived. No new comments can be posted.

W3C Approves DOM Level 2 More

W3C Approves DOM Level 2

Comments Filter:

  • Cross-browser scripting (Score:3, Insightful)

    by CMU_Nort ( 73700 ) on Friday January 10, 2003 @03:48PM (#5058077) Homepage
    cross-browser DOM scripting should become a thing of the past

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

    • 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

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

        "...for a while", yeah right. I've got some swamp land you might wanna buy from me...

  • DOM 2 *is* backwards compatible. (Score:4, Insightful)

    by CMU_Nort ( 73700 ) on Friday January 10, 2003 @03:53PM (#5058130) Homepage
    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! (Score:4, Funny)

    by Anonymous Coward on Friday January 10, 2003 @03:58PM (#5058196)
    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 (Score:4, Interesting)

    by cbv ( 221379 ) on Friday January 10, 2003 @04:12PM (#5058337) Homepage
    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.

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

      • Throwing the baby out with the bathwater (Score:4, Insightful)

        by ttfkam ( 37064 ) on Friday January 10, 2003 @06:44PM (#5059553) Homepage Journal
        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?
        • 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_.

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

            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.

    • Mozilla already supports almost all of this (if not all). Check the DOM support in Mozilla [mozilla.org].
    • 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.
    • But much k3wl3r to be at the cutting edge. Why disobey an old standard when you can disobey a new one?
  • I'll bet it'll be no time until microsoft adds something to the specs that only IE supports. Then They'll convince many lusers to use it and those of us that don't use IE will get screwed again. You guys remember Java Script, and HTML right?

    I wonder, what will it take to convince microsoft that they need to follow the standards like every one else?

    -Code
    • What are you talking about? Let's not forget about Netscape and "Layers" right.

      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?
    • I'd love to side with you on this one, but Netscape is the one who started with this "enhancing" (aka screwing over) of standard HTML. As far as JavaScript goes, that yet is another Netscape "inovation". http://gamersdot.org/compare.html

  • Standards? (Score:2, Insightful)

    by sabNetwork ( 416076 )
    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.

    • I'm not pro-ms, but it's not as simple as that. MS has many apps, departments and policies. As for IE meeting standards, the Windows versions are still getting there, but are pretty good, but they do have some bugs, shortcomings in HTML, CSS, and especially DOM. But some credit must go to the Mac programmers at MS who built one of the most standard compliant versions of IE (5.5).

      From what I can gauge, the adherence to standards in MS, or any large company often has a lot more to do with departmental leadership, agendas and politics, rather than overall company policy.

      MS deserves credit for making their OS and API supportive of accessibility assistive technologies, but they still have a way to go. As a side note, their main accessibility page [microsoft.com], (and probably all the rest of them) has never validated [w3.org].

      Improved standards compliance for IE6 [microsoft.com] (they seemed to have missed the new support for DTDs in this list).

  • ...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.
  • WC3 Approves Doom 2 Level ...that's what I thought I saw.

  • that's great (Score:3, Informative)

    by Kanasta ( 70274 ) on Saturday January 11, 2003 @04:40AM (#5061631)
    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

  • DOM 2 is like my favorite game ever!

Slashdot Top Deals

"I'm a mean green mother from outer space" -- Audrey II, The Little Shop of Horrors

Close