W3C home > Mailing lists > Public > www-dom@w3.org > October to December 2005

Re: [dom3core] getAttribute

From: Brendan Eich <brendan@meer.net>
Date: Mon, 05 Dec 2005 18:47:18 -0800
Message-ID: <4394FBB6.7070604@meer.net>
To: www-dom@w3.org

Hi Ray, a quick note to talk about the case you show that doesn't work 
as expected in Firefox:

<p id='foo'></p>
<script>
alert(document.getElementById('foo'));
</script>

This source, taken as an entire text/html document, causes Gecko to move 
the script to the implicit head and leave the p in the implicit body.  
That makes the document.getElementById call become a forward reference, 
which returns null since when the relocated script in the document's 
head is processed, there is not yet any element with id 'foo'.  This is 
all done to emulate IE.

Giving the p some child content causes the implicit body to open before 
the p, so the script is not moved to the (still-implicit) head.  Again, 
IE compatible.

If you use an explicit body tag, all works as expected.

One more (lengthy) comment: a lot of what browsers do to gain market 
share and hope to lead the web toward better standards conformance is 
necessarily temporizing.  You might call it a deal with the devil, but 
without it, there is no way forward because adoption is strictly limited 
based on lack of backward compatibility.

Adding UI preferences, even with the right (user-oriented, 
"bugward-compatible") default, won't help, since most web developers 
won't set the pref the other way when developing (assuming they even use 
your browser), and if they did, their content might still break in 
almost all browsers.

Even if IE7 were to fix this implicit head bug, for example, and at 
great risk of lost backward compatibility and therefore of lost market 
share with some (probably "Enterprise" or otherwise large, 
institutional) customers, the sunk costs in content creation spread 
across the web and private networks will not be un-sunk, and the content 
will not be re-authored, until IE7 and other browsers with such a fix 
showed adoption at or above a significant threshold -- or until entirely 
new content is written for the same purpose, for unrelated reasons.  
While it would help if this were to happen, it does not appear likely to 
with IE7.

Any browser with much smaller market share than IE faces even harsher 
trade-offs.  This is a variation on the Prisoner's Dilemma (it would be 
pure P.D. if all browser vendors were willing to cooperate).  Without 
meaningful cooperation, instead of "defection" to the status quo and 
backward compatibility as we all try to gain market share against the 
dominant browser, it is not possible to advance the state of standards 
conformance in many ways in the near term.

But with more market share for standards-friendly browsers based on 
their merits *independent of standards conformance*, and so long as they 
"don't break the web" (i.e., "work like IE, or Mozilla if it is handled 
correctly by content"), then there is hope.

The trick is to get enough market share, and thereby co-evolve new 
interoperable, standard, and *actually used* content languages with 
"sugar on top", so that over time, new content based on the new 
standards comes to eclipse the old content that ties our hands right 
now.  This is far from a sure thing, but it is conceivable.  In fact, 
Gecko has eliminated a few bugward-compatible quirks over its history.

What is not likely is a "brand new web" built beside the old one, on top 
of new, undertested /de jure/ standards.  Evolution by incremental 
change, with lots of web compatibility, is clearly the only viable 
growth path for minority-market-share browsers.

/be
Received on Tuesday, 6 December 2005 07:09:56 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:13:58 GMT