do the hard work now so that in the future it will be easier for browsers to support something really cool-like 3D hyperlinked video broadcasted in real time over the web. It's hard enough just to do cheesy dynamic html stuff today let alone the really cool stuff

DOM level 1???

You've got to be kidding... DOM level 1 *and* level 2 fail to provide a sound platform to develop web applications.

I guess my only question is what are ya drinking... and where do I get it! hehe! ;-)

This has been discussed before news://news.mozilla.org/7gao0f%24qlu1%40secnews.netscape.com

(1) The current state of DOM support in Gecko is agonizing, frustrating, and deplorable.

(2) Good DOM support is absolutely critical to the survival of the browser.

(3) Backwards compatibility with the old klugy, obsolete, proprietary object model isn't worth a flip.

(4) The project is in deep doodoo if it can't get this fixed in a timely fashion. It's way, way behind.

(5) All of that is clear. The only mystery is why Krock said the decision was a hard one to make.

It's not correct to state the 'Mozilla Dispenses with Old, Proprietary DOM' when the decision is narrowly limited to aspects of <LAYER> and document.layer.

A question for a previous poster, while I'm here --- what about DOM2 is missing in your opinion? (Not saying that you're wrong, and I do know, for instance that accessing computed values of element style is not fully specified (and may not be in DOM2). Just curious.

"(1) The current state of DOM support in Gecko is agonizing, frustrating, and deplorable."

Give them a break... they're doing the best they can with what they got.

"(2) Good DOM support is absolutely critical to the survival of the browser."

DOM? By who's specification???

"(3) Backwards compatibility with the old klugy, obsolete, proprietary object model isn't worth a flip."

Who are you referring to as kludgy? IE or Netscape???

"(5) All of that is clear. The only mystery is why Krock said the decision was a hard one to make."

No mystery at all... Krock has a good understanding of the consequences...

It's not correct to state the 'Mozilla Dispenses with Old, Proprietary DOM' when the decision is narrowly limited to aspects of <LAYER> and document.layer.

A question for a previous poster, while I'm here --- what about DOM2 is missing in your opinion? (Not saying that you're wrong, and I do know, for instance that accessing computed values of element style is not fully specified (and may not be in DOM2). Just curious.

DOM, Level 2 is still a working draft.

Geez... thanks Tekhir, for filling me in!

there are 2 kinds of developers. One camp wants all the latest features and tricks. This camp would exploit the MS XSL, the little .ico thing, the layer tag and every bug is taken advantage of to show off the developer's skill in designing a website. These people also tend to develop for the intranet where there's control over the browser used.

The other camp is annoyed with dealing with the bugs and wants a standard. These people probably never really used CSS/dom stuff because it just doesn't work well under both browsers. These people are sick and tired of netscape or IE only buttons because they try to develop for as many platforms as possible including Netscape 3.

How do we satisfy both camps? Well I think we can satisfy #2 by being tough on the standards issue. And an embeddable browser component means that anyone can make their own standards compliant browser without much fuss (such as the one Bruce is working on) To satify the other camp, I think people from outside mozilla.org will try to implement all the MS and Netscape specific stuff. I also think they'll like what XUL can do for their web apps. Imagine what XUL plus a robust DOM can do for web apps.

Bruce, what anon is saying is that the decision was a no-brainer. There's no point in keeping Netscape's proprietary DOM since it takes resources away from doing better things. I agree with this. On the other hand it's always hard to tell those who are used to Netscapisms that there is a better standards compliant way.

In response to the other anon post, plese read the newsgroup article I linked to and the thread.

In response to "it's a no brainer to drop support for the old", I offer this for consideration:

Because there are so many things out there right now (web sites) that are using the broken / non-compliant code, etc, will dropping support for the broken DOMs cause these sites to stop working? If that's the case, it's something that really needs to be thought about.

