- From: Arun Ranganathan <aranganathan@mozilla.com>
- Date: Thu, 7 Mar 2013 13:09:43 -0800 (PST)
- To: Anne van Kesteren <annevk@annevk.nl>
- Cc: Web Applications Working Group WG <public-webapps@w3.org>
Anne, > On Wed, Feb 6, 2013 at 7:58 PM, Arun Ranganathan <arun@mozilla.com> > wrote: > > 3. Progress events have been clarified. > > You're still using the old IDL syntax for event handlers. > Fixed. > I think we should rename URI to URL. That's what everyone is > converging on. Fixed. > I'm also not convinced that leaving what exactly to return in the > HTTP > scenario open to implementors is a good thing. We've been through > such > things before and learned that handwaving is bad. Lets just pick > something. Just to be clear, are you referring to the 500 Error Condition for Blob URLs? If so, the only handwaving is about the text of the error message. I'm happy to tighten even this. > Just like HTML, CSS, etc. this specification should defer to > http://encoding.spec.whatwg.org/ for its encoding related > requirements. I fully agree that what we've currently got, which favors a "heuristic guessing model" for encoding, and forces UTF-8 in a void, isn't sufficient. AND I agree that the encoding spec. is much more detailed. But what exactly does deferring to it entail? Right now, the specification encourages user agents to get encoding from: 1. The encoding parameter supplied with the readAsText. 2. A byte order detection heuristic, if 1. is missing. 3. The charset component of Blob.type, if provided and if 1. and 2. yield no result. 4. Just use utf-8 if 1, 2, and 3 yield no result. Under the encoding spec., it returns failure if encoding isn't valid, and it returns failure if the BOM check fails. So should the spec. say something about throwing? > > I don't think we should throw for limitations on URL length. We > always > leave undefined lengths unaddressed in specifications, including with > regards to how to handle them. OK. -- A*
Received on Thursday, 7 March 2013 21:10:15 UTC