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 10:03:10 -0700
Cc: Maciej Stachowiak <mjs@apple.com>, HTML WG <public-html@w3.org>
Message-Id: <95670224-921C-4EA2-9DC8-911F0690BCC1@mozilla.org>
To: Ian Hickson <ian@hixie.ch>
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.

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.

/be
Received on Thursday, 15 October 2009 17:04:25 GMT

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