From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020619 BuildID: Any Hello, I am aware of the current policy of Mozilla of not implementing Internet Explorer DOM features, as one can read in http://www.mozilla.org/quality/help/bugzilla-helper.html . I suggest that this policy should be changed. Lots of pages are currently inaccesible for Mozilla users. Futhermore, since Mozilla produces a very small amount of hits in servers, web developers have little incentive in producing web pages that work with Mozilla. Although it is not technically difficult to do so, most commercial web pages are produced by cheap consultories. Their mediocre Javascript programmers try to get the job done as fast as posible, and only test against Internet Explorer or perhaps Netscape 4.x, but never with Mozilla. The result is that, at least in Spain, practically all important comercial web sites are blocked from using Mozilla. For instance, Iberia's web site, www.iberia.com (the leading airlines company in Spain) cannot be used with Mozilla for buying tickets, because for selecting the date one has to use a calendar that requires either document.all or document.layers. Ebankinter, probably the most important electronic bank in Spain cannot be used with Mozilla, because Mozilla rejects a regular expression with a {0}. This illustrates that no test was done with Mozilla. The problem has been reported, but there are not lots of changes of getting it fixed. Making a change, even a small one, requires lots of tests to be done, and there is little incentive for a browser with few users such as Mozilla or Netscape 6. There are many examples, such as www.auto-res.net (bus tickets), www.abbys-computer.com (computer store), ... As explained in the column of the former Microsoft Excel program manager Joel Spolsky, http://www.joelonsoftware.com/articles/fog0000000054.html any new software platform must be compatible. Examples of this rule include BeOS, AmigaOS, ... who have disappeared because there where no applications for them. Most users do not care about using Mozilla or Internet Explorer. When they see that Mozilla fails to show a page, they do not know or care of the reason; they will switch to Internet Explorer. Reproducible: Always Steps to Reproduce: obvious

Implements some Internet Explorer extensions (the ones I have seen used): document.all, window.<id> (where id is the id attribute of a node), and HTMLElement.outerHTML. document.all does not support the syntax document.all("index") and document.all.tag["tagname"], because I have not yet seen any site that needs them. To apply the patch, enter in the "mozilla" subdirectory (where you see the subdirectories accesible, build, calendar, caps, ...) and type patch -p2 < filename (filename is the file where you saved the patch).

Changed severity to 'enhancement' and added [rfe] to summary Ramon, nice work, but this bug might be closed, by someone else, as WONTFIX just because of that same policy ;)

well he wrote a patch... +nsGenericHTMLElement::GetOuterHTML(nsAString& aOuterHTML) +{ + aOuterHTML.Truncate(); ... + return rv; +} + +nsresult +nsGenericHTMLElement::SetOuterHTML(const nsAString& aOuterHTML) +{ + nsresult rv = NS_OK; please keep indentation constant, don't use tabs, and do match the file rule for that file it's: 1 gerv 1.283 /* -*- Mode: C++; tab-width: 2; indent-tabs-mode: nil; c-basic-offset: 2 -*- */ so you should use 2 spaces, attribute DOMString innerHTML; + attribute DOMString outerHTML; these should line up, i'm guesssing you used a tab. never use hard tabs :) + wrapper->GetNative(getter_AddRefs(native)); + NS_ABORT_IF_FALSE(native, "No native!"); Abort is rather harsh. imo your code should never need abort.

ok, so you have my preliminary review notes. personally if this feature were to be accepted by mozilla, i'd prefer for it to be a pref, either simply on/off (default: off), or using security:caps to allow access to it (again, default: off). with caps, people could then manually provide the crutch to sites on an individual basis and still have an insentive to complain to site authors. if caps was set to refuse access, then it should be as if the property wasn't there (instead of throwing an exception). i'm not sure if that's possible, but ...

Reply to Comment #3 Sorry with indentation. Should I post a new patch? With regards to NS_ABORT_IF_FALSE, I wrote it for consistency with the rest of nsDOMClassInfo.cpp. (For instance, nsHTMLDocumentSH::ResolveImpl uses it). The reason seems to be that any Javascript object bound to a native object must have "native" defined. Otherwise, the xxxSH (SH = Script Helper) would not have been called.

With regard to Comment #4. I think that by default these extensions should be accepted. Most Netscape users (where Mozilla code will be used) know nothing about javascript. They see that some site does not work and it works with Internet Explorer. They will blame Mozilla rather than the site. If the intention is to provide incentive for using standards in the sites, a better method would be to display a dialog box warning the user that "this site uses incorrect javascript", and provide a check box so that the dialog is not displayed again for the same site.

I think there needs to be a careful and public review of the possible consequences and discussion among the module owner and peers before we take this patch. While this may seem like an "easy win" situation, there are several adverse consequences to consider: 1) This means that implementors of future browsers will continue to have to support the unstandardized document.all DOM as well as W3C DOM, placing an additional burden on them. 2) We're also going to have to commit to maintaining this additional implementation. 3) Most disturbingly, this could act as the "thin end of the wedge" for providing additional proprietary DOM support. If people find that some of their document.all scripts work in Mozilla, they'll probably expect that all such scripts work in Mozilla, and when they don't, they'll regard it as a bug in our browser than we don't do so. This expectation applies not only to the existing parts of document.all that the patch doesn't cover, but to any future extensions by MS to the document.all collection, and I doubt they'd be reluctant to make us play catch-up with them. WRT comment #6: Let me share a quote from the head of the Mac IE team, uttered in a similar context: "If a UA did report such errors with a web site, the typical user would take the corrective action they usually take when errors are reported from a website, and that is to try a different UA." Ten painful years of web experience have shown that the only thing web authors care about is whether their page displays right; if a user agent displays some error, it's just being dumb-- after all, it renders the page properly, doesn't it? Quite simply, there is no middle ground. Trying to get people to stop using something that "works" is simply impossible.

I oppose adding document.all to our object model since it will break the major object based detection scheme that is currently on the web. document.all is widely used to differentiate IE from other browsers in particular ourselves and in particular with respect to events. If an individual site wishes to emulate document.all they can easily do so with the awareness that they will have to use other means to distinguish browsers but removing this distinction from the web at this point is a recipe for disaster imo.

This is invalid, if we implement a non-standard dom, then its 4.x's for backwards compatability. Documant.all support will break more sites than fix, and as an technology evangelist, I'm not just talking rubbish :) As for document.all.tag["tagname"], I've seen it used. google for it.

My replay to comment #7 Of course, we all agree that the decission should be reviewed. In replay to the other arguments. If Mozilla would have a market share of, say, 40 %, then it would could exercise some control on the usage of standards, and then I would agree with refusing non standards constructs. Unfortunately, due to the 95 % of share of Microsoft Internet Explorer, there is very little choice. Many commercial web sites are tested with Microsoft browser only; others do take into account Netscape 4.x. Mozilla is rarely taken into account. This means that Mozilla has little power of influence in web authors. The fact that major commercial sites that effectivly block Mozilla is an evidence. For instance, in http://www.mandrakeforum.com/article.php?sid=1213&lang=en we can read the experience of a web developer trying to convince his boss to support Netscape 6. "But my project manager and all the team know (or think they know) that Netscape is dead and now represents 5% of all browsers, and for them Netscape is DEAD". The patch is small, thus showing that the burden is not much. It took me more time to figure what point I needed to patch than to write the actual code. Finally, replaying to the argument of the "thin end of the wedge". Since the purpose is compatibility, only extensions that are actually used should be supported. I remember now window.event and element.style.pixelTop, that I may implement some day. I do not think that implementing these extensions will encourage much using them. If everything that can be done with extensions can be done in standards compliant ways, competent web authors will choose the standards, a good programmer tries his best to do the right thing. Less competent authors, or authors who need to get the job done at any price in little time, probably do not even test with Mozilla. Ramon

My replay to comment #8 and comment #9 Your argument is that document.all is used to detect Internet Explorer, and then to use other features such as window.event . Why not implementing window.event and other frequently used extensions in addition to document.all ? I can do it. It would seem natural to implement document.layers as well. Unfortunately, it is much more complicated. document.layers is a collection of document objects, and emulating it is not trivial. Yes, it is trivial to change sites so that they do not need document.all in the browser. But that is something that we do not have the power to change. Experience shows that even if it is easy for webmasters to fix a site they will not do it for a browser with a small market. Can something be easier than fixing an incorrect regular expression changing [^0]\d{0} by simply [^0]? I reported to http://www.ebankinter.com and the reply was literally "This site is optimized for Internet Explorer, but can be also used with Netscape 4". Finally, I may implement document.all.tag["tagname"] Ramon

