Closed
Bug 74201
Opened 24 years ago
Closed 24 years ago
Internet Explorer (document.all) Compatibility
Categories
(Core :: DOM: Core & HTML, enhancement)
Core
DOM: Core & HTML
Tracking
()
VERIFIED
WONTFIX
People
(Reporter: BryanZx, Assigned: jst)
References
Details
If we wanted to beat Microsoft at their own game, why not slip in compatibility with some of their features, like document.all. Would it be possible that when document.all is located and no branches for Mozilla are available in the Javascript, that document.all function as document.getElementById(). This would solve compatibility with the old Internet Explorer versions. Maybe this goes against the spirit of the browser but I think it would be great after 1.0 to support all the old stuff to say not only are we the most compatible with the W3C , but we also match the competition.
confirming enhancement request
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Internet Explorer (document.all) Compatibility → [RFE] Internet Explorer (document.all) Compatibility
Comment 3•24 years ago
|
||
Assuming the "game" in question is a complete disregard for standards, then this would seem to defeat the purpose of all the standards compliance work we've done, no? I don't think very many people would see it as beating them at their own game, either, so much as supporting the same propietary extensions they do.
Assignee | ||
Comment 4•24 years ago
|
||
If it would've been decided in the early days of mozilla that document.all should be supported then I wouldn've have much problem with doing so, but deciding now to start supporting document.all is IMO a very bad idea, there are pages our there already that use code like: if (document.all) { // Do IE specific stuff } else if (document.getElementById) { // Do mozilla specific stuff } ... and if we'd now all of a sudden started supporting document.all we'd break things like this. Even worse, the closer to IE mozilla gets (in terms of DOM functionality) the more bugs we'll get about mozilla not working exactly as IE does, and I'm not up for revers-engineering everything in IE at this point, that would be extremely complicated and time consuming. We're already seeing similar problems with mozilla's support for IE's element.offsetXXX properties, they behave more or less the same way, but not exactly what IE does, and finding out exactly how IE works is non-trivial (for all the hundreds of proprietary methods/properties in IE), to say the least. I'm all for implementing functionality in mozilla that exists in IE and is very useful, cleanly defined and has a nice clean API, however, document.all is not one of those things, I it's not a clean API (it's a list and a hash and callable function, and what exactly does it contain? Who knows?), there are other nice clean standards compliant API's that give you everything that document.all gives you, I say that's enough. Marking WONTFIX.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → WONTFIX
Well, there goes any chance of Mozilla taking over the world. Standards are for people who live in a utopic world. There is one standard for browsers, no matter what any comittee says, and that is the buggy behavior of IE. If thousands of websites use Microsoft products to design their sites, and those products implant Microsoft scripts in the web pages, then no arguing or whining or justifying standards is going to help Mozilla proliferate. If I can't use Mozilla to access my favorite web sites (and as of now I can't), then I will still need Internet Explorer for most of my browsing.
Comment 10•21 years ago
|
||
I agree that we need to add IE compatibility in order to make Mozilla more useful. There are a large number of sites out there that use IE specific javascript code that breaks on Mozilla. I have no choice - I have to use many of these sites, and to do so I have to load up IE. Why not make IE compatibility an option that can be switched on?
Updated•21 years ago
|
Summary: [RFE] Internet Explorer (document.all) Compatibility → Internet Explorer (document.all) Compatibility
Comment 16•21 years ago
|
||
I think taht standart compilance is good..:> Ok let's lash all of the bad guys which doesn't want to follow standarts, instaed of do nothing show FIVE BIG WARNINGS on page right where they want to use document.all or whatever mozilla can't show, that developer is stupid and he is doing wrong thing. This is a joke!!!!!!! but is even better of do nothing and wait microsoft to force developers to use getElementById...
Comment 17•21 years ago
|
||
this is my last comment... sorry.. first variant rise and alert on every document.all... :> second variant write in html coments about where developer have to read about document.all and documen.getelementbyid... :> third variant mimicry documnet.all to document.getelementbyid for most used situation like changing styles .. document.all.item().style.backgroundColor or document.all.item().src
Comment 18•20 years ago
|
||
(In reply to comment #4) > If it would've been decided in the early days of mozilla that document.all > should be supported then I wouldn've have much problem with doing so, but > deciding now to start supporting document.all is IMO a very bad idea, there are > pages our there already that use code like: > > if (document.all) { > // Do IE specific stuff > } else if (document.getElementById) { > // Do mozilla specific stuff > } ... > This is the main problem. Braking this will force deveolopers to stop using it. And they will make their code standart. WONTFIX is a cowardly solution. > and if we'd now all of a sudden started supporting document.all we'd break > things like this. > > Even worse, the closer to IE mozilla gets (in terms of DOM functionality) the > more bugs we'll get about mozilla not working exactly as IE does, and I'm not up > for revers-engineering everything in IE at this point, that would be extremely > complicated and time consuming. No body wants mozilla to work exactly as IE does, it's not about mozilla and IE it's about webdevelopers, once they learn that ease solution like above JS is bad they'll find elegant way using getelementbyid. >We're already seeing similar problems with > mozilla's support for IE's element.offsetXXX properties, they behave more or > less the same way, but not exactly what IE does, and finding out exactly how IE > works is non-trivial (for all the hundreds of proprietary methods/properties in > IE), to say the least. > > I'm all for implementing functionality in mozilla that exists in IE and is very > useful, cleanly defined and has a nice clean API, however, document.all is not > one of those things, I it's not a clean API (it's a list and a hash and callable > function, and what exactly does it contain? Who knows?), there are other nice > clean standards compliant API's that give you everything that document.all gives > you, I say that's enough. > Forget about API and properties and methods, when developer find that he can't swich which metods to use with JS as above he will use getelementbyid. > Marking WONTFIX.
Comment 19•20 years ago
|
||
> This is the main problem. Braking this will force deveolopers to stop using
> it. And they will make their code standart.
No they really won't. Just look at the number of sites that use document.all
right now and _do_ break.
Assignee | ||
Comment 20•20 years ago
|
||
For those who care, bug 248549 adds support for document.all in a way that doesn't break existing standards compliant code.
Comment 21•20 years ago
|
||
Please keep this bug WONTFIX for ever. IE is loosing 0.2% market share every single month we certainly don't need to bloat mozilla browsers with non standard ****. - As a webdeveloper I'm always trying to follow web standards in a hope that it'll render the same for everyone. - As a user if a site doesn't work in my browser because of bad code the site is not worth visiting and the only thing I would do is write to it's webmaster to ask hime to make his homework.
Updated•12 years ago
|
Component: DOM: Mozilla Extensions → DOM
Updated•6 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•