From a developer's point of view, it's easy to say, "drop the broken stuff and go with standards", and this, I agree with. However, from a user's standpoint, if this new software I just installed doesn't work with half the sites out there, I'm not going to use it. I don't care about standards, I just want it to work, and if it doesn't work, I won't use the software. The majority of people out there are looking at it from the latter point of view.

I'd like to see a list of sites in the top 100 that use the proprietary DOM. I don't believe that many will be broken by a browser that doesn't support the proprietary version.

This decision will only harm sites that do browser sniffing rather than object detection. I know this has been discussed here recently but sites should realy be using

if (document.layers) { ... }

to test if the browser supports the netscape layers tag. By removing this from Javascript, well written sites will just fall back to version 3.0 code.

.id. -- weblog - http://alchemy.openjava.org/ me - http://www.fdc.co.uk/people/iand/ email - iand@fdc.co.uk | icq - 4423828

ack c'mon anon guys just be members! :)

If people like a new browser that works with 90% of the sites are out there then the site developers who make the other 10% will want to rewrite the websites otherwise people won't come to their sites. So it works both ways in a way

I'm willing to bet that it's more like 90% are not doing things correctly, and 10% are only doing them almost correctly.

arielb,

Yeah... I guess I have to agree... if it comes down to one or the other... W3C is the way to go.

Thanks for shedding the light! :)

-Bruce

Well done, Mozilla team, you've made the right decision! But, to repeat a previous concern, WHAT TOOK YOU SO LONG??!

Honestly, I thought we were going the whole hog on compatability. Going along and not crashing with old proprietary doohickeys, and just ignoring them. And getting a nice standards-based system into place. Right? So why were you even considering sticking to the old proprietary stuff? Time to make a clean break!

Of course, this means we'll all lose the benefit of the <blink> tag .... awww I'll *really* miss that annoying piece of sh**....

-=Yusuf=-

Sorry if this post sounds manic, but there's too little blood in my caffeine system....

Hmm, I didn't see this post on news.mozilla.org - it was posted on secnews - maybe there are still problems with articles showing up on one and not the other. Oh well.

"Of course, this means we'll all lose the benefit of the <blink> tag .... awww I'll *really* miss that annoying piece of sh**...."

Nobody has said anything about abandoning blink. If you look in ua.css, you will see that the blink tag has a declaration. All that needs to be done is hook it up to the layout engine.

Blink will be supported, as it is a CSS1 standard.

When blink is functional, put this line in ua.css

*{text-decoration:blink;}

for an instant headache.

Blink is dead, long live blink

To clarify my above post:

"UAs must recognize the keyword 'blink', but are not required to support the blink effect."

So we cannot be certain it will be supported, but we can still hope.

w3c is the way to go-of course. In many ways the standards are completely ahead of everyone-with a few exceptions of course. In the good old days this wasn't the case. Netscape couldn't rely on the w3c to make it easier for websites to look good so they came out with their own extensions. Netscape 3 really was a killer success and I remember the Netscape Now buttons on many websites. IE then turned more competitive and it's pretty clear that new extensions will only hurt the web instead of helping as they did in the past.

well just modify ua.css then :)

"I'm willing to bet that it's more like 90% are not doing things correctly, and 10% are only doing them almost correctly."

This is probably true in the case of people actually using the extensions. But what about the web sites that don't use *any* extra extensions on their site? I'm sure ~90% of the web is made up of people that don't implement any extra stuff on their site, since they don't know how to write it in the first place (eg. myself).

God knows, I'd *like* to try some DHTML or JavaScript. Unfortunately, I hate coding. ^_^

I think arielb is right when he says people will rewrite their websites if they want hits from users with new browsers. I know I'll be revamping my pages with Composer 5.0 when it appears in the final package... there *is* a standards-complient Composer being fashioned, right? I remember reading about it somewhere...

-Brendan "Beej" Dery