First implement 100% of the IE dom and then we can invalidate this. So once window.events comes in, then we have to modify our event code and etc. This will become a huge task, and what about QA? This won't go into mozilla nor netscape :)

Replay to Comment #9 : I have looked for document.all.tag in Google and found only 13 matches :-) I tried "document.all.tag" and advanced search page and only 13 matches.

WONTFIX bug 74201 covers the same issue in case someone wants to review the arguments there instead of repeating them all again.

Replay to comment #12: 100 % of IE DOM is not needed. Only features that are reasonably frequently used. A reasonable choice would be the functions emulated http://www.webfx.nu/dhtml/ieemu/ieemu.js , and element.style.pixel[Left,Top]. Some of them insertAdjacentHTML are probably redundant: I have never seen them. In total ieemu.js has 308 lines, and element.style.pixel[Left,Top] can be implemented as wrappers of element.style.[Left,Top]. Come on, it is not that large. Ramon

Ramón, please listen to the evangelists here (Bob, Doron, ...), they've been dealing with these exact issues for years and they know what they're talking about. Implementing document.all n' friends will *not* solve the problem you're trying to solve here, as Bob and Doron said, it will most likely break more sites that it will fix since most pages nowadays do: if (document.all) { do IE stuff } else if ... and just because we'd implement document.all doesn't mean we'd support what "do IE stuff" does, and from what I've seen so far, and from what I've heard from other people that have been in this boat for a long time, in most cases Mozilla wouldn't work. If we take this step and start supporting document.all then we need to support window.event, element.currentStyle, element.outerHTML, the whole IE event model (which is far from trivial and not supportable w/o breaking the already defined W3C DOM Event model), exposing elemnts by their ID in the global namespace, supporting all the IE quirks in element.style. The list goes on. You're a very brave man for claiming you can do all this, and if you can, more power to you. But keep in mind that it took Netscape *years* to become as compatible as it is with the things we chose to be comapatible with, there are a *ton* of quirks in every DOM implementation out there, IE being only one of them, and finding those quirks (even only in IE) is far from easy. I bet the 80/20 rule applies very well here, you can implement support for 80% of the remaining IE DOM in mozilla and it'll take you only 20% of the time that it would take you to implement complete support (including being bug comatible, which believe it or not is very important). What makes this task so hard is that while you can implement most of this fairly fast, an implementation that's not extremely close to what you're trying to emulate (IE) isn't really helping anyone all that much. If you're not 99% (or something close to that) compatible then you'll still have the same problems as you did before you started, yes, you would've made it easier for sites to make their pages work in mozilla, and sure, some sites would probably work "out of the box", but if you're not all the way there yet, lots of sites would still need to write special code to make their site work in mozilla. So in the end, the problem still exists, even if it's not exactly as big. And once you think you're "done", a new site pops up, or a huge site out there updates their pages, and something else creeps up that would need to be tweaked in Mozilla. The evangelists job didn't really get that much easier, and we got a far less clean DOM implementation into Mozilla. I'm not convinced that it's worth it. Had Mozilla (or Netscape, really) chosen to aim at 100% IE compatibility from the start then I'd be more than happy to add support for whatever quirks that pop up as we move forward, but now, after Mozilla 1.0 is released and it's been more than a year since the first commercial product was released based on the Mozilla standards-compliant code was released to the public (Netscape 6.0, which admittedly wasn't all that impressive or well received by the masses) I'm still not convinced that this is worth doing. Maybe I'm wrong, but these are my thoughts based on what I've seen as the owner and primary developer of the Mozilla DOM code for the last 2 years.

Replay to comment #16 I undestand the argument that implementing document.all has the risk of breaking sites that depend on it to include or not MSIE features, and therefore document.all requires more extensions. However, your main point is "What makes this task so hard is that while you can implement most of this fairly fast, an implementation that's not extremely close to what you're trying to emulate (IE) isn't really helping anyone all that much". I think that implementing that 80 % easy subset will make work most sites that do not work at present. But let us assume that, as you propose, the easy part of emulating MSIE DOM does not work because many sites not tested with Mozilla do not work with Mozilla. Sorry, but that does not stop the current dynamics. That is, that webmasters develop for the browsers that they see in their logs, and that means 95 % MSIE and 5 % Netscape 4.x. Sites want to have their sites developed with little cost, and that means hiring cheap consultories. And that users use what seems to "works better", and that means MSIE. In that case, I am afraid, Mozilla would be lost. Ramon

Some browser statistics I mentioned that browser usage statistics are the reason why web developers have incentive of developing for a particular browser. So here are some browser statistics From thecounter.com (http://www.thecounter.com/stats/2002/May/browser.php) Total visitors 404064153 1. MSIE 5.x 219146705 (54%) 2. MSIE 6.x 141191308 (34%) 3. Netscape 4.x 16606594 (4.1%) 4. MSIE 4.x 13080856 (3.2%) 5. Netscape comp. 4256467 (1.0%) 6. Netscape 6.x 3490540 (0.86%) 7. Opera x.x 3113504 (0.77%) 8. Unknown 1345945 (0.33%) 9. Netscape 5.x 1054535 (0.26%) 10. Netscape 3.x 267702 (0.066%) 11. MSIE 3.x 250732 (0.062%) 12. MSIE 2.x 235615 (0.058%) 13. Netscape 2.x 22461 (0.005%) 14. MSIE 1.x 597 (0.0001%) 15. Netscape 1.x 592 (0.0001%)

Based on some of the things that have been reported in the press recently <http://news.com.com/2100-1023-860710.html>, one could speculate that those statistics will change dramatically sometime soon. And if those numbers all of a sudden change one of these days, one could continue to speculate that sites will fix themselves or lose a considerable market share.

Correct me if I am wrong. I suspect that part of the reason of the opposition for implementing document.all is that some sites that the Tech Evangelism managed to make Mozilla compliant did so by checking document.all in Javascript code. Breaking those sites would be breaking a commitment. In that case, that could be fixed by adding a list of sites that have document.all disabled.

so... are you volunteering to visit every website on the planet and compile this list?

The problems here, Ramón, are two-fold. 1) We do not fix the majority of sites by doing this. Sure, we might fix the occasional one that uses *just* document.all instead of document.getElementById(), but to fix any site of reasonable complexity requires a complete implementation of IE's object and event model, a task that I doubt even Microsoft is competent to attempt at this point. jst, among others, have pointed this out. 2) We give page authors absolutely no incentive to change their habits. For the sake of a couple of pages with extremely short-sighted authors, we sacrifice our stand on standards and allow the kind of crap that has permeated DOM implementations until now to continue. I can guarantee that if you go to those sites in Spain with a Mozilla that supports pieces of IE's object model, you give them no reason at all to support standards. Why would anyone spend the minor amount of money necessary (and it is indeed minor; the cost of testing new code is virtually minimal when you've got the free aid of the Mozilla evangelism effort, who would practically be willing to write the code for you) to support the DOM when they could just keep their existing pages? Which means support for Mozilla never gets any better, because the pages are never written to the standards that Mozilla has tried very hard to implement. And that Opera tries very hard to implement. And Konqueror. And IE/Mac. And iCab. And any of a host of other browsers. For the sake of developers weaned on IE/Windows, which had a big stick up its rear for years, everyone else is impaired. If we kowtow to Microsoftian "standards," we doom the real standards which most everyone else attempts to support.

> document.all does not support the syntax document.all("index") and > document.all.tag["tagname"], because I have not yet seen any site that > needs them. There is at least one semi-popular menu system that uses the latter. If we implement document.all, we had better implement that... > + int rv = doc->GetElementById(name, result); nsresult rv Other technical issues: 1) Sites assume that anything having document.all also has window.event 2) Sites assume that anything having document.all also has Element.currentStyle 3) Sites assume that anything having document.all does _not_ support certain parts of the DOM or supports it in odd ways.

The point of item #3 is that we do not want to screw over standards-compliant sites if we can avoid it.

