[XHR] remove user cancels request
Currently the XMLHttpRequest Standard special cases the condition where the end user terminates the request. Given that there's less and less likely to be UI for that kind of feature, does it still make sense to expose this distinction from a network error in the API? I think we should merge them. http://xhr.spec.whatwg.org/ -- http://annevankesteren.nl/
Re: [XHR] remove user cancels request
On Sun, Feb 24, 2013 at 8:18 AM, Anne van Kesteren ann...@annevk.nl wrote: Currently the XMLHttpRequest Standard special cases the condition where the end user terminates the request. Given that there's less and less likely to be UI for that kind of feature, does it still make sense to expose this distinction from a network error in the API? I think we should merge them. http://xhr.spec.whatwg.org/ I didn't even know about that behavior. I've always assumed that the only way onabort happens is as a result of my calling abort(). I don't think breaking that assumption would break my code, but it's a rare, untested code path. I doubt other developers test it either. I agree that users killing a network request should look like a network error, and in general the API should guarantee that onabort is only fired as a result of a call to abort(). -- Glenn Maynard
Re: Re: Keyboard events for accessible RIAs and Games
I've updated the UIEvents document with an initial draft for queryKeyCap/queryLocale https://dvcs.w3.org/hg/d4e/raw-file/tip/source_respec.htm (Section 4.1) On Mon, Feb 18, 2013 at 8:09 AM, Gary Kacmarcik (Кошмарчик) gary...@chromium.org wrote: I'll be updating the document this week. I'll send an update to the list after that happens. On Sat, Feb 16, 2013 at 7:40 AM, Florian Bösch pya...@gmail.com wrote: Any progress on the speccing of queryKeyCap? On Fri, Feb 1, 2013 at 9:14 PM, Gary Kacmarcik (Кошмарчик) gary...@chromium.org wrote: On Fri, Feb 1, 2013 at 11:42 AM, Travis Leithead travis.leith...@microsoft.com wrote: I think we should give it another try by including it in our UI Events spec. I like the idea of adding the static queryKeyCap(code) API to Keyboard events. I wonder about the name though. A key capability doesn't sound right. Are we querying for a key's locale name? e.g., queryKeyLocaleName(code)? SGTM. I'll add a section to the spec for this. The KeyCap name refers to the cap placed over the keyswitch of the physical keyboard. It's not a great name since there's no guarantee that the physical keyboard matches the current locale (although they usually do). However, the other (more accurate) names that I was able to come up with at the time were all rather unwieldy. Taking your name as a base, I think we'd need something like queryLocaleChar(locale, code) or queryLocaleKey since we'd be returning the equivalent of the 'char' (or 'key') attribute. Thinking briefly about this now: * If we return 'char' equivalents, we won't return dead keys or other virtual keys. * If we return 'key' values, then we need to address how to handle non-printable keys like Shift and Home that people might expect to be translated. * I think we'll also want the ability to specify modifier keys to apply to the 'code' (to generate shifted or AltGr'ed versions). I'll formalize this a bit more and send something out for comments. -Gary
Re: [XHR] remove user cancels request
On Feb 24, 2013, at 11:18 AM, Glenn Maynard gl...@zewt.org wrote: On Sun, Feb 24, 2013 at 8:18 AM, Anne van Kesteren ann...@annevk.nl wrote: Currently the XMLHttpRequest Standard special cases the condition where the end user terminates the request. Given that there's less and less likely to be UI for that kind of feature, does it still make sense to expose this distinction from a network error in the API? I think we should merge them. http://xhr.spec.whatwg.org/ I didn't even know about that behavior. I've always assumed that the only way onabort happens is as a result of my calling abort(). I don't think breaking that assumption would break my code, but it's a rare, untested code path. I doubt other developers test it either. I agree that users killing a network request should look like a network error, and in general the API should guarantee that onabort is only fired as a result of a call to abort(). +1 -- Glenn Maynard - Timmy
Re: Re: Keyboard events for accessible RIAs and Games
This looks fine to me, I have question though. Are we sure that the locale dependent printable keys are uniquely identified by code alone (and not also location on the keyboard)? On Sun, Feb 24, 2013 at 5:36 PM, Gary Kacmarcik (Кошмарчик) gary...@chromium.org wrote: I've updated the UIEvents document with an initial draft for queryKeyCap/queryLocale https://dvcs.w3.org/hg/d4e/raw-file/tip/source_respec.htm (Section 4.1) On Mon, Feb 18, 2013 at 8:09 AM, Gary Kacmarcik (Кошмарчик) gary...@chromium.org wrote: I'll be updating the document this week. I'll send an update to the list after that happens. On Sat, Feb 16, 2013 at 7:40 AM, Florian Bösch pya...@gmail.com wrote: Any progress on the speccing of queryKeyCap? On Fri, Feb 1, 2013 at 9:14 PM, Gary Kacmarcik (Кошмарчик) gary...@chromium.org wrote: On Fri, Feb 1, 2013 at 11:42 AM, Travis Leithead travis.leith...@microsoft.com wrote: I think we should give it another try by including it in our UI Events spec. I like the idea of adding the static queryKeyCap(code) API to Keyboard events. I wonder about the name though. A key capability doesn't sound right. Are we querying for a key's locale name? e.g., queryKeyLocaleName(code)? SGTM. I'll add a section to the spec for this. The KeyCap name refers to the cap placed over the keyswitch of the physical keyboard. It's not a great name since there's no guarantee that the physical keyboard matches the current locale (although they usually do). However, the other (more accurate) names that I was able to come up with at the time were all rather unwieldy. Taking your name as a base, I think we'd need something like queryLocaleChar(locale, code) or queryLocaleKey since we'd be returning the equivalent of the 'char' (or 'key') attribute. Thinking briefly about this now: * If we return 'char' equivalents, we won't return dead keys or other virtual keys. * If we return 'key' values, then we need to address how to handle non-printable keys like Shift and Home that people might expect to be translated. * I think we'll also want the ability to specify modifier keys to apply to the 'code' (to generate shifted or AltGr'ed versions). I'll formalize this a bit more and send something out for comments. -Gary
[editing] Block extending algorithm
Hi folks, Currently, the block extending algorithm [1] normally treats br as a block delimiter, but if the br is inside an li, then it is not treated as a block delimiter. This seems like a somewhat arbitrary decision. I've noticed that different applications extend blocks differently, regardless of whether the br is inside an li or not. WebKit currently always treats br as a block (paragraph) delimiter, but MS Word does *not* treat newlines (Shift+Enter) as block delimiters when performing block commands. I'm wondering if this can be made into a setting instead of hard-coding a specific behavior into the spec. I think the web application (and not the browser) would know better which behavior is more suitable for its use-case. I'm not sure how it would be exposed, perhaps a document-wide flag like how useCss works? Any thoughts on this would be appreciated. Thanks, Shezan [1] https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html#block-extending-a-range
[editing] Block extending algorithm
Hi folks, Currently, the block extending algorithm [1] normally treats br as a block delimiter, but if the br is inside an li, then it is not treated as a block delimiter. This seems like a somewhat arbitrary decision. I've noticed that different applications extend blocks differently, regardless of whether the br is inside an li or not. WebKit currently always treats br as a block (paragraph) delimiter, but MS Word does *not* treat newlines (Shift+Enter) as block delimiters when performing block commands. I'm wondering if this can be made into a setting instead of hard-coding a specific behavior into the spec. I think the web application (and not the browser) would know better which behavior is more suitable for its use-case. I'm not sure how it would be exposed, perhaps a document-wide flag like how useCss works? Any thoughts on this would be appreciated. Thanks, Shezan [1] https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html#block-extending-a-range
Re: [webcomponents]: Making Shadow DOM Subtrees Traversable
Hello everybody, I'm coming into this conversation late, but wanted to add my thoughts. As has been pointed out in this thread, the web has traditionally been very open and malleable. JavaScript has very few readonly properties, doesn't generally throw exceptions instead guessing or returning bogus values. Making shadow trees hidden clearly goes against this idiom and, by definition, limits what pages will be able to do with external libraries built using shadow DOMs. Even given this downside, though, I think that it's a mistake to make shadow trees accessible to the bound document by default. One of the most important features for frameworks is the ability to provide an encapsulated API. Without that, it becomes extremely difficult to fix bugs or add features to the framework without risking breaking downstream clients. Shadow DOMs are one of a host of features being designed and implemented that make HTML + CSS + JavaScript usable for programming in the wild and it feels like an oversight to make the default imitate the bad ol' days of monkey patching and low to no encapsulation. Finally, reading through the thread, it seems like one of the main use-cases for open-by-default is features like Google Feedback. From my point of view, it seems like features like that need to be considered from the beginning of a site's design. So if a site wants to have something like GF and also use web components and shadow DOMs, then the designers of the components should have to explicitly set the bit that says let other people poke at my internals. I don't think that this one use-case needs to trump the good programming practices of every other library. -- Blake Kaplan
Re: [webcomponents]: Making Shadow DOM Subtrees Traversable
On Thu, Feb 21, 2013 at 6:33 PM, Blake Kaplan mrb...@gmail.com wrote: Hello everybody, I'm coming into this conversation late, but wanted to add my thoughts. As has been pointed out in this thread, the web has traditionally been very open and malleable. JavaScript has very few readonly properties, doesn't generally throw exceptions instead guessing or returning bogus values. Making shadow trees hidden clearly goes against this idiom and, by definition, limits what pages will be able to do with external libraries built using shadow DOMs. Even given this downside, though, I think that it's a mistake to make shadow trees accessible to the bound document by default. One of the most important features for frameworks is the ability to provide an encapsulated API. Without that, it becomes extremely difficult to fix bugs or add features to the framework without risking breaking downstream clients. Shadow DOMs are one of a host of features being designed and implemented that make HTML + CSS + JavaScript usable for programming in the wild and it feels like an oversight to make the default imitate the bad ol' days of monkey patching and low to no encapsulation. Finally, reading through the thread, it seems like one of the main use-cases for open-by-default is features like Google Feedback. From my point of view, it seems like features like that need to be considered from the beginning of a site's design. So if a site wants to have something like GF and also use web components and shadow DOMs, then the designers of the components should have to explicitly set the bit that says let other people poke at my internals. I don't think that this one use-case needs to trump the good programming practices of every other library. We've gone back and forth. It seems that allowing monkeypatching by default is the better choice, as most uses aren't security conscious, they just want the encapsulation benefits. If you are doing something security-conscious, you'd better be thinking about it a bit, and it's trivial to hide your shadow then. Google Feedback is merely one particular example of a whole class of things that *do* want to know the real DOM of the page, and which are fine to allow by default. ~TJ
RE: [XHR] remove user cancels request
From: Timmy Willison [mailto:timmywill...@gmail.com] Sent: Monday, February 25, 2013 2:55 AM On Feb 24, 2013, at 11:18 AM, Glenn Maynard gl...@zewt.org wrote: On Sun, Feb 24, 2013 at 8:18 AM, Anne van Kesteren ann...@annevk.nl wrote: Currently the XMLHttpRequest Standard special cases the condition where the end user terminates the request. Given that there's less and less likely to be UI for that kind of feature, does it still make sense to expose this distinction from a network error in the API? I think we should merge them. http://xhr.spec.whatwg.org/ I didn't even know about that behavior. I've always assumed that the only way onabort happens is as a result of my calling abort(). I don't think breaking that assumption would break my code, but it's a rare, untested code path. I doubt other developers test it either. I agree that users killing a network request should look like a network error, and in general the API should guarantee that onabort is only fired as a result of a call to abort(). According to the current spec, it is already the case that onabort() is called only when client.abort() is explicitly called (including CORS requests.) onerror() is getting called in actual network errors such as DNS error, TLS negotiation failure, cross-origin access violation, etc. I am not sure what conditions Anne exactly propose to remove from the spec. I can think of only three scenarios where the end user *terminates* the request: calling open(), calling abort() or explicitly stop in browser chrome. I don't think client.open() and explicit browser stop are what Anne is talking about. Anne, could you elaborate what part of the text are you pointing? If it's the case that you want to merge abort into error, I tend to disagree as there can be use cases explicitly putting cancel button in UI that should be distinguished from network initiated errors. Jungkee +1 -- Glenn Maynard - Timmy
