Re: [XHR] chunked
On Thu, May 24, 2012 at 2:54 AM, Jonas Sicking jo...@sicking.cc wrote: No change came out of this thread. I think we established that there is a need for chunked-arraybuffer. This thread contained some controversy about whether chunked-text is needed, but in the end the controversy didn't actually seem relevant to the question at hand. Is there a reason not to add chunked-text and chunked-arraybuffer to the spec right now? 1. Why not just have http://html5labs.interoperabilitybridges.com/streamsapi/ to address this case? 2. Is anyone else planning on implementing these? -- Anne — Opera Software http://annevankesteren.nl/ http://www.opera.com/
Push API draft uploaded
Thanks to the inestimable help of the W3C staff I am now plugged into the mercurial mainline and have uploaded the first stab at the Push API http://dvcs.w3.org/hg/push/raw-file/default/index.html I incorporated Mozilla's client API ideas in https://wiki.mozilla.org/Services/Notifications/Push/API as the PushManager interface, and also in the PushService interface with some additions to support a more explicit event model for received message delivery, derived from Server-Sent Events. A lot is still left unsaid, and I will work on examples. I also have not addressed the server API aspect that Mozilla mentioned in their proposal. Like a lot that is left unsaid in their client API proposal (how does the browser determine what that magic server URL is...?), the server API is likely related to the specific Push service that is bound to the API. I am considering the use of Web Intents to discover and select the Push Service provider that the user wants apps to use, assuming that we can leave the backend details to the intent provider. I'm not yet sure how the pieces will fit together, how much needs to be defined, and how my earlier proposal about specific event source selection and filtering fits into this, but it's a start. Thanks, Bryan Sullivan
Re: Push API draft uploaded
On 05/24/2012 09:14 AM, SULLIVAN, BRYAN L wrote: Thanks to the inestimable help of the W3C staff I am now plugged into the mercurial mainline and have uploaded the first stab at the Push API http://dvcs.w3.org/hg/push/raw-file/default/index.html A couple of notes on the WebIDL: * PushManager has |PushService requestRemotePermission ([Optional] DOMString url);|, should be ... (optional DOMString url), though the spec doesn't appear to define what happens when url is omitted; same for checkRemotePermission. * There does not appear to be a need to make PushManager and PushService use [NoInterfaceObject], so please remove that. * PushService.readyState is a DOMString, but the spec defines it to return the unsigned short constants CONNECTING/OPEN/CLOSED. Please get rid of the constants. The requestUrl attribute must return the absolute URL where the webapp server can send Push service messages to this webapp. should probably refer to |serviceUrl|, not |requestUrl|. A reference to DOM4 for the DOMError interface should probably be added. Also, the resolve a url cross-reference is broken. HTH Ms2ger
Re: Howto spec
On May 23, 2012, at 20:40 , Anne van Kesteren wrote: how does ReSpec.js use or promote the discouraged particulars? Most specifications (if not all) using ReSpec.js have this problem. I believe that is because it is the default setup. Yup, it's just the default setup. As I've said before, I'm certainly very open to adding alternative ways of doing it. Anyone interested in working on this can just ping me. -- Robin Berjon - http://berjon.com/ - @robinberjon
Re: Howto spec
On May 23, 2012, at 20:30 , Anne van Kesteren wrote: On Wed, May 23, 2012 at 5:55 PM, Dimitri Glazkov dglaz...@chromium.org wrote: Should I be concerned about what seems to be a lively competition between ReSpec and Anolis. Do we need this tussle? Can we not just decide which tool to use? It's a tradeoff: ReSpec.js pro: * No setup costs ReSpec.js con: * Loads slower because of script. You get a flash of unstyled content. User experience suffers. Right. ReSpec is optimised for editors more than for users, at the cost of all the processing taking place at runtime. The performance is made worse by the fact that a 300K biblio database (yay!) is loaded over the wire. The FOUC is much worsened by the fact that an older browser (I forget which, maybe FX3?) had abysmal performance when many text nodes were being manipulated, the fix for which was to set display: none on body before running and reverting it afterwards (re-yay!). Both of those issues are going away very soon though. If you want smoother UX you can generate a static output. This is currently harder than it should be; if there's interest I can hack something out. Overall there's no competition though, I doubt that there can be one tool for everyone's tastes. I also think that it's good to have a Web-based tool and a more traditional Python one, it helps us keep in mind what we need to improve with the Web. -- Robin Berjon - http://berjon.com/ - @robinberjon
Re: Howto spec
On May 23, 2012, at 14:45 , Anne van Kesteren wrote: I have made some updates to the howto spec wiki page outlining how you should go about writing a specification, with some emphasis on specifications for APIs. http://wiki.whatwg.org/wiki/Howto_spec In particular the Patterns and Legacy DOM-style sections are probably of interest. I would love to have feedback to see what else people would like to see explained or how what is explained thus far can be done better. Thanks Anne, this is good stuff. I wonder if maybe there would be value in merging some of that with http://scriptlib-cg.github.com/api-design-cookbook/. It's just a rough draft now but I'm slated to update it a fair bit over the next three months or so. It's currently under the scriptlib's repo, but since that doesn't seem to be taking off we can put it elsewhere. -- Robin Berjon - http://berjon.com/ - @robinberjon
URL spec parameter-related methods use parameter in a way inconsistent with the URI RFC
The current draft URL spec has a number of Parameter-related methods
(getParameterNames, getParameterValues, hasParameter, getParameter,
setParameter, addParameter, removeParameter, clearParameters)[1]. Apparently
these methods refer to key-value pairs in the query part of the URL as
parameters. However, the term parameter is used by the URI RFC[2] to refer
to something else, a semicolon-delimited part of a path (which I think is
nearly obsolete in modern use; I am not sure what it is for). I understand that
for legacy reasons, much of the URL interface cannot be consistent with
RFC-official terminology. But it seems like a bad idea to use the same term for
a different piece of the URL, worse than using the same term for a different
part. At least call it something like query parameters to disambiguate.
Another point of feedback on the parameter-related methods: they seem to form a
dictionary-style interface, and it seems inelegant to have all these different
methods giving a dictionary-style interface to something that is a piece of the
URL, rather than something that is the URL.
One possible way to solve both these problems:
interface URL {
StringMultiMap queryParameters;
}
interface StringMultiMap {
sequenceDOMString keys;
sequenceDOMString getAll(DOMString name)
boolean contains(DOMString name)
DOMString? get(DOMString name);
void set(DOMString name, DOMString value);
void add(DOMString name, DOMString value);
void remove(DOMString name);
void clear();
}
The StringMultiMap interface could be reusable for other, similar key-value
list contexts.
Or else use an appropriate dictionary type from ES if one is ever provided.
Regards,
Maciej
[1]
http://dvcs.w3.org/hg/url/raw-file/tip/Overview.html#dom-url-getparameternames
[2] http://www.ietf.org/rfc/rfc2396.txt
Re: URL spec parameter-related methods use parameter in a way inconsistent with the URI RFC
On 2012-05-24 11:29, Maciej Stachowiak wrote: The current draft URL spec has a number of Parameter-related methods (getParameterNames, getParameterValues, hasParameter, getParameter, setParameter, addParameter, removeParameter, clearParameters)[1]. Apparently these methods refer to key-value pairs in the query part of the URL as parameters. However, the term parameter is used by the URI RFC[2] to refer to something else, a semicolon-delimited part of a path (which I think is nearly obsolete in modern use; I am not sure what it is for). I understand that for legacy reasons, much of the URL interface cannot be consistent with RFC-official terminology. But it seems like a bad idea to use the same term for a different piece of the URL, worse than using the same term for a different part. At least call it something like query parameters to disambiguate. The URI RFC actually is RFC 3986. Otherwise, agreed. ... Best regards, Julian
Re: Howto spec
There is a list called spec-p...@w3.org which is about things to do with making specs. I.e. for editors, in particular. I forwarded some stuff from this thread there - there are other preprocessing systems around, including XML toolsets. I think this stuff used to be documented somewhere, and it might be worth trying to find that and make it look like it comes from the 21st century... cheers On Wed, 23 May 2012 14:45:05 +0200, Anne van Kesteren ann...@annevk.nl wrote: Hi, I have made some updates to the howto spec wiki page outlining how you should go about writing a specification, with some emphasis on specifications for APIs. http://wiki.whatwg.org/wiki/Howto_spec In particular the Patterns and Legacy DOM-style sections are probably of interest. I would love to have feedback to see what else people would like to see explained or how what is explained thus far can be done better. Thanks, -- Charles 'chaals' McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg kan noen norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: URL spec parameter-related methods use parameter in a way inconsistent with the URI RFC
+1 (top post FTW)
cheers
On Thu, 24 May 2012 11:29:24 +0200, Maciej Stachowiak m...@apple.com
wrote:
The current draft URL spec has a number of Parameter-related methods
(getParameterNames, getParameterValues, hasParameter, getParameter,
setParameter, addParameter, removeParameter, clearParameters)[1].
Apparently these methods refer to key-value pairs in the query part of
the URL as parameters. However, the term parameter is used by the
URI RFC[2] to refer to something else, a semicolon-delimited part of a
path (which I think is nearly obsolete in modern use; I am not sure what
it is for). I understand that for legacy reasons, much of the URL
interface cannot be consistent with RFC-official terminology. But it
seems like a bad idea to use the same term for a different piece of the
URL, worse than using the same term for a different part. At least call
it something like query parameters to disambiguate.
Another point of feedback on the parameter-related methods: they seem to
form a dictionary-style interface, and it seems inelegant to have all
these different methods giving a dictionary-style interface to something
that is a piece of the URL, rather than something that is the URL.
One possible way to solve both these problems:
interface URL {
StringMultiMap queryParameters;
}
interface StringMultiMap {
sequenceDOMString keys;
sequenceDOMString getAll(DOMString name)
boolean contains(DOMString name)
DOMString? get(DOMString name);
void set(DOMString name, DOMString value);
void add(DOMString name, DOMString value);
void remove(DOMString name);
void clear();
}
The StringMultiMap interface could be reusable for other, similar
key-value list contexts.
Or else use an appropriate dictionary type from ES if one is ever
provided.
Regards,
Maciej
[1]
http://dvcs.w3.org/hg/url/raw-file/tip/Overview.html#dom-url-getparameternames
[2] http://www.ietf.org/rfc/rfc2396.txt
--
Charles 'chaals' McCathieNevile Opera Software, Standards Group
je parle français -- hablo español -- jeg kan noen norsk
http://my.opera.com/chaals Try Opera: http://www.opera.com
RE: Push API draft uploaded
Thanks for the comments. I updated the spec: - define what happens when url is omitted - remove [NoInterfaceObject] - define readyState as a unsigned short (that was what was meant in the first place) - fix cut/paste errors I still have to find the source of resolve a url as that's a function I borrowed from EventSource. Latest version is at http://dvcs.w3.org/hg/push/raw-file/default/index.htm Thanks, Bryan Sullivan -Original Message- From: Ms2ger [mailto:ms2...@gmail.com] Sent: Thursday, May 24, 2012 12:33 AM To: SULLIVAN, BRYAN L Cc: public-webapps Subject: Re: Push API draft uploaded On 05/24/2012 09:14 AM, SULLIVAN, BRYAN L wrote: Thanks to the inestimable help of the W3C staff I am now plugged into the mercurial mainline and have uploaded the first stab at the Push API http://dvcs.w3.org/hg/push/raw-file/default/index.html A couple of notes on the WebIDL: * PushManager has |PushService requestRemotePermission ([Optional] DOMString url);|, should be ... (optional DOMString url), though the spec doesn't appear to define what happens when url is omitted; same for checkRemotePermission. * There does not appear to be a need to make PushManager and PushService use [NoInterfaceObject], so please remove that. * PushService.readyState is a DOMString, but the spec defines it to return the unsigned short constants CONNECTING/OPEN/CLOSED. Please get rid of the constants. The requestUrl attribute must return the absolute URL where the webapp server can send Push service messages to this webapp. should probably refer to |serviceUrl|, not |requestUrl|. A reference to DOM4 for the DOMError interface should probably be added. Also, the resolve a url cross-reference is broken. HTH Ms2ger
RE: Push API draft uploaded
Sorry, cut paste error: the spec is at: http://dvcs.w3.org/hg/push/raw-file/default/index.html Thanks, Bryan Sullivan -Original Message- From: SULLIVAN, BRYAN L Sent: Thursday, May 24, 2012 6:02 AM To: 'Ms2ger' Cc: public-webapps Subject: RE: Push API draft uploaded Thanks for the comments. I updated the spec: - define what happens when url is omitted - remove [NoInterfaceObject] - define readyState as a unsigned short (that was what was meant in the first place) - fix cut/paste errors I still have to find the source of resolve a url as that's a function I borrowed from EventSource. Latest version is at http://dvcs.w3.org/hg/push/raw-file/default/index.htm Thanks, Bryan Sullivan -Original Message- From: Ms2ger [mailto:ms2...@gmail.com] Sent: Thursday, May 24, 2012 12:33 AM To: SULLIVAN, BRYAN L Cc: public-webapps Subject: Re: Push API draft uploaded On 05/24/2012 09:14 AM, SULLIVAN, BRYAN L wrote: Thanks to the inestimable help of the W3C staff I am now plugged into the mercurial mainline and have uploaded the first stab at the Push API http://dvcs.w3.org/hg/push/raw-file/default/index.html A couple of notes on the WebIDL: * PushManager has |PushService requestRemotePermission ([Optional] DOMString url);|, should be ... (optional DOMString url), though the spec doesn't appear to define what happens when url is omitted; same for checkRemotePermission. * There does not appear to be a need to make PushManager and PushService use [NoInterfaceObject], so please remove that. * PushService.readyState is a DOMString, but the spec defines it to return the unsigned short constants CONNECTING/OPEN/CLOSED. Please get rid of the constants. The requestUrl attribute must return the absolute URL where the webapp server can send Push service messages to this webapp. should probably refer to |serviceUrl|, not |requestUrl|. A reference to DOM4 for the DOMError interface should probably be added. Also, the resolve a url cross-reference is broken. HTH Ms2ger
Re: Push API draft uploaded
Hi Brian, On 05/24/2012 03:02 PM, SULLIVAN, BRYAN L wrote: Thanks for the comments. I updated the spec: - define what happens when url is omitted - remove [NoInterfaceObject] - define readyState as a unsigned short (that was what was meant in the first place) - fix cut/paste errors I still have to find the source of resolve a url as that's a function I borrowed from EventSource. Latest version is at http://dvcs.w3.org/hg/push/raw-file/default/index.html Thanks for the update. resolve a url is defined in HTML; see http://www.whatwg.org/html/#resolving-urls. As for a numeric readyState, please have a look at the discussion at http://lists.w3.org/Archives/Public/public-script-coord/2012JanMar/0166.html. Finally, it appears that you removed [NoInterfaceObject] from NavigatorPush (where I believe it was correct), rather than from PushService. HTH Ms2ger
Non-persistent in-memory storage accessible by same domain tabs
Web applications need a way to communicate between two same domain tabs without polling LocalStorage and without hitting the disk. It would be useful to have an in-memory get/set/compare_and_set hash table exposed to scripts running same domain tabs, that is discarded by the browser when those tabs are closed. Use cases: 1. Coordinate replication between tabs for an offline app, i.e. one tab takes responsibility for syncing a user's data to and from IndexedDB. 2. Sign out from one tab triggers sign out from all other tabs. 3. If something like LevelDB were exposed directly to JS, one could implement MVCC on top using the shared hash. 4. Library authors would be able to implement their own cross-tab postMessage. It's difficult to implement these use cases with LocalStorage, without a coarse resolution, and risky at that, due to the lack of compare and set primitive in LocalStorage.
Re: Non-persistent in-memory storage accessible by same domain tabs
On Thu, May 24, 2012 at 8:42 AM, Joran Greef jo...@ronomon.com wrote: Web applications need a way to communicate between two same domain tabs without polling LocalStorage and without hitting the disk. I think shared Workers can handle most of this. -- Glenn Maynard
RE: Push API draft uploaded
OK, I corrected the [NoInterfaceObject] (I hope), and referenced HTML5 for resolving a URL. The numeric readyState was borrowed from EventSource. I will look at the thread, but I think this is something that I will just align with the consensus in the group once determined. I don't have a strong opinion either way. Latest version is at http://dvcs.w3.org/hg/push/raw-file/default/index.html Thanks, Bryan Sullivan -Original Message- From: Ms2ger [mailto:ms2...@gmail.com] Sent: Thursday, May 24, 2012 6:37 AM To: SULLIVAN, BRYAN L Cc: public-webapps Subject: Re: Push API draft uploaded Hi Brian, On 05/24/2012 03:02 PM, SULLIVAN, BRYAN L wrote: Thanks for the comments. I updated the spec: - define what happens when url is omitted - remove [NoInterfaceObject] - define readyState as a unsigned short (that was what was meant in the first place) - fix cut/paste errors I still have to find the source of resolve a url as that's a function I borrowed from EventSource. Latest version is at http://dvcs.w3.org/hg/push/raw-file/default/index.html Thanks for the update. resolve a url is defined in HTML; see http://www.whatwg.org/html/#resolving-urls. As for a numeric readyState, please have a look at the discussion at http://lists.w3.org/Archives/Public/public-script-coord/2012JanMar/0166.html. Finally, it appears that you removed [NoInterfaceObject] from NavigatorPush (where I believe it was correct), rather than from PushService. HTH Ms2ger
Re: Push API draft uploaded
On 5/24/2012 7:08 AM, SULLIVAN, BRYAN L wrote: OK, I corrected the [NoInterfaceObject] (I hope), and referenced HTML5 for resolving a URL. The numeric readyState was borrowed from EventSource. I will look at the thread, but I think this is something that I will just align with the consensus in the group once determined. I don't have a strong opinion either way. Latest version is athttp://dvcs.w3.org/hg/push/raw-file/default/index.html Does the following mean that http/https are interpreted as EventSource and ws/wss as WebSockets? Does checkRemotePermission trigger CORS checks for those protocols? If the url parameter is present and the user agent recognizes the url value as a particular type of Push service that it supports, the user agent must activate the service. My read on that is yes and yes, but I wanted to double-check. -Charles
Re: Push API draft uploaded
Re a particular type of Push service that it supports this is intended to be generic so that new services (perhaps identified by unique URI schemes) can be covered under this. That being said, WebSockets schemes clearly would imply that protocol, but http schemes could be more flexible. One of the goals is to define how the serviceUrl is conveyed to the user agent and Webapp. In the process of determining that URL, there could be other useful info that the server returns, eg the applicable bearer bindings or info that will help ensure events can be delivered to the correct Webapp (e.g. SMS source address, message fields/headers). If its possible to define a lightweight and generic/extensible Push service registration protocol, this would be a good place to invoke it. We defined such a protocol for OMA Push, and some of those ideas might be useful here. This is an area for further study. If the Push server connection is setup to another domain then CORS would apply. But the checkRemotePermission method (at least as I understood it from the Mozilla proposal) would only test if there was a prior permission by the user, and would not need to invoke any network transactions to do so (though for some implementations this might be a feature). I will try to develop these ideas in the draft (or at least outline the intent to), but I did not want to put too much into it at this time... As far as possible I am leaning to the simple (but clearly not as simple as the Mozilla proposal). Service lifecycle management, of which registration is a facet, can hopefully be layered above the API for the most part. Thanks, Bryan Sullivan On May 24, 2012, at 9:33 AM, Charles Pritchard ch...@jumis.com wrote: On 5/24/2012 7:08 AM, SULLIVAN, BRYAN L wrote: OK, I corrected the [NoInterfaceObject] (I hope), and referenced HTML5 for resolving a URL. The numeric readyState was borrowed from EventSource. I will look at the thread, but I think this is something that I will just align with the consensus in the group once determined. I don't have a strong opinion either way. Latest version is athttp://dvcs.w3.org/hg/push/raw-file/default/index.html Does the following mean that http/https are interpreted as EventSource and ws/wss as WebSockets? Does checkRemotePermission trigger CORS checks for those protocols? If the url parameter is present and the user agent recognizes the url value as a particular type of Push service that it supports, the user agent must activate the service. My read on that is yes and yes, but I wanted to double-check. -Charles
RfC: LCWD of WebSocket API; deadline June 14
This is a Request for Comments re the 24-May-2012 LCWD version of the WebSocket API: http://www.w3.org/TR/2012/WD-websockets-20120524/ The comment deadline is June 14 and all comments should be sent to the public-webapps@w3.org list. The Bugzilla component for the API is [Bugz]. I Cc'ed the hybi list as an FYI and comments from that list's subscribers are of course welcome. The Bugzilla component for the API is [Bugz]. -Thanks, AB [Bugz] https://www.w3.org/Bugs/Public/buglist.cgi?product=WebAppsWGcomponent=WebSocket%20API%20%28editor%3A%20Ian%20Hickson%29resolution=---
RfC: LCWD of Indexed Database; deadline June 21
This is a Request for Comments re the 24-May-2012 LCWD version of Indexed Database: http://www.w3.org/TR/2012/WD-IndexedDB-20120524/ The comment deadline is June 21 and all comments should be sent to the public-webapps@w3.org list. -Thanks, AB
http://www.w3.org/TR/2012/WD-url-20120524
Hi there, here's some early feedback. A control character is a character whose value is less than or equal to U+0020 ( ). This is really surprising; it doesn't match Unicode (http://www.unicode.org/charts/PDF/U.pdf) nor IETF ABNF (RFC 5234). I think it would be better to exclude U+0020, in particular as the term is just only once. A more general concern is that the spec defines various URI-related operations in terms of algorithms, and doesn't mention whether those algorithms are supposed to return the same results as those defined in RFC 3986 or not. If they are not, it would be totally awesome if there was an explanation about what these difference are. Lacking that, this is really hard to review. Best regards, Julian
Re: RfC: LCWD of WebSocket API; deadline June 14
On 2012-05-24 19:20, Arthur Barstow wrote: This is a Request for Comments re the 24-May-2012 LCWD version of the WebSocket API: http://www.w3.org/TR/2012/WD-websockets-20120524/ The comment deadline is June 14 and all comments should be sent to the public-webapps@w3.org list. The Bugzilla component for the API is [Bugz]. ... I note that many keywords that reference parts of other specs are not hyperlinked, so it's extremely hard for a reader to understand what they are supposed to mean (phrasing it politely). For instance, in Section 7: If the url string is not an absolute URL, then fail this algorithm. absolute URL is not defined anywhere in this document. Resolve the url string, with the URL character encoding set to UTF-8. [RFC3629] Resolve is not defined anywhere in this document. etc. Best regards, Julian
Re: [File API] File behavior under modification
On Thu, May 24, 2012 at 8:27 AM, Jonas Sicking jo...@sicking.cc wrote: On Mon, May 21, 2012 at 4:05 PM, Eric U er...@google.com wrote: According to the latest editor's draft [1], a File object must always return an accurate lastModifiedDate if at all possible. On getting, if user agents can make this information available, this MUST return a new Date[HTML] object initialized to the last modified date of the file; otherwise, this MUST return null. However, if the underlying file has been modified since the creation of the File, reads processed on the File must throw exceptions or fire error events. ...if the file has been modified on disk since the File object reference is created, user agents MUST throw a NotReadableError... These seem somewhat contradictory...you can always look at the modification time and see that it's changed, but if you try to read it after a change, it blows up. The non-normative text about security concerns makes me think that perhaps both types of operations should fail if the file has changed [... guarding against modifications of files on disk after a selection has taken place]. That may not be necessary, but if it's not, I think we should call it out in non-normative text that explains why you can read the mod time and not the data. This came up in https://bugs.webkit.org/show_bug.cgi?id=86811; I believe WebKit is currently noncompliant with this part of the spec, and we were debating the correct behavior. Currently WebKit delays grabbing the modification time of the file until it's been referenced by a read or slice(), so it won't notice modifications that happen between selection and read. That was done because the slice creates a File object reference, but in my reading creating the File referring to the file should be the time of the snapshot, not creating a Blob referring to a File. What's the correct behavior? In Gecko we currently lazily in some cases get the file size and the lastModificationDate (which we just implemented the other day). However getting that lazily means that we sometimes have to do synchronous IO which is something we want to avoid. Hence we're working towards always getting the file size and last modification date when the File object is instantiated and would never change after that. I would imagine other UAs would want to avoid such synchronous IO too? Changing the behavior of .lastModificationDate and .size might affect existing Web applications, but I like this approach. It makes things clearer, UAs can avoid synchronous IO (yes, we want to avoid it) and File becomes a purely constant snapshot. It sounds saner to me (especially now that we have an alternative live file interface, i.e. FileEntry). We absolutely should not have an API which forces implementations to do synchronous IO, hence I don't think we can require that lastModificationDate should stay up-to-date, or that reading from it should throw if the file has changed on disk. The only operations that we can make fail are asynchronous ones, which means that we can only make file-reading fail. The wording in the spec is unfortunate since it says that reading should throw. Instead we should say that reading should fail, and then leave it up to the various APIs to define what happens when reading fails. / Jonas
Re: Implied Context Parsing (DocumentFragment.innerHTML, or similar) proposal details to be sorted out
This seems sensible. I've updated the WebKit patch to do exactly this: https://bugs.webkit.org/show_bug.cgi?id=84646 It appears that the details of the proposal are now sorted out. I'll start a new thread describing the full API semantics. On Fri, May 18, 2012 at 8:29 PM, Ryosuke Niwa rn...@webkit.org wrote: Not that I want to start another bike-shedding, there is one clear distinction between innerHTML and createDocumentFragment, which is that innerHTML sets already-started flag on parsed script elements but createDocumentFragment does not (or rather it unsets it after the fragment parsing algorithm has ran). See http://html5.org/specs/dom-parsing.html#dom-range-createcontextualfragment There appears to be a consensus to use document.parse (which is fine with me), so I would like to double-check which behavior we're picking. IMO, the only sane choice is to unset the already-started flag since doing otherwise implies script elements parsed by document.parse won't be executed when inserted into a document. While we can change the behavior for template elements, I would rather have the same behavior between all 3 APIs (createDocumentFragment, parse, and template element) and let innerHTML be the outlier for legacy reasons. (Note: I intend to fix the bug in WebKit that already-started flag isn't unmarked in createDocumentFragment). - Ryosuke
