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.
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
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
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
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
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,
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,
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
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
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
10 matches
Mail list logo