I personally think this sucks!!! Unlike most of you I have invested over a year into learning to use both the IE and Netscape DOMs. Not only that but I have spent hours working on crossbrowser scripts that the average web builder, like yourselves, could port to there sites without needing to know the gory details of DHTML/JavaScript (menu scripts, scrollers, etc...). Now I know this decision won't cause endless errors to be fired at users with NN5, but instead it will cause the script to just won't work. You may think oh well the user won't know what there missing, but that's not true.

For example...

Suppose a fairly new, non computer savvy, web user frequents a site. And when they go to that site it has a nice DHTML menu that the user has grown accustom to using. The user doesn't know or even care how it works they just know that it does!!! Now suppose the user is persuaded some how into upgrading their browser to the NEW, bigger, better version of the same software. However after upgrading they return to their favorite site, but the menu that they are used to using doesn't work!!! Not only are they confused, but mad. They may even be so mad that they say to hell with it and delete the new version in favor of the old one.

It's a fact of nature people are resilient to change!!! I don't know about you, but when I get a NEW version of a software package I not only expect it to support the whole slew of new features (the ones I can get used to in time), but I also expect it to be compatible with the previous version. I mean do you think anyone would upgrade there office suite if the software company that made it suddenly said sorry we've decided not to support our old file format at all because we think the new one is better???

I understand that Netscape (and everyone else) is eager to get a final product with full standards support, but I think ditching the old DOM is a mistake!!! It is just going to cause confusion and anger among people like myself who expect a software package to be backwards compatible. I mean look at how much flack MS got when IE5 broke it's own DOM slightly. Imagine how people are going to react when Netscape doesn't support it's own DOM at all!!!

If a site "breaks" because it uses a non-standard DOM, well, that's the price that an author pays for failing to author by specs.

If the site becomes non-functional because of the non-support of non-standard DOMs, that's even more the author's fault.

"...after upgrading they return to their favorite site, but the menu that they are used to using doesn't work!!!...They may even be so mad that they say to hell with it and delete the new version <browser>in favor of the old one."

It seems more likely to me that they will assume the builders of the site screwed up and not that the browser fell short. My guess is that it's going to mean a lot of e-mails to webmasters saying things like "your menu is broken" and "I can't access your menu, when is it going to be fixed."

I think Anon's main point was that It's going to be a pain in the butt to have to code for four+ browser types (non-DOM IE + NS, IE4+ NS4.x and now Mozilla/NS5+, not counting opera et al) especially after spending so long trying to learn/work around the current impementations. It is frustrating, also , since the initial word from the Moz development team was that gecko would be backwards complient; and complient to both proprietary DOMs (if memory serves me well).

I know why the decision was made, and I do agree with it, but it does mean that *most* web designers will be continueing with the "wait and see" aproach, hoping that the DOMs will finally become more stable/similar; especially now that there are three forks. Luckily, one of them, the proprietary NS model, will fade. I don't realy code for NS2 variations any more (although I still test in it, to see if pages are at least readable), & within a year or so, NS3 will probably go into the sunset too. NS users tend to stay on top of the latest release posible.

"If a site "breaks" because it uses a non-standard DOM, well, that's the price that an author pays for failing to author by specs."

No. Its the Browser manufacturer's fault(s), for not producing complient Browsers. I would love to code to spec, but then I try and test the darned pages.

Well what we're doing is telling web site developers to get ready _now_ so that it won't be a problem in the future. Learn solid CSS1 now. Learn w3c DOM now.

