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

Re: typeof document.all

From: Ian Hickson <ian@hixie.ch>
Date: Thu, 15 Oct 2009 21:00:58 +0000 (UTC)
To: Brendan Eich <brendan@mozilla.org>
Cc: Maciej Stachowiak <mjs@apple.com>, HTML WG <public-html@w3.org>
Message-ID: <Pine.LNX.4.62.0910152048150.6803@hixie.dreamhostps.com>
On Thu, 15 Oct 2009, Brendan Eich wrote:
> On Oct 13, 2009, at 6:21 PM, Ian Hickson wrote:
> > On Tue, 13 Oct 2009, Brendan Eich wrote:
> > > > 
> > > > Personally I would be against underspecifying anything that can be 
> > > > black-box tested from a Web page.
> > > 
> > > This is silly. Is everything else in HTML5 full specified in terms 
> > > of effects in the DOM, global objects, information leaks including 
> > > implicit flows, and anything else "that can be black-box tested"?
> > 
> > More or less. Anything that is dominated by hardware characteristics 
> > (e.g. timing, memory availability, input capacity limits, performance) 
> > is left unspecified, but otherwise yes, things are intended to be 
> > fully specified.
> 
> Let's talk about memory. Memory availability is not dominated by 
> hardware in all browsers. Implementations may have software quotas. Many 
> have two heaps, one for JS and one for the DOM. Cycles between these 
> heaps may be uncollectible until page or window-clique teardown (or even 
> permanent memory leaks -- these are "just" bugs). Or an implementation 
> may work harder to collect cycles promptly. Or it could use a single 
> heap.

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. Therefore I consider this something that is 
dominated by hardware characteristics and leave it unspecified.


> Developers can black-box test for memory effects to-do with JS/DOM 
> cycles. These are not just academic problems, they're genuine web dev 
> concerns (the permanent leaks certainly, but from my discussions with 
> developers even the whole-DOM entrainment in cycles until page or 
> multi-window app teardown is a problem).
>
> 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.

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. Differences in how browsers implement the DOM are a big 
part of what authors complain about when you ask them about their 
authoring experiences.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 15 October 2009 20:49:45 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:09 UTC