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