document.all evaluates to false but document.all['chicken'] gets the item with ID - Mozilla madness!

J

Jim Ley

Hi,

It seems the mozilla guys have chosen another (almost certainly poor
choice in my initial thoughts) of having document.all evaluate to
false, but document.all['chicken'] catch the chicken event - also
document.all.tags will work.

It seems that the document.all not evaluating to true is to stop the
really dumb object assumption scripts to fail and the document.all
scripts that don't bother with any object detection to all of a sudden
"work".

A shame, actual IE emulation would've made much more sense.

http://bugzilla.mozilla.org/show_bug.cgi?id=248549

Jim..
 
L

Lasse Reichstein Nielsen

It seems the mozilla guys have chosen another (almost certainly poor
choice in my initial thoughts) of having document.all evaluate to
false, but document.all['chicken'] catch the chicken event - also
document.all.tags will work. ....
http://bugzilla.mozilla.org/show_bug.cgi?id=248549

Yes, it seems to have status RESOLVED/FIXED, so I guess that means
that it is in (apparently in the birds version 1.0). Bummer. I had
hoped they would stand by this one
<URL:http://www.mozilla.org.uk/docs/proprietary-features-bad.html>

/L
 
G

Grant Wagner

Jim said:
Hi,

It seems the mozilla guys have chosen another (almost certainly poor
choice in my initial thoughts) of having document.all evaluate to
false, but document.all['chicken'] catch the chicken event - also
document.all.tags will work.

It seems that the document.all not evaluating to true is to stop the
really dumb object assumption scripts to fail and the document.all
scripts that don't bother with any object detection to all of a sudden
"work".

A shame, actual IE emulation would've made much more sense.

The shame of it is that _any_ IE emulation will simply delay the authoring
of standards-compliant scripts.

innerHTML was an acceptable compromise because it is useful functionality
that could only be replaced by complex createElement() activities.
Including document.all.tags when there is an easy, standards-compliant
mechanism to do the same thing is totally unacceptable in my opinion.

I guess we can look forward to badly written scripts that use proprietary
features for many, many years to come.
 
D

DU

Grant said:
Jim Ley wrote:

Hi,

It seems the mozilla guys have chosen another (almost certainly poor
choice in my initial thoughts) of having document.all evaluate to
false, but document.all['chicken'] catch the chicken event - also
document.all.tags will work.

It seems that the document.all not evaluating to true is to stop the
really dumb object assumption scripts to fail and the document.all
scripts that don't bother with any object detection to all of a sudden
"work".

A shame, actual IE emulation would've made much more sense.


The shame of it is that _any_ IE emulation will simply delay the authoring
of standards-compliant scripts.

innerHTML was an acceptable compromise because it is useful functionality
that could only be replaced by complex createElement() activities.
Including document.all.tags when there is an easy, standards-compliant
mechanism to do the same thing is totally unacceptable in my opinion.

I guess we can look forward to badly written scripts that use proprietary
features for many, many years to come.


I entirely agree with your opinions and with Jim's and Lasse's opinions
on this. The thing is that Mozilla.org is opening the door to more
compromises of this sort and to more "smart compatibility" with
IE-specific ways to do DHTML scripts. The message that is sent with this
support of document.all[idElement] is that it is no longer beneficial to
resort to W3C web standards methods anymore. 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?? The message is 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?
I don't agree with this.

For over 2 years, many evangelization documents
{
Using Web Standards in Your Web Pages
http://www.mozilla.org/docs/web-developer/upgrade_2.html
http://bugzilla.mozilla.org/show_bug.cgi?id=74952
and
Updating DHTML Web Pages for next generation browsers
http://devedge.netscape.com/viewsource/2001/updating-dhtml-web-pages/#codefork
and
the whole Gecko DOM reference
}
failed to be accurate and reliable (not even without markup errors!) at
mozilla.org. It is obvious to first start with sanitizing these files
first before going into drastic directions/actions like that bugfile
http://bugzilla.mozilla.org/show_bug.cgi?id=248549
went.

Mozilla never was able to promote proactively and coherently W3C web
standards when, on 1 hand, mozilla.org webpages were promoting W3C web
standards that mozilla.org failed (or refused) to implement into its own
webpages.

One last thing. I think Lasse, Jim and yourself would be interested into
getting involved in bug 74952 and bug 93108
http://bugzilla.mozilla.org/show_bug.cgi?id=74952
http://bugzilla.mozilla.org/show_bug.cgi?id=93108
I sure would be interested into hearing suggestions (and/or feedback on
mine) regarding bug 74952.

DU
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,769
Messages
2,569,579
Members
45,053
Latest member
BrodieSola

Latest Threads

Top