- From: Jonas Sicking <jonas@sicking.cc>
- Date: Wed, 25 Jun 2008 15:53:36 -0700
- To: Maciej Stachowiak <mjs@apple.com>
- CC: arun@mozilla.com, Ian Hickson <ian@hixie.ch>, aa@google.com, Ben Turner <bturner@mozilla.com>, Johnny Stenback <jst@mozilla.com>, Jonas Sicking <sicking@mozilla.com>, Brandon Sterne <bsterne@mozilla.com>, chaals@opera.com, chris.wilson@microsoft.com, public-webapps@w3.org, schepers@w3.org, tlr@w3.org, dveditz@mozilla.com
>> I'd really rather not add more stuff to HTML5, it's too big as it is. >> Ideally worker threads is something that we can nail down in a pretty >> short period of time, before HTML5 is out (targeted a few years into >> the future iirc). >> >> Like you say, some features from HTML5 should be exposed in the >> context of worker threads. I don't really know how to handle that, but >> I can see two ways: >> >> 1. Make a informative note stating a list of features that we expect >> will be made available once there is a finished spec for them, but >> leave it up to the HTML5 spec to actually explicitly make this >> requirement. >> >> 2. Have a normative requirement that implementations that also support >> feature X from HTML5, makes that implementation available to the >> worker thread as well. > > I am ok with the spec either being in HTML5 or standalone, but we have > to realize that if it is a separate spec, it will have dependencies on > HTML5. For XMLHttpRequest this has turned out to be controversial, so we > should make this clear up front. Agreed. I think we need to find a solution for this dependency both for XHR and for threads, and probably for other specs in the future. I listed two proposals above that might work for the threads spec. / Jonas
Received on Wednesday, 25 June 2008 22:54:01 UTC