- From: Brendan Eich <brendan@mozilla.org>
- Date: Thu, 15 Oct 2009 10:03:10 -0700
- To: Ian Hickson <ian@hixie.ch>
- Cc: Maciej Stachowiak <mjs@apple.com>, HTML WG <public-html@w3.org>
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 UTC