W3C home > Mailing lists > Public > public-script-coord@w3.org > October to December 2009

Re: Conflicts between W3C specs and ES5?

From: Ian Hickson <ian@hixie.ch>
Date: Tue, 24 Nov 2009 12:27:13 +0000 (UTC)
To: Brendan Eich <brendan@mozilla.org>
Cc: Maciej Stachowiak <mjs@apple.com>, James Graham <jgraham@opera.com>, "Mark S. Miller" <erights@google.com>, public-script-coord@w3.org
Message-ID: <Pine.LNX.4.62.0911241218400.9450@hixie.dreamhostps.com>
On Tue, 17 Nov 2009, Brendan Eich wrote:
> On Nov 17, 2009, at 11:03 AM, Maciej Stachowiak wrote:
> > On Nov 17, 2009, at 7:32 AM, Brendan Eich wrote:
> > > 
> > > The argument I was having, which you kindly interrupted (no problem! 
> > > ;-), was against indefinite and blind over-specification. The wiki 
> > > page is a mix, as you say. But only some of it fits in ECMA-262. 
> > > Where does the rest, if we agree to cut the crazy 
> > > over-specification, belong?
> > 
> > I think the argument you were having was against a position that no 
> > one has taken.
> 
> I don't think so. Clearly no one wants to endorse "blind 
> over-spefication" but I've heard either "let's specify legacy crap 
> feature X fully, it's easy" when it's neither easy nor necessary to 
> over-specify. I've also heard "we will specify all effects other than 
> those dominated by hardware issues". Evidence:
> 
> http://lists.w3.org/Archives/Public/public-html/2009Oct/0365.html (Anne on
> document.all)
> http://lists.w3.org/Archives/Public/public-html/2009Oct/0368.html (my reply to
> Anne)
> http://lists.w3.org/Archives/Public/public-html/2009Oct/0396.html (Hixie, same
> thread)
> 
> Hixie and I exchanged a few more messages on that "typeof document.all" 
> thread, but I don't think we came to much of an understanding. I owe him 
> some data on cross-browser interop-hazard results to do with memory 
> management. But the general issue of specifying too much legacy is still 
> unresolved, AFAICT.

For the record, my desire is for user agents of the Web platform to 
interoperate in all areas other than those dominated by hardware issues. 
This implies specifying those areas, but it does _not_ imply specifying 
quirks and bugs in those areas.

If you're willing to remove support for the legacy, then I'm more than 
happy to remove it from the specs. But if browser vendors continue to 
support the legacy, then we should spec it. I don't think it's acceptable 
for the specs to be intentionally different from interoperable 
implementations purely because we think it's too hard to spec the real 
requirements or because it violates our sense of aesthetics.

Are JavaScript interpreter implementers willing to drop the "<!--" parsing 
quirks? If not, we should spec them, to make it easier for new JavaScript 
implementations to be written, and to make it more likely that the 
implementations will at least agree to implement the quirks the same way.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 24 November 2009 12:27:44 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 May 2013 19:30:02 UTC