If anyone knows of a website that uses this stuff then inform the webmaster about this (I'm not talking about the big sites-Netscape can do this)

"It seems more likely to me that they will assume the builders of the site screwed up and not that the browser fell short"

Not if they open both the old and new versions sided by side, and could plainly see that the old one works fine but the new one doesn't!!!

With this current line of thinking why have they bothered investing so much time into emulating the previous browsers HTML bugs??? Hell why do they support depreciated tags at all, why not support only HTML 4.0 strict and if people are using old tags say "oh well there just going to have to fix it"??? How do you think the average web page author would feel if NN5 suddenly stoped supporting the <FONT> tag??? Sure you shouldn't use it infavor of CSS, but since old browsers don't support CSS it would force them to make a seperate page for the old and new browser (wouldn't that suck???). Well this is exactly what there doing by not supporting the previous DOM!!! I think not trying to support IE's DOM is understandable, but not supporting their own DOM is a BIG mistake!!!

I just wish my C++/COM skills were up to par, I would fix the code myself.

"but since old browsers don't support CSS it would force them to make a seperate page for the old and new browser (wouldn't that suck???)."

That's kinda what were doing now with DOM anyways. The main focus of Mozilla, since going full bore with the gecko engine, has been to correctly implement the standards in its rendering engine. The other, proprietary stuff was a bonus. But when push comes to shove, and deadlines are looming, it HAS to be the standards that win over proprietary implimentations. This is simply because Mozilla is NOT Netscape, never was, never will be. Sure, it was born of Netscape, and Netscape is basing their next generation browser on Mozilla code, but they are two distinct entities, and will, over time, grow farther and farther apart. It isn't "thier" proprietary DOM, it's a non-standard proprietary DOM. 'sides, according to the news posting, Netscape will put a lot of effort to try and ease us web developers into WC3 DOM code.

and I quote :

6) For those developers who need to continue to support apps on both the Nav4 DOM and the W3C DOM during the transition period or who need to upgrade existing Nav4 DOM apps to Nav5 and the W3C DOM, Netscape will be releasing TechNotes, sample code, and View Source articles showing how to do this.

7) We'll be holding a CodeStock shortly to start educating developers about the W3C DOM.

8) We'll be making educational presentations available for free, 24x7 access as streaming audio presentations at media.netscape.com.

9) We will also be encouraging tool vendors to provide full support for Gecko, Nav5, and W3C standards such as HTML 4.0, CSS1, and DOM1 to ease cross-browser development.

I really don't know why some people are getting upset over this. I do web design myself, and I have PRAYED for a feature-rich, standards-compliant browser like Moz and its eventual offspring.. and I'm an athiest! *_*

So maybe your old code breaks. Big fat deal! I'm not going to dwell on whether it's the authors' fault for using proprietary code, or the browsers' fault for not supporting standards; they're both wrong to some extent, and that's enough. But for the first time in - what, a decade? - we'll be able to write our pages to spec using current tech, and have them work right.

You people who don't want to have to conform to the standards are complaining now, sure. But a year or two from now, when everything "just works" and you never have to rewrite your code again, you'll shut up. And that's a lot better than bitching for the NEXT decade about incompatible proprietary standards.

"But a year or two from now, when everything "just works" and you never have to rewrite your code again"

Is that how long you figure Microsoft will be dragged through the courts?

DHTML is not really that big, most webmasters that dont have a year to learn DOM and JS just use flash fancy graphics and layers, pretty basc things that will be a snap to change, why? becuase it is a pain in the ass to make crossbrowser code. So as I see it, try to start cutting down in the little dhtml tricks, just slowly migrate to better code, or start coding WC3 compliant code and improving it and work on it and when NAV5 is released slip it into your pages. Another option is to have 2 pages, Bells and Whistles and 3.0, people with 4.0 browsers can go to 3.0 people with NAV5 can goto bells and whistles. The point is the web is too chaotic and there should be a make your page standards compliant movement, some reason to wantto make webmasters make their code compliant. Hopefully Nav5 will be under 5 megs so it can be downloaded even by people with 28.8 connections (50-60 min)which cuts out to pretty good time considering IE5 is like 30 MB. So we can all start putting those BEST VIEWED WITH: and DOWNLOAD: $X NOW! buttons all over our pages..

"Mozilla is NOT Netscape, never was, never will be."

How do you figure??? Considering there are only a handfull of non-Netscape employees that contribute code to this project, and Netscape/AOL funding runs the community that hosts it. Without Netscape/AOL this project would be dead!!! Your statement may be true someday, but for now Mozilla is all Netscape.

Really should have those !!! and ??? keys checked. They seem to be sticking.