Doh. I just went back and read all the comments (not sure how I missed some of them the first time). Leaving ethical and technical issues aside, a purely pragmatic management decision for any checkin like this has to consider the following issues: 1) How many (and what type) of sites will this help? 2) How many (and what type) of sites will this break? 3) How much more or less evangelism work will there be as a result of this checkin? 4) How much easier or harder will evangelism work be as a result of this checkin (eg. it may be easier because less needs to be changed in sites, it might be harder because sites may be more likely to come back with "why don't you make it work just like IE instead")? These 4 items together combine, in my opinion, to give an answer to the really important question here (from a pragmatic standpoint): "What effect will this checkin have on browser adoption?" Bob and Doron are the people who would know best the answers to these questions, I believe.... Once we have decided this issue, we can start talking about the techical issues and ethical issues involved.

My replay with Comment #22 a) We agree that implementing document.all might be a step backwards because sites assume that if document.all is present the other things must be present. However, I think that the number of needed things is minor. My impression after reading webfx.nu page on the matter is that Mozilla model is powerful enough that allows the IE model to be implemented as a trivial wrapper in most cases. Johnny Stenback pointed out that subtle compatibility problems will appear and I agree, but I think that most pages will work fine. b) We disagree in that point. Sorry for repeating myself. At present there is very little incentive for commercial sites for being compatible with Mozilla. Mozilla (including Netscape 6) stands for about 1 % of hits. That should not be an excluse: any decent web programmer would make his site work with any browser with some trivial javascript programming. Unfortunately, most sites hire cheap consultories that get the job done in the most ugliest posible way. They make sites full of Flash to impress companies that have little or no clue on technology.

my 0.02 Euro (sorry for the spam) This is against all why I like Mozilla and why I work on this open-source projekt with my small resources. Today: "docment.all" crap, tomorrow document.layers (via a stupid mozdev project) and after that use content sniffing like IE and add vbscript and ActiveX support (including Plugins). I want a fast, nice standards complient browser and no IE clone. Mozilla will loose his glory if we add this... (unless Document.all is an official standard)

Replay to comment #24 and comment #25 Thanks for the fix. Corrected in my tree. I have been convinced that implementing document.all alone (as my patch does, with two little additions) would be a step backward. Comments of Johnny Stenback are IHMO correct. Therefore I suggest not to commit my patch. Instead, in addition to document.all more extensions should be implemented. I propose: - All the extensions emulated in http://webfx.nu/dhtml/ieemu/ieemu.js That includes document.all, window.event element.[outer,inner][Text,HTML] and many others. - element.style.pixelTop and element.style.pixelLeft - document.all.tags["a"] - a little cumbersome, but not difficult. I am convinced that with these extensions the vast majority of sites would work.

A question: Johnny Stenback told that emulating IE event model is quite difficult. However, by reading webfx.nu I get a different impression. So I guess that some parts not covered there are the difficult ones. What features of the event model are difficult to emulate?

let me chime back in on the benefit of a per site emulation of either IE or NN4 vs changing Mozilla to support either proprietary DOM. I am definitely against changing Mozilla's DOM to add document.all or document.layers however there is a place for an emulation library on a per site basis. If you have a site that was coded for IE4/NN4 with several hundred or thousand pages, then it is a major undertaking to update your content and not a trivial task. The availability of an emulation library that would allow you to support Mozilla with the simple addition of an external script file is a good thing. Your use of an emulation library in this context does the web at large no harm and improves the availability of your content. As you and your developers learn more about the newer standards and the older browsers die off (which they will just due to security exploits and lack of support), then you can use the modern standards. If you don't learn the modern standards you will be left behind by your competitors who do. So, please don't flame these people who are trying to create emulation libraries. The libraries have their uses and abuses, but they do serve a purpose especially with regard to legacy content. Ramon, I think it would be good if you were to try to help the development of such compatibility libraries with the understanding these are crutches which should not be used except with the intent of supporting legacy content. my $0.02 Bob

Bob, if your disagreement with implementing document.all is that it would damage the web, I think that there are better ways of encouraging standards. In a previous post, I suggested that, when those extensions are detected, a dialog box should be displayed saying "This site is programmed incorrectly". Thus you would be damaging the brand of the site, creating the impression that their designers are incompetent. By contrast, if the site does not work with Mozilla, the average user will blame Mozilla (or does not care) and will switch to Internet Explorer.

> However, by reading webfx.nu I get a different impression. I just took a look at http://www.webfx.nu/dhtml/ieemu/ieemu.js and unless IE's event model is completely braindead the webfx.nu window.event code is broken. In particular, consider an event handler that does something like function handleEvent() { // 1) do something with window.event // 2) manipulate the DOM some // 3) do something else with window.event } Now the DOM manipulation in step #2 will fire mutation events that may rebind window.event if something is listening to such mutation events. Then handleEvent() will see different objects in window.event in steps #1 and #3. Is that the behavior of IE?

Comment #32 Thanks. I see. According to the MSDN documentation, window.event is only accesible during event handlers. However, that is not very difficult to implement. It means that window.event has to be created inside the scope of the event handler, just before invoking it.

That doesn't really answer my question. handleEvent() _is_ an event handler in my example. My question is, in IE does a new value of window.event shadow the old value (with the old value being restored when the new one goes out of scope)? Or does it override the old value?

Replay to comment #34 > My question is, in IE does a new value of window.event shadow the old value (with the old value being restored when the new one goes out of scope)? Exactly. Each event hander sees a different window.event. The actual implementation would be function real_event_handler(Event e) { ModWindow.prototype = window; aModWindow = new ModWindow; aModWindow.event = e; window = aModWindow; user_event_handler(); } That is, the event handler views a modified version of the window object, specific for its scope, that has the property event.

Personally I think this is a dupe of 74201.

Ramon - Why not make this a project at mozdev.org?

I think that the default Mozilla should include these extensions. We must accept the dynamics of the market. That is, if most end users browse with IE web designers will design for IE; and if end users find that IE works with more sites that Mozilla they will use IE. One may not like it, but it would be irresponsible not to accept it. It is like gravity, one must live with it. All those products that did not accept this rule failed (to a different extent), even being technically better: the BeOS operating system, the Beta video system, the RISC CPUs.

> the RISC CPUs. Bad example.

