Closed Bug 154589 (document.all) Opened 22 years ago Closed 22 years ago

implement Internet Explorer DOM features document.all and others.

Categories

(Core :: DOM: Core & HTML, enhancement)

enhancement
Not set
normal

Tracking

()

CLOSED DUPLICATE of bug 74201

People

(Reporter: ramon_garcia_f, Assigned: ramon_garcia_f)

References

Details

(Keywords: arch, highrisk, Whiteboard: duplicate of bug 74201.)

Attachments

(1 obsolete file)

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 ;)
Severity: normal → enhancement
Summary: Please implement Internet Explorer DOM features document.all and others. → [rfe]Please implement Internet Explorer DOM features document.all and others.
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.
Assignee: jst → ramon_garcia_f
Status: UNCONFIRMED → NEW
Component: DOM HTML → DOM Level 0
Ever confirmed: true
Summary: [rfe]Please implement Internet Explorer DOM features document.all and others. → Please implement Internet Explorer DOM features document.all and others.
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 ...
Summary: Please implement Internet Explorer DOM features document.all and others. → implement Internet Explorer DOM features document.all and others.
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.
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
Attachment #89399 - Attachment is obsolete: true
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
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?
Keywords: arch, highrisk
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.
Alias: document.all
**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 ***
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
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.
Whiteboard: duplicate of bug 74201.
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.
Status: RESOLVED → VERIFIED
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.
Status: VERIFIED → CLOSED
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.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: