See bug 246964. If a page uses document.all without first object-detecting it, we can satisfy the reference with an object that smells like a skunk and quacks like a skunk, so to speak. We could even emulate other IE DOM level 0 quirks, but let's take this one step at a time, with much-appreciated evangelism help. /be

This does just that (with some additonal changes that Brendan's got). This patch doesn't expose anything other than elements by their ID's in document.all atm, there's still some reverse engineering that needs to be done here. The things I know that we still need to address is that IE exposes an array of elements if multiple elements exist with the same ID (geez). And IIRC, it also exposes certain elements by their name, not just ID. Any help on figuring out exectly what IE does here would be greatly appreciated.

ID is supposed to be unique in a given document, so there shouldn't be any need for auto-array'ing. I am to blame for auto-arraying of form elements with the same NAME attribute value, to support radiobuttons, back in Netscape 2 when I created all this crazy DOM level 0 stuff. But auto-arraying of IDs doesn't make sense. Unless there are real-world HTML docs with non-unique ID values among their elements? /be

This makes any use of document.all or such (ygd.all where var ygd = document, or whatever) be detecting if the use is the right-hand side of a variable assignment, an operand of ||, &&, or !, or tested by if or ?:. /be

(In reply to comment #2) > ID is supposed to be unique in a given document, so there shouldn't be any need > for auto-array'ing. I am to blame for auto-arraying of form elements with the > same NAME attribute value, to support radiobuttons, back in Netscape 2 when I > created all this crazy DOM level 0 stuff. > > But auto-arraying of IDs doesn't make sense. Unless there are real-world HTML > docs with non-unique ID values among their elements? I fully agree that there *shouldn't* be a need for this, but that's how IE works, and according to bc's testing of real sites, there is a real need. How big, I don't know. Bob, you got any more data to share here re multiple elements with the same ID, or anything else?

IE Emu might give some insight about what needs to be done: http://webfx.eae.net/dhtml/ieemu/ A major problem I see with this is that most serious DHTML still isn't going to work since most document.all authors don't specify 'px' units when setting positions, etc.

Goal is not to get "most [IE-only] DHTML sites" working. Start with the sites that use document.all for simpler things than what generally falls under "DHTML". Bob, please enlighten us based on your test spidering. /be

Re: Comment #4 From Johnny Stenback Regarding a node list for duplicate ids, I saw it a few times during the nscp techevang days but it is not that common I think. I am still in the process of scanning sites looking for problems with both trunk and patched builds. I haven't completed comparing the results yet but it looks like this will have minimal impact for good or bad on the top sites like yahoo and msn which is to be expected. I have seen a few of the global var for id'd elements, calls to window.attachEvent type errors. I still have some more scans of microsoft.com and some aol related properties like netscape and cnn to run, but I expect similar results there. Re: Comment #5 From Aaron Kaluszka The units only matter in a standards mode page but I expect the majority of the pages this will affect will be in quirks. Re: Comment #6 From Brendan Eich I have rewritten the spider app as a xul app which is working much better in terms of handling sites which attempt to break framesets and can test them more completely now. I have an outstanding issue with sometimes skipping some pages so the coverage hasn't been 100% yet but I think it is ok for now. I also found that I could eliminate the crashers I experienced but that no one else did by compiling non-debug, non-optimized. I have done yahoo and msn with patch and unpatched builds, microsoft with a patched build (was interrupted by a thunderstorm Thu PM) and am going to run an unpatched scan of them next. So far things look good in terms of not breaking content and not crashing but no noticable improvement since they all detect Gecko pretty well. I plan to test urls from TE bugzilla bugs to see the potential for the positive effects on sites which are less likely to code cross browser than the top sites. Older sites or those maintained by the clueless are where I expect to see more of the benefit and potential other properties that could be added. I hope to have more details by Monday or so.

For what it's worth... I'm a web designer and think it's very sad. As far as "real" JavaScript is concerned, I don't mind too much because anything that I don't write myself are scripts I found on the Internet, modified to work with "document.getElementById" exclusively. The issue starts when using JavaScript to work around specific bugs in browsers. I used to do "browser name" sniffing in the past, but that has changed. If Mozilla were to add support for document.all, it would make it very hard (if not impossible) to distinguish it from other browsers. Say, I need to distinguish between Mozilla, Opera and IE (in general), then I would do it like this: (window.opera) (document.all) "else" Where "else" is assumed to be Mozilla and/or "document.getElementById". For more advanced sniffing I may resort to things like (document.fireEvent), (document.doctype) and (window.GeckoActiveXObject), but only after I've limited to "main branch" (Moz/Op/IE) first: (window.opera) ---(document.doctype) (document.all) ---(document.fireEvent) (document.getElementById) ---(window.GeckoActiveXObject) I do want to make this clear though: I design to standards (XHTML 1.0 or 1.1 for current sites) and will only resort to JS for workarounds if they can't be done via CSS hacks. The point of this comment is to say that, if support for document.all were to be added to Mozilla, I will have to resort to "browser name" sniffing again (or at least partially). Other than that, there's also a nasty side effect... Say Mozilla renders something correctly, but Opera and IE don't. Technically, I could do this in CSS as such: div { value for Opera } * html div { value for Internet Explorer } :root div { value for Mozilla } We'll leave aside the possibility that other browsers may support ":root" in the future. The problem with this CSS hack is that ":root" isn't "valid". So, JS is required if one is very strict. Currently, this would be the JS solution: (window.opera) (document.all) Simple. But when Mozilla adds support for (document.all), it will also pick up the "wrong" value that was only intended for Internet Explorer.... I'm really sorry, but I don't see any advantage in supporting (document.all). From my experience, most sites that use it either cater to IE4 with it, or (wrongly) use it to verify that it's MSIE in general (and automatically consider it "ActiveX supported" if needed).

> If Mozilla were to add support for document.all, it would make it very hard > (if not impossible) to distinguish it from other browsers. The _entire point_ of this bug is that the supported would be undetectable. In other words, if (document.all) { ... } ...would _not_ catch Mozilla.

(In reply to comment #9) > The _entire point_ of this bug is that the supported would be undetectable. Sorry. I didn't get that impression. Maybe it's the language used; I'm an HTML coder, not an application coder.

javascript-logs.zip contains the results (minus the CSS errors) for spidering approximately 565 sites 1 level deep which were listed in bugzilla tech evangelism has having problems with document.all. Note that these logs contain the javascript errors which were detected up to either the first exception or the page load event therefore not all errors on each page were logged. Please ignore the errors due to scripting plugins since I failed to copy the xpt files into the dist for the builds. The trunk-javascript.log contains the results of loading over 12,000 pages using an unpatched trunk build from 6/29. The bug248549-javascript.log contains the results of loading over 10,000 pages using brendan's 3rd version of the patch he sent me including the new support for assignents and document.all on the rhs of expressions along with the patch in this bug. The difference in the counts are due (I think) to changes in the pages from the time I started on Friday to this morning when I completed plus some pages which failed to load due to network issues or crashes. The full logs including CSS errors are available if anyone wishes to look at them but they are 30M and 29M uncompressed respectively so I am not including them here. One thing is clear: People write invalid CSS and don't know any better. Basic results are that 430 javascript errors in unique urls due to document.all were eliminated by this patch. Some additional errors due to the sporadic use of document.all[name] instead of document.all[id] were found however the number was relatively small. I did note the use in at least one site (ohmynews.com) of document.all[name] returning a nodelist however I do not think this is a common occurence. There were also a very small number of new errors due to document.all.tags. The next major source of errors appear to be due to MSIE's exposure of id'd and named elements using global references which I do not think it is possible to fix. As far as I can tell, I did not see any unique crashes due to this patch. I think this passes the 80/20 test pretty well. Note that layer errors are at least an order of magnitude less common than document.all errors.

Thanks, Bob! > One thing is clear: People write invalid CSS and don't know any better. Cc'ing dbaron. > The next major source of errors appear to be due to MSIE's exposure of id'd > and named elements using global references which I do not think it is possible > to fix. If these references are always preceded, or often enough preceded, by document.all non-detecting uses, then we can decide, upon a non-detecting document.all use, to reflect ids into the window global. Would that win? Maybe jst can whip up a patch. /be

trying to reflect the ids into the window object would probably help a little but I doubt it would end up helping that much. some examples: http://www.mediasetonline.com/resources/js/italia1/i1pubblicita.js http://webfx.eae.net/tools/taskplayer/index.html don't detect document.all at all http://webfx.eae.net/dhtml/statusbar/statusbar.html would benefit a little until it started running into things link elm.children and elm.style.filter so the net result would still be a borked page.

Ok, maybe the thing to do (separate bug, not here) for window.id hacks is to resolve them when id is defined in the document, and no such window property exists. jst, want to spin off a bug on that, if one is not already on file? /be

I am going to see if I can get some testing done on IBM products with the patch (the testing person is on vacation atm) and see if it breaks anything. What about IE's window.elementName - that is pretty common as well.

(In reply to comment #3) > This makes any use of document.all or such (ygd.all where var ygd = document, > or whatever) be detecting if the use is the right-hand side of a variable > assignment, an operand of ||, &&, or !, or tested by if or ?:. if we consider the assignment as a type of object detection, some assignment that does not involve detection may be sacrificed. Is there anyway to identify this kind of situation?

Robin: distinguishing detection via a variable that loaded the document.all reference from undetected use of that variable requires data-flow analysis in JS, something not worth doing just for this compatibility hack, and not worth it for other reasons (optimization) for most scripts. /be

Depending on how this goes, we may want it in Firefox 1.0. /be

I just checked in attachment 152157 [details] [diff] [review]. /be

(In reply to comment #18) > Depending on how this goes, we may want it in Firefox 1.0. This would just be great!

This cleans stuff up a bit, and also adds support for document.all.tags (tags.foo, tags["foo"], tags("foo")) which maps to document.getElementsByTagName().

Sorry, I haven't take a look at the patch as I would be unable to understand it, but reading the comments it seems that each use of document.all is evaluated to see if it is a detection of capabilities or a direct use. As comment 12 points I think that it would be good to have a IE-compat mode that just needs to be triggered once per document and from then on the hacks (this one and others that might get also added) could go on automagically. Now a request: Would it be possible to add a warning to the JS each time document.all is supported so there's a hint for those who care about what's going on? With regards to the support for id'd and named elements using global references, even if no previous document.all has triggered the IE-compat mode, maybe it could be guessed based on the use of an undeclared variable and that variable just happens to match a document.getElementById(variable) element. In general, whenever a "element has no properties" happens it seems a target to try to guess it (although it means that web developers will forget again about document.getElementById and friend) Thank you.

(In reply to comment #22) > Now a request: > Would it be possible to add a warning to the JS each time document.all is > supported so there's a hint for those who care about what's going on? Yes, I was going to do that but forgot in my haste to get the patch up in the bug... I'll try to get that included...

Comment on attachment 153433 [details] [diff] [review] Support document.all.tags too! sr=me, just go on a JS_Lookup*Property hunt and use JS_Has*Property -- and do the warning thing, ok? The suggestion from Alfonso to resolve window properties that look doomed to failure but match a document element id is good -- separate bug for that (on file yet?). /be

jst: What about document.elementName?

(In reply to comment #25) > jst: What about document.elementName? What about it? Or you mean window.elementName? Mozilla already exposes certain elements by their name as properties of the document object.

Now, or never. Looks like a large set of patches. Has to be landed by next week or will miss the train.

I'll review this tomorrow.

Comment on attachment 153679 [details] [diff] [review] Same as above with code to write message to console first time (per page) document.all is used. Caillon says r=caillon over irc.

MSDN spec on .all: http://msdn.microsoft.com/workshop/author/dhtml/reference/collections/all.asp

Fixed on trunk and aviary branch.

Does this happen in both quirks and standards/nearly-standards modes? If so, was having it work only in quirks mode considered? Gerv

Quirks mode is for things that, if implemented, break the standards, not for extensions. What would the advantage of putting it only in quirks mode be?

(In reply to comment #34) > Quirks mode is for things that, if implemented, break the standards, not for > extensions. What would the advantage of putting it only in quirks mode be? The advantage would be to reinforce the idea that this is non-standard, and that there is a standard way of doing the same thing (not that I totally agree with such a view).

I am in favor of this support, but I think the user should be notified when it is invoked. In my opinion, a site written with broken DOM is as bad as a site with popups, and therefore the notification should be similar. The first time document.all support is invoked, let the user know - with a message along these lines: "You are now entering a site that is written incorrectly. Mozilla [Firefox] will attempt to display it anyway. You will be notified when you enter these sites by this icon [image on left] at the bottom-left corner". This message should appear once, and afterwards, an icon will be displayed in the style that the popup-block notification icon is. I have no better idea for this icon than a bug.

Ohad, I'm all in favor for this IE-DOM warning (in fact, I suggested something similar in Bug 154589, comment 112), but it's probably better to open a new bug for it. Prog.

(In reply to comment #36) > I am in favor of this support, but I think the user should be notified when it > is invoked. I strongly disagree. If my mother were to be using Mozilla, she would not care about a website using Microsoft DOM. We're making end-user products here and we can't be throwing confusing dialogs at them to scare them away. The warning in the JS console seems appropriate to me. Anyone interested in seeing the problems with a site's JS will look there.

Hixie: it used to be our approximate policy, as I understood it, that we would implement extensions which had no standards-based equivalent of equal simplicity, such as innerHTML or even <marquee>, under a "lesser of two evils" sort of rule, but didn't implement any extensions which had a standards-based equivalent. I'm suggesting that instead of throwing that principle away completely, we just modify that last part to say "we do implement some extensions with a standards-based equivalent, but only in quirks mode". This would emphasise that they are standards-based ways of doing it, which are available in standards mode. Of course, the recent WHAT-WG business does put a different perspective on these things compared to how we've thought about them historically. Will WHAT-WG be including a spec for document.all in its proposals? Gerv

Comment 36 and comment 37 miss the vital distinction between the end-user, who has no ownership or influence on the web site in general, and the web-site content author, who may be years gone, with no replacement left behind. It´s absurd to annoy the former with messages that should target (ideally via time travel to the past) the latter. /be

The message "Non-standard document.all property was used. Use W3C standard document.getElementById() instead." could be much more useful if it were a normal Warning with with Source and Line info.

Gerv: I am not aware of any such policy. By such a policy we would not have implemented innerHTML nor <marquee>, nor almost any other extension. No, the policy has always been that we implement standards extensions if they are useful or if significant numbers of pages depend on them. Quirks (which are unrelated to standards extensions) are similar: we implement violations of the correct behaviour, in quirks mode only, if pages depend on them. > Will WHAT-WG be including a spec for document.all in its proposals? That has been proposed. However, I think "if (document.all)" type tests -- which are what caused this bug to have to go through hoops to implement d.a -- are likely to make it hard to specify d.a in a backwards-compatible way.

> the policy has always been that we implement standards extensions if they are > useful or if significant numbers of pages depend on them. I don't believe there has been no change in policy. If there hasn't, why haven't we implemented this before? There have been several patches for it around, but jst or others have turned them down, even when the magic "document.all returns false" behaviour was proposed. (Bug 154589, comment 16 is one example; I'd be interested in jst's comments on how his personal view has changed.) The patch attached to this bug is not complex - I find it hard to believe we've just been waiting for four years for someone to do the work. Are you sure you're not thinking of the Opera policy? ;-) If the policy is as you say, is there going to be any limit to our attempt to implement the IE DOM, apart from engineering resource? And how do we avoid some of the factors listed here: http://www.mozilla.org.uk/docs/proprietary-features-bad.html from coming into play? (That document is slightly out of date, and a couple of comments don't apply because of the implementation strategy used, but most of its points are still valid.) Gerv

> I don't believe there has been no change in policy. If there hasn't, why > haven't we implemented this before? Because we were naively hoping we wouldn't have to. However, it recently became clear that a bit barrier to Gecko's adoption was problems on pages that were not going to change, and that were using document.all without checking for it first. > Are you sure you're not thinking of the Opera policy? ;-) Yes, Opera's policy is radically different from what I described above. > If the policy is as you say, is there going to be any limit to our attempt to > implement the IE DOM, apart from engineering resource? Depends on how much is needed. For example we do innerHTML, but we don't do outerHTML -- the former is much more widely used than the latter. > And how do we avoid some of the factors listed here: > http://www.mozilla.org.uk/docs/proprietary-features-bad.html > from coming into play? Points 1 and 2 are no longer relevant given, as you say, the impl strategy. Points 3 and 4 are avoided by only doing the critical bits, and by simply saying "no" to the rest. Point 5 is avoided by not implementing the IE event model. Point 6: We changed strategy precisely because our evangelisation efforts were not effective enough, so the good should outweigh the bad (if any) here. Point 7 is silly given the extent of our implementation of Microsoftisms already. Point 8 is also moot given the status of the market, and we are working to avoid this with WHATWG. Point 9 is irrelevant given IE's development status (or rather, lack thereof). Point 10 misses the fact that at least one of those browsers is way ahead of Mozilla in implementing such features. Point 11 assumes that we can't say "no", which is clearly not the case given that we are only implementing what is required, just as we always have been. Point 12 is frankly out of touch with reality (which is not to belittle the efforts of these teams, it is simply that these teams are small and the number of sites than need changing is huge). So I think we have that covered.

> However, it recently became clear that a bit barrier to Gecko's adoption was > problems on pages that were not going to change, and that were using > document.all without checking for it first. Could you give some examples? Reading this bug, all I see are statements like "this will have minimal impact for good or bad on the top sites like yahoo and msn which is to be expected" (bc), and no specific URLs. Is there a tech evangelism keyword I should search for? > Depends on how much is needed. That's not a clarification - you've just moved all uncertainty into the definition of "needed". :-) > Points 3 and 4 are avoided by only doing the critical bits, and by simply > saying "no" to the rest. On what grounds? Tech Evangelist: "Please upgrade your page." Page Author: "Why? You've implemented some of the IE stuff; just implement some more." Tech Evangelist: ? (This is point 11 again.) > Point 12 is frankly out of touch with reality Well, it's making the same point as bc's statement quoted above - almost all the top sites work fine. Anyway, I think this still comes down to "What is the policy, how are these decisions made, and where will this all end?" I don't think it's unreasonable for mozilla.org to explain this. Gerv

Those are all policy questions, so I'll let staff/drivers/module owners reply.

(document.all != undefined) returns true and typeof document.all returns function, is this intentional?

Gerv, policy requires nice judgment about particular facts on the ground, not brain-off application of _a priori_ thinking. I never agreed to anything in the document at http://www.mozilla.org.uk/docs/proprietary-features-bad.html. I did come up with the idea implemented here and in bug 246964 to emulate document.all without running into the first objection from that document. See bc's comment 11, specifically: "Basic results are that 430 javascript errors in unique urls due to document.all were eliminated by this patch", for the data he's collected suggesting that this patch does only good, not harm. The idea that by emulating undetected document.all, we will induce lazy or otherwise unmotivated web site content authors to write IE-only code is pretty silly. Web content authors these days do not generally turn away 10% (by use) minority browser market share. It would be economically foolish to turn away even a few percent, given the small incremental cost (today, not years ago) of using standards that work in IE and the minority-share browsers. The fact we face is that some part of the web content already written around the world (much of it long ago, not today, where there is no one around to rewrite it) assumes IE only. If such content has only shallow dependencies on IE's non-standard DOM (document.all, element.innerHTML, offsetTop, e.g.), then with this patch, we win. Without it, we lose, and we have no realistic hope of winning in any realistic time frame. /be

> (document.all != undefined) returns true and typeof document.all returns > function, is this intentional? Yes. Both are considered to be undetected uses of document.all. Neither is what people actually write in order to object-detect document.all. /be

(In reply to comment #49) > Yes. Both are considered to be undetected uses of document.all. Neither is > what people actually write in order to object-detect document.all. I use the typeof method to avoid the "reference to undefined property" warning myself but I doubt I'm representative... Minor nit: when document.all.tags is used, the message still reads "Use W3C standard document.getElementById() instead.". document.getElementsByTagName() would be more appropiate.

> Gerv, policy requires nice judgment about particular facts on the ground, not > brain-off application of _a priori_ thinking. Let me attempt to rephrase the question to make it more answerable. Or perhaps you can help me by answering the right question even if I ask the wrong one. I'm just trying to get some insight into the thinking that went into this decision, and some idea of how future decisions may be made. - When making decisions like this in the future, will we continue to take any account at all of what is standardised and what isn't, or are we simply implementing what works? - Are you concerned that this will make tech evangelism harder, because sites we are trying to evangelise will just tell us to implement the part of the IE DOM that they happen to be using? > I never agreed to anything in the > document at http://www.mozilla.org.uk/docs/proprietary-features-bad.html. I've never asserted that anyone apart from myself agreed to that document, or that it represented any sort of policy. > See bc's comment 11, specifically: "Basic results are that 430 javascript > errors in unique urls due to document.all were eliminated by this patch", for > the data he's collected suggesting that this patch does only good, not harm. If you are measuring good and harm solely on how many web pages work or don't, then indeed, the patch does only good. Is he able to tell how many pages went from a non-working to a working state as a result? > Web content authors these days do not generally turn away 10% (by use) > minority browser market share. I may have misunderstood, but are you saying that very few people these days write IE-only sites? Gerv

Erik: that strict warning has been a false alarm for too long. I'm inclined to fix things so it doesn't fire for DETECTING uses. Gerv: you seem to think policy can inform decisions more than I do. If it were that simple, we could write policy-AI and retire. > - When making decisions like this in the future, will we continue to take any > account at all of what is standardised and what isn't, or are we simply > implementing what works? What works is often a de-facto standard. Consider the DOM Level 0, which the w3c never standardized, but which all browsers must implement. It is far from trivial to reverse-engineer. Standards matter, to the extent that they are actually implemented well and widely. That applies to de-facto standards too. For a non-web example, consider the SQL situation. > - Are you concerned that this will make tech evangelism harder, because sites > we are trying to evangelise will just tell us to implement the part of the IE > DOM that they happen to be using? No, and I already said that's silly, so why are you repeating it? > > I never agreed to anything in the > > document at http://www.mozilla.org.uk/docs/proprietary-features-bad.html. > > I've never asserted that anyone apart from myself agreed to that document, or > that it represented any sort of policy. Ok, so I'm not sure why you brought it up. The first two points do not apply to the conditional document.all support we've added. > > See bc's comment 11, specifically: "Basic results are that 430 javascript > > errors in unique urls due to document.all were eliminated by this patch", > > for the data he's collected suggesting that this patch does only good, not > > harm. > > If you are measuring good and harm solely on how many web pages work or don't, > then indeed, the patch does only good. > > Is he able to tell how many pages went from a non-working to a working state > as a result? See above, where I specifically quoted his 430 figure. > > Web content authors these days do not generally turn away 10% (by use) > > minority browser market share. > > I may have misunderstood, but are you saying that very few people these days > write IE-only sites? I'm saying that anyone who does is not competitive. There are fewer offenders now than in the dark days of Netscape 6 -- but the old offenses hang around too often, without owners. Bob may have data here. I'm tired of citing your comments by hand. Do you want to go to a newsgroup? /be

(In reply to comment #52) > Erik: that strict warning has been a false alarm for too long. I'm inclined to > fix things so it doesn't fire for DETECTING uses. Please do. I was just caught making the recommendation of using typeof to reduce the "reference to undefined property" warnings myself. I have always hated that warning. > > Is he able to tell how many pages went from a non-working to a working state > > as a result? > > See above, where I specifically quoted his 430 figure. > I am currently in the process of scanning the homepages of the same 500+ sites to look for changes. I am not doing the 1 click deep scan since that would take me _days_ instead of hours. The 430 figure represents about 3.5% of the loaded URLs I tested. This is somewhat skewed since some of the sites contain many links each of which generates an error, but I expect to find the "Non-standard..." message in about 2% of the sites when I am finished. I also intend to review the outstanding evangelism bugs and mark any that are resolved by this change as WFM later today. I will report the results when I am finished.

>> are you saying that very few people these days write IE-only sites? > I'm saying that anyone who does is not competitive. A curious statement. As a web developer, I’ve been very intrigued by this development. Im very tempted to simplify my code by eliminating the .getElementById forks and just use .layer and .all. This will definitely save me coding, debugging and testing time.

The introduction of undetected document.all can be expected to help in limited circumstances where script uses id based element references obtained via document.all, simple use of element.style and 1. no browser detection at all. 2. detection of document.layers first then assuming document.all. 3. detection of document.all [!=|==] null, or typeof(document.all) [!=|==] 'undefined'. Test results (see the logs for the actual details.) 497 begun - 6 Network timeouts -64 failed due to DNS/Network === 427 completed Summary Non-standard message occured 18 times for 4.2% Definitely Fixed 2 for about .5% Most occurences of the Non-standard message occur in pages where they already do NN4/IE4 type detections, but failed to properly object detect everywhere on the page. This limits the effectiveness. On other pages even with document.all the page fails to varying degrees due to global vars, document.all[elementname], element.parentElement, element.children, exposure of attributes as properties on elements, window.event related issues, etc. (document.all == null) == false and (document.all != null) == true appear to have a greater affect than I would like although the occurence is much less than normal tests. However it does fix MM_showHideLayers() v2.0, but still is bothersome I think. Details http://timeoutny.com/ fixed. tests document.layers first, else document.all http://saab.com.tw/ not fixed. uses document.all, document.layers testing primarily http://pandasoftware.com/ partial fix, global vars, window.events, behaviors etc http://ori.dhhs.gov/ not fixed, server side detection, we get layer tags, also note that MM_showHideLayers version 2 is fixed but it is due to the test document.all != null function MM_showHideLayers() { //v2.0 uses document.all != null which is true http://orange.co.il/ not fixed, global vars http://ohmynews.com/ not fixed, global vars, uses multiple ids and document.all[id] as a nodelist http://www.jockey.com/ fixed but only uses image rollovers http://janusys.com/janus/library/ not fixed, children, elm.attachEvent, window.event, event.srcElement, exposes attributes as properties http://imbc.com/ not fixed, uses if (document.all) else {layers} http://iafdb.travel.state.gov/ not fixed, uses document.all[formelementname] http://haaretzdaily.com/ not fixed, primarily nn4/ie4. the fix has no real effect http://games.jolt.co.uk/ partial fix, document.all.namedItem http://emhart-vic.com/ not fixed, uses DHTML library which really only does NN4/IE4 detection http://egged.co.il/ not fixed, elm.parentElement, globalvars, attributes as properties http://dramaten.se/ no real effect, mostly coded using cross browser and w3 anyway dom.com not fixed due to use of elm.parentElement http://crowncolonyproperties.com/ partly fixed, site uses innerText, table data controls, etc, but we are not blocked but this is due to document.all != null http://coe.int/ fixed although menus are awkward

From reading some comments here, I see that this implementation solely focuses on benefitting the end-user (doubtfully) and making life easy for site maintainers (the care shown is touching). It completely disregards how it will affect the web developers and the Web itself in general. The Web lives by one rule only: "If it works — it must be right". This bug basically gives green light to document.all. This is what it does for web developers and for the Web in general. And with all focus on end-users I don't see the discussion about this, which I find disturbing. There is a new generation of web developers emerging, who want to learn. There is a current generation becoming aware of alternative browsers and W3C standards. These people learn primarely on Mozilla. Mostly, learning still remains via seeing source of other sites and trying it. DOM is the last thing people usually learn after (X)HTML and CSS. These people know that if it doesn't work in Mozilla - the browser with best standards support - then it must be wrong, and they come and ask what's the right way to do it. This bug changes this. People will try code, see it working, think it's right, and continue using it, creating more and more pages unknowingly, and still being proud that Mozilla helped them to design a fully (X)HTML and CSS compliant site. So far Mozilla has been a solution. Now it is turning into a part of the problem. So instead of arguments that we should behave like dominating browser, I would like to hear some real analysis of the benefits and detriments of why we should give green light to use of this interface. * Impact on end-users. * Impact on web developers that are creating new code. * Impact on web maintainers that maintain existing code. * Impact on Web in general. * Impact on Mozilla. Here is my take on things: Great benefits for users? Please! I am sure out of all web content, there are less than 1% of sites that rely on DHTML so heavily, that without it they would be unusable. Problems of non-working document.all is laughable compared to non-working ActiveX, when it comes to end-user experience. In fact, in many years I am yet to come across a general-use site that would prompt me to use IE to make it accessible because of lack of document.all support (I don't count (ignorant) scripting skill show-offs and coding experiments as general-use sites). Comment #54 clearly shows the impact on developers of new code - less typing. Also above I described the big impact on learning developers. This in turn affects Web in general and it's future. Existing code maintainers? These are the only people that I see really benefiting from this bug implementation. It allows them to be lazy, and not spend millions of prescious dollars on improving their slightly broken sites. How is it benefitial to the Web in general? I would like to hear full technical (scientific if you like) justification to giving green light to this interface. Why and how document.all is good? Why should developers use it instead of using a value returned by a function. Impact on Mozilla? Due to very little impact on end-users, this will not affect installbase of Mozilla. But If a site instead of spending millions on fixing code, offered just 1 million to Mozilla Foundation to make a dirty hack to the browser - I would understand the sudden eagerness to implement it despite previous open opposition. In this case benefits outweight everything else for Mozilla. But if this is not the case, we should focus on the previous points. Who are we trying to please here?

I completely disagree with the purpose served by this bug and the chosen means to support more IE-specific websites. For hundreds of reasons, I think Mozilla.org is going in the wrong direction here and is giving the wrong message at large, including to web authors of IE-specific pages. If mozilla.org really needed this bug to be fixed, then mozilla.org should at least have given as much efforts, energy into evangelizing web authors about proper+compliant+interoperable way to code a page. I can find dozens of documentation and/or evangelization bugs which would have made a lot more sense to fix. I see no balance here. The whole bug was opened and then fixed in 20 days without a broad, public, open discussion on this. If mozilla browsers are going to support and to compensate for IE-specific code in webpages, absence of object support, etc.., then what's the purpose of writing documentation and spending time into evangelization? What's the purpose of reading and following W3C recommendations? From a very practical and pragmatic perspective, there is no point. The more a browser cater for technically invalid code, incorrect practices, non-standard DOM methods, the less web authors feel, see the need to upgrade their skills (or HTML editing software) and update their code according to W3C standards/recs. getElementById was first supported by MSIE 5.01 more than 5 years ago; so, from that point, it becomes furthermore irrelevant to use document.all the more users were/are upgrading to MSIE 5+... and we know that less than 1% of all users out there use IE 4 or NS 4. What's the use of notifying users (or web authors, does not matter really) that "Non-standard document.all property was used. Use W3C standard document.getElementById() instead." if the mozilla browser is going to support document.all anyway?? This does not make any sense. You're recommending a practice that no longer brings any kind of benefit; in fact, the IE-specific way now brings the benefit of code size reduction. Where's the incentive to make a page code more interoperable across browsers and web-aware devices by making it compliant in the first place then? When should we expect Composer, NVu, DOM inspector, Venkman debugger to support document.all? By fixing this bug, mozilla.org has open the door to an endless list of more IE-specific code that currently breaks in mozilla browsers. When should we expect mozilla browsers to support missing unit for css declarations the way IE supports it in backward-compatible mode? to support IE box model in backward-compatible mode? improper nesting rendered the way MSIE renders in specific cases? alt attribute rendered the way IE does it? All these are rendered in a certain way in IE browsers and are not rendered the same in Mozilla browsers. So why stop at document.all? I'm sorry. I'm very disappointed by this bug.

I am not going to add onto what the last two people that placed comments, but I am in complete agreement with comment 57. I am disappointed in the way that this bug was fasttracked through. In my opinion this is hardly a Mozilla bug at all. This change in policy has severly shaken my belief in the Mozilla Foundation. I call on all like-minded people to speak out against this and any other moves like this.

> A curious statement. As a web developer, I’ve been very intrigued by this > development. Im very tempted to simplify my code by eliminating the > .getElementById forks and just use .layer and .all. This will definitely save > me coding, debugging and testing time. Feel free, but your code won't work in any Mozilla milestone shipped so far, or in any Netscape or Red Hat distribution of Mozilla code, or in Safari. Still believe you will be competitive with alternative sites that use the standards that work in all browsers? It's absurd to claim that document.all works in more currently maintained browsers than document.getElementById does -- the latter works in IE as well as in Mozilla, Netscape 7.x, Safari, and Opera. Comment 56 cites comment 54 as evidence for an unbelievable trend to use document.all instead of document.getElementById at the expense of existing Mozilla and Apple installed bases. Nice try, but one bugzilla comment from a like-minded person proves nothing about web developers in general, and comment 54 shows the kind of carelessness about maximizing eyeballs that will go out of business fast on the real web. Comment 57 is less long-winded, but also mistaken. Clue: implementing IE DOM extensions including undetected document.all does not mean the world should stop using standards, for the reason given above: installed base and other browsers including IE all favor document.getElementById. The mistake lies in believing that only by limiting adoption and preaching standards (to deaf or long-gone content authors, in many cases) will standards spread. It's unfortunately the case that we're only cutting off our nose to spite our face. With more market share, Mozilla-based user agents could and should start moving the web toward the standards we want to support (which emphatically does not include all w3c RECs). Until we have more market share, we are not going to make much difference, even if we had AOL-level funding for evangelism (which we do not). Can any of you long-winded commenters concede that market share may undermine both evangelism *and* future growth in market share? I've heard from PC OEMs and others who will not ship Mozilla-based browsers because doing so will lose them money from customer calls, when IE-only sites appear broken. That is a real problem for the kind of non-trivial market share growth. Obviously we could go too far, and try to emulate IE at all costs. But we are not doing that, it's a straw man. _Realpolitic_ analogy: There are people who will never vote for a lesser evil in politics, and good for them for their blinding purity -- but it's easy to find yourself marginalized that way, because the greater evil incrementally "boils the frog", stealing the high ground and moving the dominant political parties toward the evil position. Short of revolution, which is seldom what it pretends to be (see the French and Russian cases), the smarter move is to unboil the frog, moving one or both of the dominant parties incrementally toward the better position. This _realpolitic_ effect applies on the web, too. Mozilla will continue to evangelize web standards, particularly document.getElementById. And we may remove this undetected document.all compatibility mechanism if we gain enough market share, although at that point I suspect we'll be worrying more about newer standards. Please, can we go to the newsgroups? I'm now being long-winded in defense of this bug, which is resolved fixed. This is not the place to debate or fight. BTW, subjecting every action made by core hackers to commmunity debate and consensus is not and has not been Mozilla policy, and it's a great recipe for paralysis. /be

> I've heard from PC OEMs > and others who will not ship Mozilla-based browsers because doing so will lose > them money from customer calls, when IE-only sites appear broken. That is a > real problem for the kind of non-trivial market share growth. That last sentence got cut off accidentally. "... for the kind of non-trivial market share growth necessary to effectively evangelize most of the document.all recidivists." I've posted to m.seamonkey and m.dom (followup-to: m.dom) a pointer to this bug, asking that advocacy comments and further arguments be posted as followups in m.dom. Here is the news: URL: news://news.mozilla.org:119/ce1les$ccv1@ripley.netscape.com. Google Groups URL for m.dom is http://groups.google.vg/groups?hl=en&lr=&ie=UTF-8&group=netscape.public.mozilla.dom (my post hasn't shown up on Google Groups yet). /be

One question, many websites currently listed in the Tech Evangelism section of mozilla are likely to be working with this new patch, how do we resolve them ? Should we wait for an official final release of Mozilla Suite/Firefox with document.all support to close these bugs ? Should we resolve them as WFM?

(In reply to comment #61) There won't be as many as you would hope actually. But wait for now, I would say.

> Feel free, but your code won't work in any Mozilla milestone shipped so far, > or in any Netscape or Red Hat distribution of Mozilla code, or in Safari. None of the previous releases of these browsers have significant market share nor will they ever. Its the future releases that matter. > It's absurd to claim that document.all works in more currently maintained > browsers than document.getElementById does It's absolutely absurd of you to claim that I made any such claim. I've had a hard enough time trying to get co-workers to ensure there code works in Mozilla. Fixing this bug makes this effort just a bit less necessary. Document.all satifies 99% of our needs. That's the very justification for fixing this bug. Thank you.

|It's absolutely absurd of you to claim that I made any such claim. I've had a |hard enough time trying to get co-workers to ensure there code works in |Mozilla. | Fixing this bug makes this effort just a bit less necessary. Document.all |satifies 99% of our needs. That's the very justification for fixing this bug. |Thank you. Its absurd of you to claim that this "feature" needs to be fixed because your co-workers are sloppy coders. Either tell them to do their job properly or get proper coders. Why would the future of Mozilla and its conformance to standards have to be dictated to by YOUR needs. Somehow that doesn't make sense.

> Its absurd of you to claim that this "feature" needs to be fixed because your > *** co-workers are sloppy coders ***. LOL! Don't get riled up. I'm done. I've made my point. (*** emphasis is mine.)

Ian Pottinger: see my reply to your comment 63 in the mozilla.dom newsgroup, at news://news.mozilla.org:119/410563FD.9060807@meer.net. To make this more substantive, I've filed a followup bug 253150 based on the helpful comment 50. /be

>> - Are you concerned that this will make tech evangelism harder, because sites >> we are trying to evangelise will just tell us to implement the part of the IE >> DOM that they happen to be using? > > No, and I already said that's silly, so why are you repeating it?(In reply to comment #52) Because it's not ? I've been working for tech evang for some time, and I can assure you it's not silly at all. I've seen this when we implemented offsetStuff, <marquee> and all. I've seen this a billion times when trying to get webmasters to use fixes that we wrote for their code. Why would they want to develop and maintain code when they just have to say "IE implements this, you need to implement this too, or our site won't work with your browser". Things are beginning to change, more and more sites works in gecko browsers, and I don't think we need document.all. It may help for a few sites - not that many according to the tests - in the short term, but it'll probably do more harm than good in the long term.

I added followup bug 253405 and bug 253408 for better JavaScript console messages to help web designers fix their document.all errors.

I added followup bug 253451 about allowing document.all to find elements with a given name as well as a given id. This will help document.all to work in more web pages.

(In reply to comment #67) > Why would they want to develop and maintain code when they just have to say "IE > implements this, you need to implement this too, or our site won't work with > your browser". The do not need to doi that, if there stuff isn't worth, or they are too silly or too lazzy. document.all never has been usefull and never will be usefull. But fortunately it is not as dangerous as next: (In reply to comment #13) > trying to reflect the ids into the window object would probably help a little > but I doubt it would end up helping that much. This behaviour of IE is one reason for many problems using IE, because it causes name conflicts between JavaScript names and names created by HTML elements that have a name attribut or id attribute. This pollution of the global namespace is a very big problem. document.all is just wasted work but not dangerous as long as if(document.all) evaluates to false. (In reply to comment #48) > The fact we face is that some part of the web content already written around the > world (much of it long ago, not today, where there is no one around to rewrite > it) assumes IE only. If such content has only shallow dependencies on IE's > non-standard DOM (document.all, element.innerHTML, offsetTop, e.g.), then with > this patch, we win. Without it, we lose, and we have no realistic hope of > winning in any realistic time frame. If this is your intention, you should implement the NN4 layers also to reintroduce backward compatibility to NN4.

Commenting in dead bugs is stupid. See my replies in the mozilla.dom newsgroup posting at news://news.mozilla.org:119/ce9ml4$5rt1@ripley.netscape.com. /be

(In reply to comment #71) > Commenting in dead bugs is stupid. See my replies in the mozilla.dom newsgroup > posting at news://news.mozilla.org:119/ce9ml4$5rt1@ripley.netscape.com. It would help if you actually *did* reply there.

Alexey: what is the problem? If you can't find my posting by that news: URL, here is the Google Groups link: http://groups.google.vg/groups?hl=en&lr=&ie=UTF-8&frame=right&rnum=61&thl=797578897,797498722,797630655,797401080,797362204,0&seekm=ce9024%24rcu3%40ripley.netscape.com#link63 In the name of all that which does not suck, please stop commenting here -- take it to the newsgroup. /be

First, a caveat: Although I've been coding in various languages for many decades, I've been personally active in -- rather that being CTO in charge of -- Web page development for but a few months, and am making extensive use of client-side Javascript. (Total documentation -- two books, HTML specs, CSS specs: over 4,000 pages. And I still have to hunt the Web several times a week to figure out "how to . . ." That itself verges on insanity.) I've found (and I know I'll get flamed here) document.all invaluable -- at least, I've not found anything nearly as easy to use in my implementation. A specific case: A table, built dynamically from accumulated cookie content -- the requirement here is to (1) NOT collect any data on the server side, for security assurances given to the user that that won't happen, they get to print the result locally for retention, and (2) provide instant updates without turnaround to the backend. The table contains an entry box for the user's "quantity". The Javascript, among other things, computes a new result on the fly as the user types -- no hitting an update button, no round trips -- and immediately posts the answer with each keystroke in another column in that row. (Obviously, onClick.) It's not just N x Y, there's an algorithm and parameters involved. Now, the onClick uses a Javascript function call with "this" as the argument, obviously. It is trivial then to get the sourceIndex of the cell as well as its content, increment/decrement as needed to identify the answer cell, use innerText or innerHTML as appropriate, etc., etc. Now, I suppose I could use getElementById instead. (I'm using that in many other places -- the situation is nowhere near as simple as the prior recitation.) A different Id on each entry cell and a parallel Id on the answer cell, constructing one from the other? Or putting the row number in as the argument and using that to get the input, determine the destination. Both of those are ugly by comparison, IMO. And then the reusability of the code is impaired; the same script file is used in multiple pages, each with a slightly different table or format, some with multiple tables all generated dynamically, etc., etc. This was the simplest of multiple bits of Javascript that were each made much, much easier by the IE extension. I'm not defending Microlimp. Was very disturned when the change of administration got them off the DoJ's hook. But when there is a feature introduced -- by anyone -- that makes everone's life easier, it is, to be blunt, elitist to sneer and reject because it's not "pure." OK, I'm ready to be told to come back in a year when I know more about the situation.

Gary, what you're trying to do can be done by playing around with other DOM properties, such as childNodes, previousSibling, nextSibling, parentNode, createElement, insertBefore, etc. You don't need to assign ID's to every element, because DOM1 methods provide many powerful ways to access and manipulate the DOM tree.

What about sites that check for document.all and document.layers, and then do nothing if neither of those exist? I've actually seen a few DHTML scripts that do exactly that; needless to say, they still won't work in Mozilla even with the proposed change...

Comment 76 is wasted in this bug. It's asking either for unconditional document.all emulation, or unconditional document.layers emulation. Find that bug and comment there, please. /be

Expression "'all' in document" returns true in Mozilla 1.8a3. Is is bug or feature? Yes, many sites are using expression "if(document.all)" for detection , but if we want to make it really undetectable, we should hide also "if ('all' in document)", shouldn't we?

(In reply to comment #78) > we should hide also "if ('all' in document)", shouldn't we? I think we shouldn't :) It's not widely used to detect document.all (to be precise, I've never seen it in an actual webpage), and hiding '"all" in document' would probably make Mozilla's support for the "in" operator not very ECMAScript-compliant.

Fixed on the 1.7 branch.

d

I think we should give credit where credit is due! The first time somebody came up with the idea of implementing document.all - *only* when there was no browser detection done beforehand - was Bryant Howell in bug 74201 and Ramón García in comment #72 ff of bug 154589 This was mid-2002 and the commentaries to these bugs show the fierce arguments that occured when the tech evangelists where confronted with these "new ideas". Two years have passed since and some persons who opposed theses bugs now supported to implement them. If you check the history of this "bug" it teaches a good lesson how one's policy can change over the years. True history!

(In reply to comment #82) > Two years have passed since and some persons who opposed theses bugs now > supported to implement them. If you check the history of this "bug" it > teaches a good lesson how one's policy can change over the years. True > history! My favorite Calvin & Hobbes strip illustrates this: Panel 1: Calvin: "Some people are pragmatists, taking things as they come and making the best of the choices available." Panel 2: Calvin continues: "Some people are idealists, standing for principle and refusing to compromise." Panel 3: Calvin again: "And some people just act on any whim that enters their heads." Panel 4: Hobbes (rolling his eyes): "I wonder which YOU are." Calvin: "I pragmatically turn my whims into principles." Merry Christmas. Calvin.

The newsgroup link in comment 73 is broken. (This bug's summary points to comment 73.)

This bug here is closed and fixed, if you want to discuss this further read http://groups.google.com/groups?selm=ce9ml4$5rt1%40ripley.netscape.com and http://groups.google.com/groups?threadm=ce9ml4$5rt1%40ripley.netscape.com first. If you then want to discuss that further, post to news://news.mozilla.org/mozilla.dev.tech.dom