if (document.all) { // layout code tailered to msie-specific css bugs } else if (document.getElementById) { // perfect css coding here :) } // oops, someone broke my code ?

Yes, implementing document.all will require implementing more extensions. In addition it should be tested that the number of sites that work thank to the extensions outweigh the number of sites that are broken because they test for document.all to learn that specific code for Explorer. It is a difficult problem, but that cannot be an excuse for not solving it. As previously discussed, in a world where Internet Explorer is dominant, if Mozilla is not compatible with it will be locked out because lots of pages will require Internet Explorer

Reply to comment #32 IE binds the event to the window object before entering a js event thread. Any changes to the DOM in this thread that will cause new events are executed in new js event threads after the current thread is finished. Therefore the window.event will be rebound to a new Event object. I was almost sure Mozilla behaved in the same way. Finishing the first js thread before entering the next... I'll have to test this.

Putting Mozilla policy and evanglism to one side for a moment and dealing with the technical issue at hand: I have a partial solution to some of the problems raised above. _If_ these IE compatibility features were to be implemented (partially or otherwise), of course they should *not* be enabled by default, the user should be able to enable them on a per-site basis. This is the opposite of what is described by Ramon in Comment #20 - we should keep a list of sites that this moot functionality is /enabled/ for. It would also make sense to make it /completely/ impossible for the user to _globally_ enable these non-standard extensions. If IE DOM compatibility were to be implemented/controlled in this way, then code similar to that shown in Comment #40 would still run 100% as intended using the strictly W3C Compliant DOM -- but.... if a page fails /and/ the user chooses, they could enable IE DOM compatibility mode for that site, *at their own risk*. This should make more of the web accessible to Mozilla users, without breaking all the hard work that has gone into the W3C compliant DOM. I do completely understand the resistance towards these proposed features, but /if/ they were to be implemented in a /well thought out/ fashion, wouldn't it be possible to make them not only work, but work well? My tuppence worth. [/me ducks and runs for cover..]

Ignore my last comment. I should have verified my thoughts before adding them. Both IE and Mozilla evaluate the handlers directly. All the event handlers are being run in the same js thread. This means that IE is keeping some kind of stack to not overwrite the Event object when an event handler is interupted by another event.

Please take this to the newsgroups! And for those of you cc'd on this bug please remove yourselves. I watch several of you and get bugmail from this thing all the time. This won't get checked in without review and we know that won't happen, so lets just let it go and get back to work.

giving a "true" on 'document.all' would break way more pages then you get to work with it, until we would support this 100% - especially their event-handling. Most webdevelopers - at least here in Germany - are currentlich starting to understand, what document.all is outdated and use it only to determine if they have it to do with a MSIE to add workarounds for all it's bugs. For DHTML they more and more use W3C DOM only.

The people requesting this could always just point the offending 'web designer's at http://www.metalusions.com/backstage/articles/8/ or similar, as such a simple fix will even suit minds as simple as theirs.

The next weekend I will try to write a new patch with more features: * event model. * HTMLElement.currentStyle * style.pixelTop and similar * document.all.tags My time is limited, so I cannot promise anything. Is anyone using element.innerText, element.outerText, element.insertAdjacentHTML? And using () instead of [] for accesing collections? Other features of Internet Explorer are more difficult to implement. For example CSS behaviours, where one can attach new events and event handers to objects by CSS. Another is Drag and Drop. Fortunately, no one seems to be using these features. Cross fingers. After writting this patch, I will test it with some web pages to see if defining document.all introduces incompatibilities with too many of web pages. I am concerned about incompatibilities due to subtle behaviour differences, as suggested by Johnny Stenback. Ramon

> Is anyone using element.innerText, element.outerText, > element.insertAdjacentHTML? And using () instead of [] > for accesing collections? For each of those features, I have seen at least two evangelism bugs where the site uses it... :( > For example CSS behaviours, where one can attach new events and event handers to > objects by CSS. This could probably be emulated by XBL if we really cared to...

Ramón: forget this at all, if you won't be _100%_ compatible! Imagine, that most (if not all) people understanding this expect us _not_ to do document.all!

Status report: I took me all the weekend to implement window.event. There is a bug in my implementation. As soon as I fix it, I will post a new patch. The issue with window.event is that is has special semantics. window.event is defined in a function when it has been called from an event hander. But in Javascript, the scope chain (the list of contexts that are visited to determinate if a variable is defined) depends on where a function is declared, it does not depend on where it is called from. My solution is, before calling any Javascript event handler (dom/src/events/nsJSEventListener.cpp, HandleEvent ), a new global object is created. Then, when window.event is resolved, (dom/src/base/nsDOMClassInfo.cpp, WindowSH::{NewResolve,GetProperty}) the code queries the global object for window.event. In this way window.event is defined only if the function is called from an event handler, and it is that event. I am concerned that properties of an object are cached, and therefore window.event might continue being defined even when not being called from an event handler. Any suggestions? More important, am I implementing the correct semantics of window.event? Code in nsJSEnvironment.cpp complains that "Global is not an nsISupports", but that is not difficult to fix.

FWIW, I'm going to push for the CSSOM spec to have element.currentStyle ...be defined as equivalent to element.ownerDocument.defaultView.getComputedStyle(element, '') So we might end up implementing that as spec-compliant anyway. If someone is willing to implement the majority of the IE DOM, I say go for it. But then I'm not going to be the one doing the evangelisation work, so...

On first look it might seem that currentStyle is the same as the computedStyle. I even thought it was when I did the IE Emu. There is one major difference. currentStyle always return the CSS property value that is applied to the element. This means that it returns the cascaded value, not the computed value. The easiest case is if there is a global stylesheet where the width is set to auto and there isn't any other css overriding that, then currentStyle will return auto. getComputedStyle on the other hand will always return an absolute value such as 200px. On the other hand I would say that IE's runtimeStyle is identical to W3C's getOverrideStyle but since Mozilla does not implement this part of DOM2 it will not help in this case.

It returns the cascaded style? Interesting! Thanks for the info.

getCascadedStyle vs getComputedStyle: http://lists.w3.org/Archives/Public/www-dom/2000AprJun/0112.html

Most web developers do not actually write their javascript code, nor do they actually understand them. They just download scripts from javascript.com or dynamicdrive and plug it into their site if it suits their needs. I think a better solution would be to offer a .js file that they can add to their site that would serve as a wrapper to make IE DOM work. This will keep Mozilla "clean" and strictly w3c compliant, and yet offer alternatives without having to add unnecessary extensions to the web browser.

On a sidenote, if the developer used if (document.getElementById) { // W3C compliant code here } else if (document.all) { // MSIE code here } Then it would work regardless of whether Mozilla supported document.all or not. If we supported a partial implementation of the IE DOM and then our Evangelism Team taught webmasters to check for the standard DOM /first/, then more websites would work in Mozilla. It would also make the evangelism effort a bit easier.

ust my 2 cents... Bamm: we can do that. IE does not support all the DOM. So your solution would lead these developpers to have the problem you're trying to avoid to mozilla with IE. Not to mention that its not possible to tell them to do this or that. we can give them orders. trying to get them to support the DOM and such is already a big thing. they are beginning to move. lets not waste this now...

I am rather delayed. The next weekend I will try to implement document.all.tags and have window.event working. It seems that many parts of the code expect the global object to be a native object that implements IScriptGlobalObject. So this should not be changed. (Recall that window.event is different in each invocation of an event, in particular events generated during the handling of other events must work). Instead of modifying the global object, I will implement window.event by having a stack of events. When the window.event is queryied, the last element is returned. This should work fine. Implementing event.offset{X,Y} for mouse events will be a headache. In Mozilla, the document and the view are separated. Therefore, no DOM element has information about its position in the screen: it could be different for different views. (element.offsetX is a hack that assumes the first view). This means that implementing event.offsetX requires dealing with presentation interfaces like IPressContext and IPressShell. I never had to deal with these. Another unrelated topic. Sometimes one uses element.style.background to change the background of an element. However, removing that property of assigning it to undefined should restore the default background. This does not happen. Should I report a bug, or this is another MSIE extension? Example: element.style.background = 'red' // Ok the background changes to red element.style.background = '' // Does not work. It is still red. element.style.background = undefined // Does not work. It is still red. delete element.style.background // Does not work. It is still red.

The background thing is essentially bug 52531 (that's about border, but the underlying problem is the same).

Thanks, I was looking for a bug report for this problem, but I could not find anything.

A proposal. The most important reason against implementing document.all is that many sites would be broken because they check for document.all and then assume Internet Explorer. I propose a solution: having magic that, although document.all exists, it is evaluated as false, that is: if (document.all) { } else { } the else path is executed. However, most sites with troubles assume either Internet Explorer document.all or Netscape 4.x document.layers. This means that evaluating document.all to false requires implementing document.layers, which is far from easy. Bob Clary has developed an emulation of document.layers in javascript that should not be difficult to be used as basis, assuming that the layers are in <DIV>, which is the case for any page that pretends to be rendered correctly by Internet Explorer.

Another problem: some sites (notably Microsoft.com) provide a degraded version of the page if document.all is not present (among other features). Therefore, there should be a database of sites with different degrees of emulation settings.

Mat: It appears that IE6 has good support for the standard DOM. I base this on the observation the all scripts on www.getElementById.com work on both Mozilla and IE6 without any forking. So my suggestion still stands. And if there are a few sites that break down in IE, then it's Microsoft's fault and I'm sure they are working on their deficiencies in this area. As another side note, Ramon's comment #62 sounds like a good idea.

Bamm : last time I checked, IE did not support anything in DOM 2 CSS and had many bugs in DOM 2 core support. IE5 supports getElementById too btw. and its dom support is even worse.

Comment on attachment 89399 [details] [diff] [review] Implements some Internet Explorer extensions. If you want this to be considered, please create a patch that has 100% support and is bug free

In replay to comment #66 I will do, but my time is limited. Please understand I can work for this on weekends only.

Also in replay to comment #66 I would like to know your opinion to my proposal in comment #62

The proposal in comment #64 would do more bad than good. A common coding style is this. var all = document.all; var l = all.length; for (var i = 0; i < l; i++) doSomethingWithElement(all[i]); Other things that talks against it is that it would break the semantics of JavaScript and would require a hack in the JS engine. document.all should be an instance of HTMLCollection

A summary of thoughts: http://www.mozilla.org.uk/docs/proprietary-features-bad.html . Gerv

Replay to comment #69 I did not explain well my idea. It was too ambiguous. I stated the purpose, but not the exact behaviour. My idea is that document.all returns an object that, when evaluated as boolean, it returns false. Ramon

Clarification of proposal. It seems that the proposal of comment #62 is not clear. I tried to clarify with comment #71, but some private mail convinced to me that I did not succeed. The idea is that the document.all object object has a flag, so that when it is used in a boolean context or converted to boolean, the result is false. Otherwise it is a normal object. So var t = document.all; t["id"] .. would work without problem.

Trying to implement the Internet Explorer DHTML Object Model is not something that is viable to do. Even if support for document.all and all other issues are fixed that have been discussed in this thread I can still list at least twice as many unsolved issues where Mozilla will not be compatible with the IE DOM. I think it would be better if all the energy spent on this bug was spent on areas where Mozilla needs improvements. I strongly feel that this bug should be marked as WONTFIX. Ramon, I think you should file separate bugs for the different parts. Some of these features are still wanted (maybe not always in the IE form but the at least a similar feature).

"Even if support for document.all and all other issues are fixed that have been discussed in this thread I can still list at least twice as many unsolved issues where Mozilla will not be compatible with the IE DOM." What kind of issues?

There are way too many issues to mention them all or even claim that I can find them all... I'll just list a few that come to my mind (the ones that heve not been mentioned before). Selection, ranges and execCommand and all those MSHTML editing commands and features Behaviors Default behaviors Drag and drop model Clipboard model Databinding model Client information model Persistance model SMIL model VML model CSS custom attributes currentStyle and runtimeStyle expandos on HTMLElements do not work the same Filter model external model iframe extensions uniqueID popup model XML data islands focus model modal/modeless windows event capture model print model Oh... I am the author of WebFX (IEEmu) and I've been working with both IE and Mozilla since day one and I would say that being 100% compatible with IE is not just possible. Not even MS can do it for their Mac version. I would suggest that you pick your favorite parts from the list above, where Moz does not provide any kind of support, and concentrate on that instead.

I agree that this is futile, it would require so much QA that its not viable imho. YOu are also forgetting the times IE is over linient, which I doubt we can emulate (I've seen some wierd stuff that works in IE like having the value of an attribute before the attribute name). If we were to support a legacy DOM, we should provide backwards compatability with 4.x (we already support its the event model).

*** Bug 57366 has been marked as a duplicate of this bug. ***

Ramon, in the hopes of saving you time, it appears that you are fighting an uphill battle. The module owner, evangelism team, and random other key people to the Mozilla community disagree that we should do this. It might serve you well to accept that fact, and help us in other areas if you so desire. With every day that passes, this becomes riskier and harder to implement: More users are downloading Gecko based browsers daily. Mozilla 1.0 has already been released; Netscape 7 will be released soon. Both of those browsers are/will be really good. I strongly believe that they are good enough to gain user acceptance en masse. Sites are already moving to code for standards and away from document.all. CNet was hard pressed to find sites that break with us because we don't support document.all with the exception of a Microsoft site (go figure). Why should we all of a sudden change one of most fundamental pieces of the way our browser works?

In replay to comment #75 about the complexity of being compatible with Internet Explorer (and to other commets suggesting me to save my time). Let me remind you that I am in your side against the Microsoft monopoly. I am doing this to fight a dangerous extension of that monopoly to the web, with very difficult return once it gets consolidated. At present we have the following dynamic in the market: Most users use Internet Explorer (about 91 %), very few (2 %) are using Mozilla or Mozilla derived browsers => web authors develop for Internet Explorer and use Microsoft extensions => Users see that many pages do not work with Mozilla => they use Internet Explorer => and the loop starts again. Unless we figure out another way of breaking this loop, there is no option apart from being compatible with Internet Explorer. All the problems that come with it (compatibility issues with enabling document.all, diffuculty of implementing) have to be handled in the best posible manner. But it cannot be an excuse for not solving a problem just because it is difficult or takes a lot of work. I think that the problem is more severe in Spain, where practically no commercial web site can be used with Mozilla. But news such as http://news.com.com/2100-1023-941926.html, and the fact that AOL will bundle Internet Explorer with AOL 8 (in Eweek http://www.eweek.com/article/0,3658,s=720&a=28012,00.asp ) makes me think that in the USA the problem exists, though somewhat less severe. The solution that I propose: * Implement those extensions that are popular enough. * Solve the compatibility problems associated with enabling document.all according to comment #72. This implies implementing document.layers. My experience is that this is enough for most sites. Even with my limited patch I can browse most sites that were previously blocked for me. I can be wrong, however, and when I will finish my patch it will be tested against a large enough number of sites. One of the complains is that many extensions are not well documented, and many corner cases will appear where the behaviour is not compatible with Internet Explorer. Let us look at the experience of other open source projects that had to do reverse engineering. Samba had to reverse engineer a fully undocumented protocol, the Windows NT 4.0 domain protocol. They had all those problems of exact emulation, but an order of magnitude more difficult because there was zero documentation. It took their time, but the succeeded in blocking the Microsoft monopoly in entering the server side. Another complain is that Internet Explorer is a moving target. I disagree. Let us try to put ourselves in the shoe of a web author. He sees that about 34 % of hits come from Internet Explorer 6. Will he use features that only work with that browser? I do not think so. In fact, very few sites require more than Internet Explorer 4. I hope that this helps to clarify my position. PD: The references above come from www.mozillanews.org

Ramon, i understand that You're thinking about Mozilla as IE extension. You're saing that Moz should agree with IE domination and use their standards. If so, Linux should be Windows extension, Star Office -> MS Office and every WYSIWIG HTML editor should be a copy of Dreamweaver. When MS decided to build their browser (IE 1) they knew that Netscape 2 have 95% of the world, but they forced their standards. Mozilla's power is hided in maximum standard compatibility. I dont want my Mozilla to use ALT instead of Title, document.all or marquee. Last thing. Implementing IE DOM would take many, many months of work. I think that it's better to spend this time on some improvments.

> When MS decided to build their browser (IE 1) they knew that Netscape 2 have > 95% of the world, but they forced their standards. That's not true. IE implemented every NS3 quirk they needed to make their browser compete. They even made their broser report "Mozilla" in their UA string, for god sake!

Sure??? Then probably you're right. When did big, big, big differences appeard??? (DOM,JS diffs,HTML diffs)?

At the risk of extending the discussion in this bug yet again, can I suggest that most of the arguments put forward for IE compatibility have little value? The argument for document.all() is dead. This bug should be WONTFIX. It was reported more than two years ago by the Web Standards Project that the vast majority (over 95%) of Web developers are using productivity tools like DreamWeaver (or similar) for their HTML. Since these tools auto-generate created HTML through their built-in knowledge of browser compatibility options, arguments for or against document.all() are a waste of time. There are not that many web developers that code by hand. The code is mostly made by a 3rd party tool, not a developer. This argument also applies to various productized Application Server Platforms and back-end content delivery systems. All that is required is that Mozilla present an OPTION that these document generation tools can exploit, and it does. Then we wait for an upgrade to those tools so that native mozilla support is catered for. Because of this, there is little argument for exact compatibility at even the basic HTML level any more. There is enough rough compatibility for 3rd party tools to make the rest up, and thus solve the "browser problem" for their customers. Furthermore, such tools have an investment in NOT generating standard code ("our generated code is better") in order to impress their customers. So they are not going to "clean up" their act. Their act is already the way they want it. That is not to say that lack of HTML compatibility is a Good Thing. It is merely saying that it is not the issue it once was. It's a lame duck. At this point one might offer the theory that these tool makers are somehow in league with Microsoft and will never support mozilla. That is a conspiracy theory, and such theories are famously almost never correct. It is rubbish. Some benefits of Mozilla's close standards support are: 1) a good feeling inside; 2) a defensive tactic against IE ownership of the desktop extending back to the server, now part-visible as .NET, 3) an expectation that with maturing Web standards, some government will eventually make standards compliance a buying requirement (as occured for SQL long ago), and 4) that some consortia of commercial companies will eventually arise that needs XML/DOM-based infrastructure to also be supported in browsers. An example of 4) might be support for OpenOffice XML document formats. None of these mozilla benefits support a document.all() implementation. In fact all 4 arguments require that document.all() be avoided. In particular 3) and 4) (which we might all want) would be delayed by the addition of document.all() since those needs would receed further into the future. Mozilla's benefit has always been long term. It is better to suffer a few unreadable websites in the medium term until the dust from the Internet Boom settles than commit to short term featurism. And if that's not enough, then Ramón, there are concerned people like you on the other side of the wall (in content delivery companies) pushing for Mozilla support for their broken web sites too. They know what they're doing is not working everywhere yet. Please can this bug go away.

