Re: [XHR2] responseText for text/html before the encoding has stabilized
On Sat, 01 Oct 2011 22:09:47 +0200, Jonas Sicking jo...@sicking.cc wrote: If we change how determining encoding works between default, text, and document, we should really start throwing for responseText and responseXML when responseType is not the default to indicate that is different. Why? What problem are you trying to solve? I think it would be confusing for responseText to give different results for and text. The whole point was that since it behaved the same it did not matter. If we make it behave differently, that invariant is gone, and it seems better to not expose it at all. -- Anne van Kesteren http://annevankesteren.nl/
Generic guide to exceptions, events, etc. for new APIs Re: [indexeddb] New WebIDL Exception Model for IndexedDB
On Saturday, 1 October 2011 at 08:15, Anne van Kesteren wrote: On Sat, 01 Oct 2011 02:56:55 +0200, Israel Hilerio isra...@microsoft.com (mailto:isra...@microsoft.com) wrote: On Friday, September 30, 2011 12:23 AM, Anne van Kesteren wrote: Actually, given http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#concept-throw it does. Which is what I was trying to convey. HTML does this too now: http://html5.org/r/6602 The DOM 4 spec link you sent us is exactly the approach we’re following but with a simpler language. Instead of defining what it means to throw a type as an exception (like you do on DOM 4), we’re following the WebIDL spec to define the exception type in a simpler fashion. Look at the note contained in the WebIDL spec under IDL Exceptions where it says there is no IDL syntax for declaring exception types: http://dev.w3.org/2006/webapi/WebIDL/#idl-exceptions We believe it is simpler and closer to the intent on the WebIDL spec to say: Throws a DOMException of type VersionError. It's also wrong, since it does not say what code will be. Instead of having to explain what it means to throw a type as an exception: To throw a “VersionError” exception, a user agent would construct a DOMException exception whose type is VersionError and code exception field value is 0, and actually throw that object as an exception. It seems you misunderstood DOM4. All you need to say is: # Throw a VersionError exception That is it. The DOM4 definition of throw handles the details, such as setting message and code. This is great! Makes it super easy. This discussion shows that the review process can catch these types of issues and reviewers like yourself can make us aware of exceptions we should reuse. Even if it didn’t, the worst case scenario is that a developer would have similar Exceptions that have slightly different types and names. Each name or type should be meaningful enough for the developer to allow them to disambiguate. The main point is that we don’t believe we should over engineer a solution to a problem that is not pervasive at this point. We could even add a note to the DOM 4 spec that states, We encourage the reuse of these exceptions instead of defining new ones. Only define new ones if the current set of exceptions doesn’t meet your needs. I guess I don't really see what you think the problem is with keeping a non-normative table in DOM4 (or elsewhere) listing the exceptions in use. (generally speaking...) Seems there is a lot of confusion about how to do this properly (and I'm seeing that this is going to now be an issue amongst a number of groups, including this group, DAP, and even other organisations that are trying their best to define new APIs such as Webinos and WAC). Perhaps the best thing to do would be to create a wiki page that defines how to do this using some very generic examples. What would be great would be to see how the prose maps to the IDL and how the IDL maps to a real object in Java script… and also show how the DOM4 spec takes care of setting the code and the message…. so, a Exceptions and events for [Spec Writing] Dummies would be greatly appreciated (and will avoid a few common mistakes). -- Marcos Caceres http://datadriven.com.au
[Bug 14331] Hello! Why tasks that are queued by EventSource doesnot removed from task queues with close method? Thanks!
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14331 Ian 'Hixie' Hickson i...@hixie.ch changed: What|Removed |Added Status|NEW |RESOLVED CC||i...@hixie.ch Resolution||NEEDSINFO --- Comment #1 from Ian 'Hixie' Hickson i...@hixie.ch 2011-10-02 16:39:36 UTC --- EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Did Not Understand Request Change Description: no spec change Rationale: Why would they be? -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
Re: [XHR2] responseText for text/html before the encoding has stabilized
On Sun, Oct 2, 2011 at 12:08 AM, Anne van Kesteren ann...@opera.com wrote: On Sat, 01 Oct 2011 22:09:47 +0200, Jonas Sicking jo...@sicking.cc wrote: If we change how determining encoding works between default, text, and document, we should really start throwing for responseText and responseXML when responseType is not the default to indicate that is different. Why? What problem are you trying to solve? I think it would be confusing for responseText to give different results for and text. The whole point was that since it behaved the same it did not matter. If we make it behave differently, that invariant is gone, and it seems better to not expose it at all. Is it really that much more confusing than the fact that .response gives different results depending on the value of .responseType? Additionally it feels like optimizing for the more rare case when .responseText is used to load unparsed HTML/XML contents, rather than textual contents. The advantage I can see of making text responses available through .responseText is that it'll make it easier to transition to using .responseType. I.e. if you have a large JS codebase which loads non-XML data through XMLHttpRequests, you can simply set .responseType=text. In browsers that doesn't support .responseType this is a no-op. In browsers that do support .responseType the browser won't waste time checking if the response should be parsed as a document. In both cases you can read the result through .responseText. / Jonas
