248549 - Add undetected document.all support. - Please read comment #85!

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect, P2)

Description

[Brendan Eich [:brendan]]

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

Comment 1

[Johnny Stenback (:jst)]

Attachment: Expose document.all unless detected first.

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.

Comment 2

[Brendan Eich [:brendan]]

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

Comment 3

[Brendan Eich [:brendan]]

Attachment: proposed js engine extension to JSRESOLVE_DETECTING condition

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

Comment 4

[Johnny Stenback (:jst)]

(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?

Comment 5

[Aaron Kaluszka]

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.

Comment 6

[Brendan Eich [:brendan]]

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

Comment 7

[Bob Clary [:bc] (inactive)]

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.

Comment 8

[Thomas Verelst]

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

Comment 9

[Hixie (not reading bugmail)]

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

Comment 10

[Thomas Verelst]

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

Comment 11

[Bob Clary [:bc] (inactive)]

Attachment: javascript-logs.zip

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.

Comment 12

[Brendan Eich [:brendan]]

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

Comment 13

[Bob Clary [:bc] (inactive)]

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.

Comment 14

[Brendan Eich [:brendan]]

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

Comment 15

[Doron Rosenberg (IBM)]

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.

Comment 16

[Robin Lu]

(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?

Comment 17

[Brendan Eich [:brendan]]

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

Comment 18

[Brendan Eich [:brendan]]

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

/be

Comment 19

[Brendan Eich [:brendan]]

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

/be

Comment 20

[bugzilla]

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

Comment 21

[Johnny Stenback (:jst)]

Attachment: Support document.all.tags too!

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

Comment 22

[Alfonso Martinez]

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.

Comment 23

[Johnny Stenback (:jst)]

(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 24

[Brendan Eich [:brendan]]

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

Comment 25

[Asaf Romano (gone)]

jst: What about document.elementName?

Comment 26

[Johnny Stenback (:jst)]

Attachment: Same as above with code to write message to console first time (per page) document.all is used.

Comment 27

[Johnny Stenback (:jst)]

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

Comment 28

[Ben Goodger (use ben at mozilla dot org for email)]

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

Comment 29

[Peter Van der Beken [:peterv]]

I'll review this tomorrow.

Comment 30

[Johnny Stenback (:jst)]

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.

Comment 31

[Steffen Wilberg]

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

Comment 32

[Johnny Stenback (:jst)]

Fixed on trunk and aviary branch.

Comment 33

[Gervase Markham [:gerv]]

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

Gerv

Comment 34

[Hixie (not reading bugmail)]

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?

Comment 35

[basic]

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

Comment 36

[Ohad Lutzky]

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.

Comment 37

[Prognathous]

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.

Comment 38

[R.J. Keller]

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

Comment 39

[Gervase Markham [:gerv]]

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 40

[Brendan Eich [:brendan]]

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

Comment 41

[Bob Clary [:bc] (inactive)]

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.

Comment 42

[Hixie (not reading bugmail)]

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.

Comment 43

[Gervase Markham [:gerv]]

> 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

Comment 44

[Hixie (not reading bugmail)]

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

Comment 45

[Gervase Markham [:gerv]]

> 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

Comment 46

[Hixie (not reading bugmail)]

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

Comment 47

[Erik Fabert]

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

Comment 48

[Brendan Eich [:brendan]]

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

Comment 49

[Brendan Eich [:brendan]]

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

Comment 50

[Erik Fabert]

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

Comment 51

[Gervase Markham [:gerv]]

> 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

Comment 52

[Brendan Eich [:brendan]]

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

Comment 53

[Bob Clary [:bc] (inactive)]

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

Comment 54

[Ian Pottinger]

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

Comment 55

[Bob Clary [:bc] (inactive)]

Attachment: test site list and zipped Logs 281KB

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

Comment 56

[Alexey Chernyak]

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?

Comment 57

[Gérard Talbot]

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.

Comment 58

[Ray Booysen]

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.

Comment 59

[Brendan Eich [:brendan]]

> 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

Comment 60

[Brendan Eich [:brendan]]

> 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$[e-mail].  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

Comment 61

[Pascal Chevrel:pascalc]

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? 

Comment 62

[Bob Clary [:bc] (inactive)]

(In reply to comment #61)

There won't be as many as you would hope actually. But wait for now, I would say.

Comment 63

[Ian Pottinger]

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

Comment 64

[Ray Booysen]

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

Comment 65

[Ian Pottinger]

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

Comment 66

[Brendan Eich [:brendan]]

Ian Pottinger: see my reply to your comment 63 in the mozilla.dom newsgroup, at
news://news.mozilla.org:119/[e-mail].

To make this more substantive, I've filed a followup bug 253150 based on the
helpful comment 50.

/be 

Comment 67

[Mathieu Pillard [:mat]]

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

Comment 68

[Steve Chapel]

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

Comment 69

[Steve Chapel]

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.

Comment 70

[Georg Maaß]

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

Comment 71

[Brendan Eich [:brendan]]

Commenting in dead bugs is stupid.  See my replies in the mozilla.dom newsgroup
posting at news://news.mozilla.org:119/ce9ml4$[e-mail].

/be

Comment 72

[Alexey Chernyak]

(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$[e-mail].

It would help if you actually *did* reply there.

Comment 73

[Brendan Eich [:brendan]]

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

Comment 74

[Gary]

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.

Comment 75

[Bamm Gabriana]

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.

Comment 76

[Cody 'codeman38' Boisclair]

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 77

[Brendan Eich [:brendan]]

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

Comment 78

[Met - Martin Hassman]

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?

Comment 79

[Marek Stępień [:marcoos, inactive]]

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

Comment 80

[Johnny Stenback (:jst)]

Fixed on the 1.7 branch.

Comment 81

[darrin maidlow]

d

Comment 82

[Daniel Kabs, reporting bugs since 2002]

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!

Comment 83

[Gary]

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

Comment 84

[Jesse Ruderman]

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

Comment 85

[Frank Wein [:mcsmurf]]

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