Nonstandard HTML should not be supported. Any nonstandard HTML that Mozilla currently supports should be weened out as people learn the correct way to write code. Proprietary tags and DOM has created a mess that can only be fixed by following the standards. As people write pages, they will follow the means that works on the most browsers available, which hopefully eventually will be the W3C standards. Anyway... Mozilla and Netscape are gaining market share and IE's market share is decreasing. I guess that makes sense though since IE's share used to be upwards of 70% and it couldn't go much higher. Ramon: You have to be careful with browser statistics. Unless it had the stats for every page on the internet, it cannot be 100% accurate.

jst: Can we mark this WONTFIX?

As long as Ramón owns this bug it's up to him to decide whether this should be WONTFIX or not.

jst: But would his patches be accepted by the module owner (who IIRC is you)?

I have finally a working implementation of window.event, with proper support of recursive events. When I finish other details (mostly trivial) I will post a new patch. Answering comments against document.all, I think that most of them show a respectable but emotional point of view. An average computer user in Europe is blocked from using Mozilla/Netscape 6.x because of the number of pages that are do not work. For instance, sites as important as Renfe -- Spanish railway -- (bug #97457) or Iberia -- Spanish airlines -- are (bug #143107) . And so the natural reaction of users is not to use Mozilla. Just that we do not like reality does not mean that we can ignore it. I have little faith in Evangelism. It may work for a site that accidentally was not updated when Netscape 6 was released. But if a site was developed ignoring Netscape 6/Mozilla, for whatever reasons, the mind of web authors will not change just because Evangelism sends a letter. For exampe, services such as www.listen.com, that may become important in the future, that are Windows and Explorer only. With regard to the use of tools that might be fine for new web sites, but existing content will not change. Not to mention Microsoft Frontpage, that will not generate contnet that supports standards. And very few of the evangelism bugs are because of automatically generated content. I confess that I can't understand the rest of coment #83 . In replay to comment #84 "Anyway... Mozilla and Netscape are gaining market share and IE's market share is decreasing.", what have you noticed that makes you think so? The statistics of Google, that shoud be quite representative, since everybody uses Google. From www.google.com/press/zeitgeist.html 1,7 % Internet Explorer 4 3,6 % Netscape 4.x 7,0 % Others 25,2 % Internet Explorer 5.0 25,2 % Internet Explorer 5.5 37,4 % Internet Explorer 6.0 So Internet Explorer is 89.4 %. Note that Windows users are 90 %. In addition the plot shows an increasing trend in favour of Internet Explorer: 81.4 % (June 2001) => 88.1 % (March 2002) => 89.4 % (June 2002) In conclusion, since the compatibility problems about implementing document.all are resolved, I see no reason for not implementing the proposed compatibility with MSIE. Finally, jst told me in IRC why 100 % compatibility with Internet Explorer event model makes the browser incompatible with standards. MSIE does not generate events for text nodes, unlike Mozilla. However, this problem only appears for some events such as mouse entering and mouse leaving, that are used for aesthetical purposes such as making the font larger when the mouse enters. I do not thing that these minor problems are worth changing the behaviour of Mozilla.

> An average computer user in Europe is > blocked from using Mozilla/Netscape 6.x because of the number of pages that are > do not work. For instance, sites as important as Renfe -- Spanish railway -- > (bug #97457) or Iberia -- Spanish airlines -- are (bug #143107) Nonsense. I live in Europe; I use the web *a lot*; and I very, very rarely come across sites that don't work in Mozilla. And when I do, it's more often because of ActiveX or proprietary CSS features than proprietary DOM features. Or does Europe suddenly equal Spain? We should be decreasing the number of supported proprietary features, not *in*creasing it.

Replay to comment #89 "I live in Europe; I use the web *a lot*; and I very, very rarely come across sites that don't work in Mozilla." Sure, most of pages work with Mozilla, but the ones that do not work are the transactional pages (banks, e-commerce) that one is forced to use. Thus I stand that the average user is blocked from Mozilla. I based my conclusion in querying the bug database for product "Tech Evangelism" , and "[eurocontest]" in Status whiteboard. The list of sites that cannot be used Mozilla is quite impressive. In fact, I think that the reason for the eurocontest to exist is the lack of support for standards in commercial sites in Europe.

Reply to comment #90 As the owner of [eurocontest], I have to answer this. If we implement document.all & stuff, this will stop for sure the tendency of web sites to use standard code, waiting for us to implement all MS proprietary stuff. Therefore, I do not want Ramòn's stuff to be checked in. I completely agree with Bob Clary's position on this issue. Ramòn, if only you could put your impressive energy to evangelism in Spain, that would bring your country to par with other european countries such as DE, FR and UK.

Jonas, that depends on what the overall result of Ramon's patches are. If he manages to come up with a solution that helps us more than it hurts us, and the majority of the people involved, especially the tech evangelists, agree that whatever the solution might be is something we want, then of course I would accept the changes.

Replay to comment #91 "If we implement document.all & stuff, this will stop for sure the tendency of web sites to use standard code, waiting for us to implement all MS proprietary stuff." I am not sure if you understood me. I was saying that the motivation of the eurocontext is the low compliance with standards in European e-commerce sites. Is that true? On the other hand, if by implementing my (not yet released) patch most of the sites work, of course, there will be no incentive for not using them. But how much incentive is there now, with a browser that is used by 1-2% of users? It does not matter much whether document.all works for 90 % or 91 % of users from the business point of view. Maybe in the USA AOL has a lot of power. You tell that after applying my patch some rare sites do not work because they use some unsupported extensions. Ok, but that sites are rare. I have not yet seen any evangelism bugs because sites that use CSS behaviours, VML, filters, ActiveX controls or other very difficult to implement stuff (cross fingers). (An exception is the Windows Media Player control) Anyway, before proposing a patch I will perform testing against all fixed and non-fixed evangelism bugs where it is posible, and we will see the results. "if only you could put your impressive energy to evangelism in Spain" After trying to evangelize some sites, I do not have much faith in Evangelism. I have filled an evangelism bug and provided contact info to others. But, why would the will of a web author change just because receiving a letter? We cannot force them to do this or that. Look for instance, at the site www.listen.com. The site is designed only for Internet Explorer and Windows, in fact it uses ActiveX controls, installs a Windows application in the desktop and so on. They think that providing a better user experience is more important than the ~ 10 % non-Windows users.

Tristan Nitot is 100% correct. It's better to not support ANY of the proprietary IE DOM rather than support only a part. Once you START supporting ANY of it, then your argument against standards based DOM goes away. They'll ask, "Well, why won't you support Foo? You already do Bar and Baz." This way, with NO proprietary DOM cruft, our integrity is maintained, and the argument for compliant code is sound. Already many sites are moving away from IE-only code. MyDiscountBroker.com's member section used to be painful in Mozilla/Netscape6, but since the around the time 6.2 was released, they redid their member section to support NS6/Mozilla. This is NOT one of the major sites like E*Trade, Ameritrade, etc. I know first hand about some banks changing to more standards compliant code specifically for the users who use Netscape6. Many corporate IT people feel that with 6.2 and the upcoming 7.0, Netscape will become much more prevalent than it is today (not just on the desktop, but in portable devices), as will other non-IE devices, and that it is in their best interest to move to non-proprietary designs. Adding IE proprietary features will only further serve to entrench poorly written sites. Further, adding in IEDOM functions will onlyy hurt us in the long run, as these poorly written sites continue to use IE-only features, and MS can continue to move the football, ,adding in new features that we would be left scrambling to support. Without adding in this stuff, we're forcing the battle to be played on a level playing field. If we add IEDOM, we bow to them, and they have, and keep the upper hand. We either suffer a little pain now (IE only sites break) or we suffer much more later (IE becomes more entrenched, making the web merely an extension of Redmond). It's time to break away and stay that way.

I'm sorry, but that's not entirely true. A browser that supports written down standards and nothing else would fail to load pretty much every web page out there, just look at all the absolutely required DOM0 stuff that Mozilla supports. All the DOM0 stuff is non-standard as far as written-down-by-a-standards-body goes, but it is very much a defacto standard, which every browser out there must implement to even have a "window" object, which is the base of the whole script environment and the DOM in a browser. And, we've already, a long time ago, taken the step to supporting some IE-only features, .innerHTML, and the .scroll* properties and methods, to name a few, so we're past that line already. So IMO taking one more step, *if* it fixes more than it breaks (this is the million $ question in this bug) is IMNSHO not a bad thing to do. IOW, Mozilla is *already* full of "proprietary DOM cruft", and there's nothing wrong with that, so supporting more "proprietary DOM cruft" should not be dicouraged on those grounds. It's a well-known fact that already written down standards don't always go far enoug, sometime you need to go further.

> But, why would the will of [a web author] change just because receiving a > letter? If the success of the current evangelism team isn't enough for you, ask Amnesty International that question. Letter writing campaigns work for prisoners of conscience - they can certainly be made to work for web pages. http://www.amnesty.org.uk/amnesty/aiworksarchive.shtml - grep for "200". Gerv

As a formet member of Amnesty International, I can vouch for the effectiveness of a letter. Also, as a former member, I think that the threat of implementing more of the _bad_ IE DOM (innerHTML and such is debatable, doc.all is bad) in Mozilla counts as political terrorism, and we should get AI on our side to keep this stuff out. "Free Mozilla from IE Terror!" ;)

In the case that you mention, goverments are incentivated to respect human rights not because of the letters themselves, but because letters are a symptom that shows that the public reputation of the State is damaged by its actions. The effect cannot be applied to the usage of document.all . The public concern caused by torture is orders of magnitude higher that the caused the usage of document.all, and with a good reason. The reason against document.all is emotional, the bad feeling associated with doing something like Micro$oft. It makes one feel like touching ****. The comparison with Amnesty International illustrates this. However, by implementing now a limited subset of MSIE DOM (the one that is frequently used) we gain access to larger number of users. Once we get, say 10% of users the we will need no more propietary extensions, because that number of users generates the incentive to web authors for being compatible with the established user base. This is, of course, a very difficult task with a browser that is preinstalled with Windows (is IE preinstalled with Macs?). On the other hand, the issue of frequent usage of extensions seems to be less frequent in USA than in Europe, and I understand that some Mozilla developers do not feel that the problem that Mozilla users are having is serious.

*** Bug 162037 has been marked as a duplicate of this bug. ***

bla bla bla, don't implement it, it's old it's BS and we don't need it, we have evangelism for sites that don't work and we got the wonders of getElementById, also there are several scripts available that emulate the IE DOM, as far as i'm concerned that's already more than we want, because it encourages Lazyness, come on move forward and forget about document.all! Extensions more used in Europe compared to the US?? where are those figures? Can you show me any evidence? It's only going to cause more trouble in identifying what the browser is capable of, second document.all is twice as slow as getElementById, so there is no performance gain in this implementation. I'm a developer and i'm happy with the current (excellent) implementation of DOM scripting, the fact that we have something called DOM 0 is easily explained by the fact that W3.org didn't had any documentation on this while the browsers already implemented it hence the fact that it's become a standard. Oh and why not implement document.layers while we're at it. If AOL wants it in Netscape they are ofcourse free to do so, but let's keep our browser free from these 'features', in this case it's not a feature but a bug... one that needs to get the label WONTFIX ASAP. It's not a personal attack Ramon, but IMO Mozilla supports too many proprietary tags already, the line has to be drawn somewhere. That commercial sites in Spain don't work is incredibly stupid especially if you're talking about commercial sites wich should work in 'every' browser, else you lose money plain f*cking simple as that. I work in Amsterdam and can't find one Holland based commercial site that doesn't work in Mozilla, so in this specific area developers need to enhence their knowledge about web standards, don't blame the browser. We had one site (Train info) that rejected browsers like Opera And Mozilla, but they got flamed so heavily, that within a week it was accesible to the ther browsers.. the power is yours.

Ramón. Tell me please: 1) How we can belive that in near futhur percent of good way writed pages will grow after Your patch??? 2) When (what has to happen) it'll be possible to remove Your patch??? Never?!? With this patch i dont see any reason to use proper ways if i have IE ones. IE DOM is "better" than W3C, because it works with both Moz (and MANY Moz based) and IE. 3) "Mozilla is an open-source web browser, designed for standards compliance, performance and portability." - we should change this sentence??? 4) Why You're using numbers from your mind??? I'm living in Europe. In Poland. I'm using internet above 13 hours per day. For last 5 months i use only Mozilla. Percent of "IE only pages" i met is about 2-5%. Most of this is a problem with transparency background in Flash. 5) Mission&Idea of Mozilla will be hardly broken by your patch. What for? We want to change WWW to standard compilance, or just gain users in cost of everything??? Since my adventure with Mozilla started, this bug is most annoying for me. I'm very afraid of consequences which You pass over in silence. This is small patch which will probably totally change Mozilla as an Idea and as a browser. It's not emotional. It's logical. "The reason against document.all is emotional, the bad feeling associated with doing something like Micro$oft" - NO! The reason against doc.all and such is the bad feeling associated with everything not standard. Which is hold by one company . When IE7 will be relased. And will hold next non-standard extensions, will we add them too???? Will we forever add everything from MS? If not, then how long?

