W3C home > Mailing lists > Public > public-html@w3.org > October 2009

Re: typeof document.all

From: Brendan Eich <brendan@mozilla.org>
Date: Thu, 15 Oct 2009 14:08:43 -0700
Cc: Maciej Stachowiak <mjs@apple.com>, HTML WG <public-html@w3.org>
Message-Id: <F60AFC8E-7ACA-4F14-893B-2E0CF48F79C6@mozilla.org>
To: Ian Hickson <ian@hixie.ch>
On Oct 15, 2009, at 2:00 PM, Ian Hickson wrote:

> Certainly there are significant software factors. However, even if  
> we were
> to specify the software factors down to the byte, we would still be  
> left
> with unavoidable hardware factors, and thus we could never get full
> interoperability on this issue regardless of how detailed we make the
> software requirements.

First, hardware has nothing to do with the issues I've raised.

Second, hardware limitations cap software limitations in many ways,  
but this does not make the software limitations less of a problem or  
worth treating with specs.


> Therefore I consider this something that is
> dominated by hardware characteristics and leave it unspecified.

Your use of "dominated" here is incorrect.

If I have two algorithms, one O(n) and the other O(n^2), that run  
serially so the composite complexity is O(n^2), then O(n^2) dominates.  
That is nothing like the issue of cross-heap cycles entraining large  
hunks of memory in each heap, vs. hardware (and OS-mediated) memory  
quotas.

At the limit, you can run out of memory and either get OOM-killed by  
the OS, or get null from a system call (or equivalent failure return  
code) and have to propagate failure to JS.

But if you run into a browser that mishandles cycles you may find the  
observable behavior bad, but not fatally so. There's no OOM, or any  
effect that could be due to hardware at the limit.

So there's no "dominated".


>> Why shouldn't HTML5 specify harder here? It is strictly more  
>> important
>> than overspecifying document.all.
>
> I agree. I've tried to minimise the impact of these issues, by (for
> instance) specifying what are to be considered weak references vs  
> what are
> to be considered strong references, for the purposes of garbage
> collection. I've also (with extensive help and advice from others)  
> made
> sure that the APIs avoid exposing garbage collection specifics.

Great.


> However, that it is impossible to get good interperability on an  
> important
> issue is not, IMHO, a reason to avoid getting interoperability on a  
> less
> important issue.

Economic scarcity means we'll never get everything pinned down. You  
can't spend "forever" on HTML5. Choosing your over-specification  
battles can help.


> Differences in how browsers implement the DOM are a big
> part of what authors complain about when you ask them about their
> authoring experiences.


No one has asked us to change our wacky document.all emulation to be  
more like what HTML5 specifies, based on real-world content, as far as  
I know.

Of course some people are enthusiastic about "specifying every  
observable effect" modulo hardware or other limits. I think that's  
good in general and misguided when applied blindly to everything in  
HTML5.

/be
Received on Thursday, 15 October 2009 21:09:33 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:50 GMT