Please, stop bitching around people, you are just repeating eachother and what we have already said. Go triage unconfirmed bugs if you have time to write such lengthy posts.

Is there a newer patch for this? I am preparing a Mozilla-based browser for inclusion in the Bayanihan Linux project (http://bayanihan.asti.dost.gov.ph/) and I'd like to have this in there for greater IE compatibility. We intend to distribute Bayanihan to some government offices and public schools in the Philippines as a replacement for Windows (due to its high license costs) and we hope to make it as acceptable as possible to end-users who are used to Windows and IE.

To Comment #103 Sorry for the delay. I have a patch against Mozilla 1.1beta, but I did not publish it. It contains a partial implementation of window.event, but it fails in some cases. I would like to fix its bugs and porting it for Mozilla 1.1 before publishing it.

I highly doubt mozilla.org will accept a patch btw

We should have been long past this discussion. There is only way: Webstandards. WONTFIX this bug ASAP!

Ramon, do you have a patch that will work on 1.0.1? Our distro will be based on this build. What are the capabilities and limitations of your patch? Please email me privately so we don't spam this bug. Thanks.

**Before I begin, I might get a little heated. I am sorry in advance.** This is the most off the wall piece of **** I have read in a long while. Reporter: If you want a Mozilla that supports the IE DOM, download the source, put the patch you have into the source, and compile it. Feel free to release your tainted Mozilla. That's the beauty of open source. IMHO, it would be first class lunacy to support ANY part of the IE DOM. Mozilla has always been committed to STANDARDS. If we adopted the IE DOM, we admit that we aren't serious about STANDARDS. I fear If we adopt the IE DOM, evangelism by the Tech Evangelism people will be laughed at or ignored. If we adopt the IE DOM, we will be saying in effect that proprietary formats are ok. I came to Mozilla to escape proprietary format hell. To quote Ian Paisley, "Never, Never, Never!" For these reasons and more, I encourage the people involved to mark this bug as WONTFIX.

We already support many parts of the IE DOM. In the real world you have to, otherwise the majority of the web just wouldn't work.

The module owner has WONTFIXed bug 74201. Shouldn't this bug be marked as a dupe of that one?

I suppose it should, yes. marking as dup. *** This bug has been marked as a duplicate of 74201 ***

Now that Microsoft has officially stopped developing standalone versions of IE, this browser has lost its "moving target" status. It might be a good idea to reconsider the status of this bug. When browsing sub-standard websites, wouldn't it be better to let users access these sites rather than to force them to open IE (and boot into Windows)? An offending text explaining that the site is built using proprietary methods might do the trick and convince co-operative webmasters that their sites need to be redesigned. Heck, we could even display that message in a red statusbar or a popup, in such a way that no-one will be able to ignore it. See http://mozillazine.org/talkback.html?article=3244 - "Internet Explorer 6 Service Pack 1 to be Final Standalone Version"

> this browser has lost its "moving target" status Not really. No standalone versions does not mean no new versions. It just means the new versions will come preinstalled on 99% of the new desktop systems being purchased.

Unlike in the past, Windows users won't be able to upgrade IE without upgrading the OS. This in turn, will prevent Microsoft (and websites) from switching everyone to new, proprietary methods. When did MS introduce its last proprietary extension? when will it be able to effectively introduce one in the future (now that IE7 will be out of the reach of most users)? In short, IE's moving target status is indeed mostly gone. This should be good enough reason to except Ramon Garcia's patch. Prog. Prog.

If anything, that's reason NOT to accept it, as without the push of new IE versions, people will not upgrade (en masse) to new IE versions, and will most likely increasingly want to try other "new" browsers when they hear about IE7 not being available for their systems (wanting to be up-to-date and all). Other browsers, like Mozilla, Opera, et al, stand to gain, as will the web as a whole. This will encourage development of standardized pages, not more proprietary crap. But this won't happen if we bow NOW to IE's proprietary crap. If anything, this is somewhat of a concession.

> When did MS introduce its last proprietary extension? When IE6 shipped. They will likely introduce the next one when the next version of Windows ships. So?

And when will be next Windows release? In the middle of 2005. So we have 2 years to promote our borwser. And Opera's browser. And KHTML. Within those two years IE wont be upgreaded enought to force their new standards. So who is modern? Mozilla. Mozilla supports CSS2, DOM, MathML, SVG. And we have a chance to gain precents in browser stats. Not to 60% but to 20%. Thanks to our Evangelization Project, almost all webpages i know supports Mozilla in more than 90%. It's rare for me to find a non-standard page, and if it'll happen, usually webmaster fix this page after my email with advice. If we will support document.all we can forget about it's end. This bug has been created one year ago. After one year of our work, we have almost 10% of market (according to the-only apache log statistics properly splitting IE from Netscape and from Mozilla - http://awstats.sf.net) and it's good prove for me that we don't need IE's DOM. I strongly belive that we're winning and last Microsoft's moves are side-effect of this. The reasons from Comment #0 are not realistic anymore. There is something about Joel? And now Joel use Firebird (http://www.joelonsoftware.com/news/20030601.html). I also dont see any problems with www.auto-res.net, www.ebankinter.com, and www.abbys-computer.com is down. Can we close this bug as WONTFIX and forget about this? Nobody voted for this bug. Nobody need it. No duplicates found.

No duplicates found??? It *is* a duplicate.

Right. But no dopes for this one, and it's the only one dupe for original one. Don't You think that if it would be as important as reporter said there would be much more?

I'm rather confused as to what you want. This bug is RESOLVED DUPLICATE, of a bug marked VERIFIED WONTFIX. BTW, there are at least four bugs on this issue: bug 154589, bug 57366, bug 162036, and bug 74201.

The patch for this bug could potentially solve *52 other bugs related to document.all, and many others that nobody even bothered to open (users simply uninstall Mozilla when it doesn't work for them). Don't get me wrong, evangelism is very important and I am personally involved in it, but it won't always help, not when webmasters aren't cooperative and not when they can do with targeting "only" ~95% of the market. Prog. * http://snurl.com/documentall_bugs

jst would be the one to convince. This is the wrong bug to do it in though, it's marked as RESOLVED DUPLICATE, not RESOLVED WONTFIX.

to Comment #121 and on the same pattern 'document.all' 38 are fixed. Ian: yes, this bug is dupe, and orginal is wontfix. I hope there are no plans to change this.

Zbigniew Braniecki: > on the same pattern 'document.all' 38 are fixed. The bottom line is that most document.all bugs are left unfixed, regardless of evangelism efforts. Here are 6 other such bugs that I've just opened: Bug 208664, Bug 208658, Bug 208667, Bug 208674, Bug 208675, Bug 208676 I will contact these websites, and I might even convince one or two of them to fix their code, but in the meanwhile Mozilla users are left out (and for no good reason, this patch can solve all of these bugs). Prog.

From comment #117 (Zbigniew Braniecki): | Thanks to our Evangelization Project, almost all webpages i know | supports Mozilla in more than 90%. It's rare for me to find a | non-standard page ... An interesting statistic. Unfortunately, it is "absolutely meaningless". To get Mozilla accepted by the general public, the number you need to be looking for is the "Business to Business" web sites that support Mozilla. Unfortunately, that number is so low as to be considered ZERO. (Sorry for being so blunt.) Manufactures depend Webec to receive orders from distributors. All the Realtors in the northern half of my state must use Paragon to access listing on their Boards of Realtors. Health food store use Order Dog to place orders with their distributors. Real estate Appraisers need to look up tax rolls at county web sites using Seagull software's jwalk. All of the above only support IE. And, the list goes on and on and on. Are you all seeing a pattern here? (Please do not tell me to report these sites to Tech Evalgelism, on most of them, I already have. These sites just do not care. "Everyone has access to IE, just use IE.") What is being missed here is that users want to "use what they know". If they use IE at work, then they want to use IE at home. Force the user to use IE at work and you write your own obituary. (By the way, forcing businesses to stick with IE will also kill any general acceptance of Linux on the desktop.) If Mozilla is ever to break out of the "8% other browsers" mold, this bug needs to be fixed . Comment #112 is a good starting point. --Tony aewell@gbis.com

People. Please. Comments should go in bug 74201, not this one. This bug is a duplicate. Please add comments you feel should be added to bug 74201. Thank you.

I cannot agree. If we'll use Microsoft's DOM why just not use IE's engine? It's easy to embed, really! What for W3C is, if both "alternative" browsers hardly work to mimic IE? Netscape 4 had over 80% of browser market in some moment. But it lost it, without Microsoft implementation of document.layers, so please, don't tell me "it's impossible". It is possible, and we're doing it now. I also cannot belive that fixing this bug will help too much. 1) Fixing it completly would be probably very hard. IE has very big DOM, and we have same chance that "very big, ugly, and important website" use document.all and that it use document.tags['div'] or document.layerName.style="filter:" or |event|. You wont to fix those too? And formName.submit() ... 2) Fixing it completly would be similar move that AOL made. We're agreeing for Microsoft domination, and we'll help it with all our power to grow popularity of their ideas. 3) http://www.mozilla.org.uk/docs/proprietary-features-bad.html 4) Even before W3C standards about, for example, scrollbars are ready, we'll show that we prefer IE's solution than any standard. 5) We'll make us dependant from Microsoft's will. 6) It really wont rise our popularity. Let's see what Opera has from it's slavery.

Sorry Ian. You're right.

Now that AOL has closed all Mozilla development and fired almost all of you, I ask you to acknowledge your responsability for doing the wrong descission. The incompatibility of Mozilla with Internet Explorer was a key factor for AOL not integrating Gecko in AOL client for Windows, as we can read in http://www.joelonsoftware.com/items/2003/06/04.html "On the topic of AOL using Gecko in their client, I have heard from more than one inside source that this was a decision made by AOLTW management in New York because they were afraid AOL customers would complain if the AOL browser didn't display every web page perfectly." As a side point, you have unfairly marked this bug as a duplicate. It is not a duplicate. Bug 74201 is asking Mozilla development to implement Internet Explorer compatibility. By contrast, this bug is me offering to implement it. In addition, this proposal was based on more solid arguments. I did not simply say play their own game. I explained in detail the dynamics that drive Mozilla out of the market for not being compatible. Moreover, using duplicate as an excuse is a bad attitude. Through History, there have been many times the debate between idealism and pragmatism. History has always shown that the pragmatic wins. Here is just one more example. But it will not be enough for convincing idealists. There is no amount of evidence, however large, capable of convincing idealists. Ramon

ramon@juguete.quim.ucm.es: I never saw such a dumb and wrong comment in bugzilla and i read many bugs.

bugzilla@gmx.net, your rudeness is an example of some of the things Ramon was commenting on.

Closing this annoying bug once and for all. I love how Ramon believes someone OUTSIDE of AOL for knowing why Gecko development was axed. Dude, we implemented Active X support even and it didn't help.

Doron's action reminded me something. The behaviour of technical evangelism people was particulary interested. By strongly opposing to implementing MS DOM, they probably put their own interest over the global interest of the Mozilla community. By making Mozilla compatible with IE would make their jobs quite redundant. I can understand it, and we could have found compromise solutions, such as emulating IE for some sites. I attempted that at some time. However, the technical evangelism people went too far and by attempting to keep their employments they destroyed everybody's one. With regard to the real reasons of closing Mozilla development, by looking at browser statistics of Google (http://www.google.com/press/zeitgeist.html), we find that the distributions of known browsers is: 95 % Internet Explorere 3 % Netscape 6.x or higher, includes Mozilla 2 % Netscape 4.x Finally by closing the bug does not show the educated and tolerant attitude expected in a man of his position; by constrast it is a gesture of insolence.

I find this personal attack on Doron completely out of line. You talk about the Mozilla community, many respected members of that community (including developers and the DOM module owner, not just evangelists) have argued against fixing this bug. Believe what you want about the killing of Netscape, but using that as an argument for fixing this bug is silly. As the DOM module co-owner I support Jst's decision to wontfix bug 74201 and his comments in this bug. This is my first and only comment in this bug, I find spamming people with endless discussions in bugmail rude. We have newsgroups for that.

Continued in bug 229877.