Re: [whatwg] localStorage feedback
On Mon, Oct 12, 2009 at 7:07 PM, Ian Hickson i...@hixie.ch wrote: ... the problem here is that localStorage is a pile of global variables. we are trying to give people global variables without giving them tools to synchronize access to them. the claim i've heard is that developers are not savy enough to use those tools properly. i agree that developers tend to use tools without fully understanding them. ok, but then why are we giving them global variables? The global variables have implicit locks such that you can build the tools for explicit locking on top of them: // run this first, in one script block var id = localStorage['last-id'] + 1; localStorage['last-id'] = id; localStorage['email-ready-' + id] = 0; // begin // these can run each in separate script blocks as desired localStorage['email-subject-' + id] = subject; localStorage['email-from-' + id] = from; localStorage['email-to-' + id] = to; localStorage['email-body-' + id] = body; // run this last localStorage['email-ready-' + id] = 1; // commit Dividing up work like this into separate SCRIPT elements to scope the locking seems really awkward to me. On Thu, 24 Sep 2009, Darin Fisher wrote: The current API exposes race conditions to the web. The implicit dropping of the storage lock is that. In Chrome, we'll have to drop an existing lock whenever a new lock is acquired. That can happen due to a variety of really odd cases (usually related to nested loops or nested JS execution), which will be difficult for developers to predict, especially if they are relying on third-party JS libraries. This issue seems to be discounted for reasons I do not understand. You can only lose the lock in very specific conditions. Those conditions are rarely going to interact with code that actually does storage work in a way that relies on the lock: - changing document.domain - history.back(), .forward(), .go(n) - invoking a plugin - alert(), confirm(), prompt(), print() - showModalDialog() - yieldForStorageUpdates() I discussed this in more detail here: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/023059.html You are right that the conditions are specific, but I don't know that that is the exhaustive list. Rather than defining unlock points, I would implement implicit unlocking by having any nested attempt to acquire a lock cause the existing lock to be dropped. Nesting can happen in the cases you mention, but depending on the UA, it may happen for other reasons too. This combined with the fact that most people use JS libraries means that the coder is not going to have an easy time knowing when these specific conditions are met. I don't think defining a set of allowed unlock points is sufficient to make this API not be a minefield for users. For example, a JS library might evolve to use flash for something small (like storage or sound) that it previously didn't use when I first developed my code. Voila, now my storage lock is released out from under me. At this point, I'm not favoring implementing the storage mutex in Chrome. I don't think we will have it in our initial implementation of LocalStorage. I think web developers that care will have to find another way to manage locking, like using a Web Database transaction or coordinating with a Shared Worker. Sorry to be a grump about this, but a cross-process lock that lasts until JS returns is just going to slow down the web. It is a really bad idea for that reason. -Darin On Tue, 8 Sep 2009, Chris Jones wrote: Can those in the first camp explain why mutex semantics is better than transaction semantics? And why it's desirable to have one DB spec specify transaction semantics (Web Database) and a second specify mutex semantics (localStorage)? I don't think it's desirable. It's just what we have, though an accident of history. Where we're at: localStorage can't really change. It is what it is. We have a better proposal, Web Database, but not everybody wants to implement it. To move forward, I would recommend that someone come up with a storage proposal with the following characteristics: * All major browsers vendors are willing to implement it. * Compatible with workers. * Doesn't have any race conditions. * Doesn't involve a cross-process mutex that blocks interaction. * Stores structured data. * Can be queried in arbitrary ways. * Doesn't expose authors to locking primitives. Then we can replace Web Database with it and we can move on. I suggest that the right venue for this discussion would be the W3C Web Apps group, at public-weba...@w3.org. On Wed, 9 Sep 2009, Darin Fisher wrote: What about navigating an iframe to a reference fragment, which could trigger a scroll event? The scrolling has to be done synchronously for compat with the web. You can only do that with same-domain pages, as far as I can tell. (Does that
Re: [whatwg] localStorage feedback
On Fri, Oct 30, 2009 at 7:27 PM, Darin Fisher da...@chromium.org wrote: You are right that the conditions are specific, but I don't know that that is the exhaustive list. Rather than defining unlock points, I would implement implicit unlocking by having any nested attempt to acquire a lock cause the existing lock to be dropped. Nesting can happen in the cases you mention, but depending on the UA, it may happen for other reasons too. What reasons? If these reasons are situations where it's fundamentally difficult, impossible, or non-performant to follow the spec, we should change the spec. Otherwise this would just be a bug in the UA. For example, a JS library might evolve to use flash for something small (like storage or sound) that it previously didn't use when I first developed my code. Voila, now my storage lock is released out from under me. This example still sounds overly contrived to me. Nevertheless, it seems strange to say that because there might be a few unexpected race conditions, you have decided to allow a much larger set of unexpected race conditions. At this point, I'm not favoring implementing the storage mutex in Chrome. I don't think we will have it in our initial implementation of LocalStorage. I think web developers that care will have to find another way to manage locking, like using a Web Database transaction or coordinating with a Shared Worker. Have you considered just not implementing LocalStorage? If it's so difficult for authors to use correctly and to implement according to the spec, this seems like the best path to me. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] focus change inside keypress event handler
On 10/30/09 7:26 AM, Boris Zbarsky wrote: On 10/29/09 10:16 PM, Maciej Stachowiak wrote: WebKit also makes typing take effect as the default action for keypress, at least for normal typing. It's more complicated when international text input methods are in play. Yeah, when IME is involved I have no idea what events are fired in Gecko and when. When IME is involved Gecko dispatches keydown, keypress, compositionstart, text+, compositionend, keyup. D3E has compositionstart, compositionupdate (which is a lot better name than 'text') and compositionend. In Gecko IME doesn't really make key event handling more complicated, though the default handling is a bit different with keypress. (I should re-test default handling with IME.) -Olli
Re: [whatwg] localStorage feedback
On Fri, Oct 30, 2009 at 1:36 AM, Robert O'Callahan rob...@ocallahan.orgwrote: On Fri, Oct 30, 2009 at 7:27 PM, Darin Fisher da...@chromium.org wrote: You are right that the conditions are specific, but I don't know that that is the exhaustive list. Rather than defining unlock points, I would implement implicit unlocking by having any nested attempt to acquire a lock cause the existing lock to be dropped. Nesting can happen in the cases you mention, but depending on the UA, it may happen for other reasons too. What reasons? If these reasons are situations where it's fundamentally difficult, impossible, or non-performant to follow the spec, we should change the spec. Otherwise this would just be a bug in the UA. For example, a JS library might evolve to use flash for something small (like storage or sound) that it previously didn't use when I first developed my code. Voila, now my storage lock is released out from under me. This example still sounds overly contrived to me. Nevertheless, it seems strange to say that because there might be a few unexpected race conditions, you have decided to allow a much larger set of unexpected race conditions. I don't have a strong opinion either way on this one, but in general I'd say that making a race more subtle isn't usually much of a win.especially when it comes to debugging it. At this point, I'm not favoring implementing the storage mutex in Chrome. I don't think we will have it in our initial implementation of LocalStorage. I think web developers that care will have to find another way to manage locking, like using a Web Database transaction or coordinating with a Shared Worker. Have you considered just not implementing LocalStorage? If it's so difficult for authors to use correctly and to implement according to the spec, this seems like the best path to me. We'd love to, but it's difficult given that most of the other vendors have already implemented it. I also believe that Microsoft's browser exhibits the same races that Darin's talking about. So I'm not really sure how you could suggest that us not implementing it is better than implementing the status quo.
Re: [whatwg] localStorage feedback
On Fri, Oct 30, 2009 at 10:03 PM, Jeremy Orlow jor...@chromium.org wrote: I don't have a strong opinion either way on this one, but in general I'd say that making a race more subtle isn't usually much of a win.especially when it comes to debugging it. It's not just a matter of degree. If the UA follows the spec, authors can (fairly easily) write code that's race free. Darin's proposing to make it so they can't --- at least, not without external help like shared workers or Web Storage, in which case I wonder why one would use LocalStorage at all. (OK, I suppose one could rely on key/value atomicity and implement Lamport's bakery algorithm on LocalStorage alone. I hope to never see that...) Have you considered just not implementing LocalStorage? If it's so difficult for authors to use correctly and to implement according to the spec, this seems like the best path to me. We'd love to, but it's difficult given that most of the other vendors have already implemented it. I also believe that Microsoft's browser exhibits the same races that Darin's talking about. So I'm not really sure how you could suggest that us not implementing it is better than implementing the status quo. That is a good point. You do have the option of doing better than IE, though :-). Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] rp is a styling tag and has no semantic function
Futomi Hatano schrieb: If ATs(e.g. screen reader) know the rp element, it can remove the content of the rp element. So, we can get only true annotations from ATs, without parentheses. I don't want hear parentheses from a screen reader. I hope that all browsers (including ATs) support the ruby element. If so, I think the rp element is not necessary. Thank you. -- Futomi Hatano www.html5.jp I think this element is necessary in the HTML5 spec. Talking about screen-readers: How should a screen-reader actually handle ruby annotations? In this case ruby 漢 rt かん /rt 字 rt じ /rt /ruby it would be quite strange if a screen-reader read the annotations, because they have the same content as the ruby base text. (I hope this is correct. I don't know the Japanese language, but I understood it as 漢 beeing same as かん only in a different way of writing.) So the reader must not read the annotation. In an example i got from an older W3C spec, it's different: ruby rbc rb10/rb rb31/rb rb2002/rb /rbc rtc rtMonth/rt rtDay/rt rtYear/rt /rtc rtc rt rbspan=3Expiration Date/rt /rtc /ruby As this markup isn't used anymore with HTML5, here's how it would be (dropping the expiration date): ruby 10 rtMonth/rt 31 rtDay/rt 2002 rtYear/rt /ruby This one now should be read out by the screen-reader. Otherwise the meaning of the numbers may be not as clear. (Or is the date-example out-of-date and ruby shouldn't be used there?)
Re: [whatwg] HTML5 at Last Call (at the WHATWG)
Ian Hickson wrote: If you sent an e-mail or filed a bug that I haven't replied to, then please send it again. In case I didn't miss it, it seems you haven't followed up on the thread titled Proposed changes to the History API: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-August/022138.html (22 messages) Best regards Mike Wilson
Re: [whatwg] rp is a styling tag and has no semantic function
On Fri, 30 Oct 2009 11:10:59 +0100 Nikita Popov pri...@ni-po.com wrote: Futomi Hatano schrieb: If ATs(e.g. screen reader) know the rp element, it can remove the content of the rp element. So, we can get only true annotations from ATs, without parentheses. I don't want hear parentheses from a screen reader. I hope that all browsers (including ATs) support the ruby element. If so, I think the rp element is not necessary. Thank you. -- Futomi Hatano www.html5.jp I think this element is necessary in the HTML5 spec. Talking about screen-readers: How should a screen-reader actually handle ruby annotations? In this case ruby 漢 rt かん /rt 字 rt じ /rt /ruby it would be quite strange if a screen-reader read the annotations, because they have the same content as the ruby base text. (I hope this is correct. I don't know the Japanese language, but I understood it as 漢 beeing same as かん only in a different way of writing.) So the reader must not read the annotation. More correctly, screen-readers should read only the contents of rt rather than the base text. That is, screen-readers are expected to read it as ka-n-ji from rts. Of course, screen-readers which don't support ruby repeat 2 times such like ka-n-ka-n-ji-ji as you know. We also have to get ruby easy to read for visual browser users. But, the markup above is rendered by non-IE browsers as below. 漢かん字じ We feel it is odd. So, I want to mark it up like this. ruby漢字rp(/rprtかんじ/rtrp)/rp/ruby This markup is rendered by non-IE browsers as below. 漢字(かんじ) It's natural and easy to understand. Screen-readers which supports ruby of HTML5 are expected to ignore rp, and read only the contents of rt. Users who use such a screen-reader will hear ka-n-ji only once. I think that both of screen reeder users and visual browser users would be happy. If rp is dropped from the spec, screen-readers could't ignore parentheses without fail. So, I think that rp is necessary. In an example i got from an older W3C spec, it's different: Are you talking about Ruby Annotation module for XHTML 1.1? http://www.w3.org/TR/ruby/ ruby rbc rb10/rb rb31/rb rb2002/rb /rbc rtc rtMonth/rt rtDay/rt rtYear/rt /rtc rtc rt rbspan=3Expiration Date/rt /rtc /ruby As this markup isn't used anymore with HTML5, here's how it would be (dropping the expiration date): ruby 10 rtMonth/rt 31 rtDay/rt 2002 rtYear/rt /ruby This one now should be read out by the screen-reader. Otherwise the meaning of the numbers may be not as clear. (Or is the date-example out-of-date and ruby shouldn't be used there?) I think that ruby of HTML5 is not appropriate for the case. According to the HTML5 spec, ruby is primarily used in East Asian typography as a guide for pronunciation or to include other annotations. I think that this element was not designed for the case you mentioned. Ruby Annotation module for XHTML 1.1 can be used for a broad range of objectives. But ruby of HTML5 is limited, I think. Thank you for your time. -- Futomi Hatano www.html5.jp
Re: [whatwg] rp is a styling tag and has no semantic function
Futomi Hatano schrieb:
On Fri, 30 Oct 2009 11:10:59 +0100
Nikita Popov pri...@ni-po.com wrote:
Talking about screen-readers: How should a screen-reader actually handle
ruby annotations? In this case
ruby
漢 rt かん /rt
字 rt じ /rt
/ruby
it would be quite strange if a screen-reader read the annotations,
because they have the same content as the ruby base text. (I hope this
is correct. I don't know the Japanese language, but I understood it as
漢 beeing same as かん only in a different way of writing.) So the
reader must not read the annotation.
More correctly, screen-readers should read only the contents of rt rather
than the base text.
That is, screen-readers are expected to read it as ka-n-ji from rts.
Of course, screen-readers which don't support ruby repeat 2 times such like
ka-n-ka-n-ji-ji as you know.
I am not sure whether it is as easy. Please consider this one:
ruby
char rtpron 1/rt
another char rtpron 2 pron 3/rt
and some other text without a ruby annotation.
/ruby
If a screen-reader now only would read the ruby-annotations, it would
sound like this: pron 1 pron 2 pron 3 and the rest of the text
wouldn't be read.
We also have to get ruby easy to read for visual browser users.
But, the markup above is rendered by non-IE browsers as below.
漢かん字じ
We feel it is odd.
So, I want to mark it up like this.
ruby漢字rp(/rprtかんじ/rtrp)/rp/ruby
This markup is rendered by non-IE browsers as below.
漢字(かんじ)
It's natural and easy to understand.
I fully agree that
漢かん字じ
is odd and not really understandable and that
漢字(かんじ)
is much better. But I still think that
ruby漢字rp(/rprtかんじ/rtrp)/rp/ruby
is not the right way to mark this up. Much better would be:
ruby漢字rtかんじ/rt/ruby
An these two CSS-definitions:
rt:after {
content: ')';
}
rt:before {
content: '(';
}
This would add '(' before and ')' after all ruby-annotations. The only
problem is: Browsers being able to render ruby, will render the
parentheses too. So there must be another CSS-property, something like:
rt:after {
content: ')';
display: ruby-parenthese;
}
rt:before {
content: '(';
display: ruby-parenthese;
}
Browsers not knowing this value for ruby will fall back to display:
inline; and so display the parenthese. Browsers knowing ruby and this
property would not show the parentheses.
I think this is a much cleaner solution for the parentheses and the code
gets more readable.
Nikita Popov
[whatwg] Canvas.cloneNode()
Greetings, Since Last Call was announced and I just ran into this problem, hereby this question: If an image is drawn on a Canvas element, and subsequently the javascript function cloneNode(true) is executed for that element, should the clone include a copy of the source canvas image, or should it show an empty space? From my perspective (the web author), I'd prefer to have the canvas image included when executing (the deep) cloneNode(true), and excluded it when using (the shallow) cloneNode(false). Sincerely, A.E.Veltstra OmegaJunior.Net
[whatwg] Script Data tokenizer mode
When the script data state was added to the tokenizer, the tree construction algorithm was updated to switch the tokenizer into this state upon finding a start tag named script while in the in head insertion mode (9.2.5.7). I see that a corresponding change was not made to 9.5 about Parsing HTML Fragments as it still says to switch into the RAWTEXT state upon finding a script tag. Does anyone know if this difference is intentional, or did someone just forget to update the fragment parsing case? Thanks! -Matt
Re: [whatwg] focus change inside keypress event handler
On Fri, 30 Oct 2009 01:29:00 -0400, Boris Zbarsky bzbar...@mit.edu wrote: On 10/29/09 9:58 PM, Michael A. Puls II wrote: But, in Firefox, Safari and Opera, it's possible to change what element the text is inserted into by changing the focus in 'keydown'. Right; that happens because the keydown and keypress events need not fire on the same element and because the text entry is the keypress default action. In Gecko, that is. I can't speak to Safari and Opera. So, just to be sure, you're happy with that behavior? Which? It being possible to change focus in keydown and thus change where the text will go? Yes. I'm pretty agnostic on whether that should be possible or not. Whichever way makes the event model simpler, I think. This seems wrong to me. If a key is held down, I would expect a single keydown followed by multiple keypresses. O.K. FF doesn't do that though. If you hold down a key, it'll do: keydown keypress over and over. At quick thought, are you O.K. with FF's current behavior being a bug? I don't know. It's worth looking up why the behavior is as it is (that is, what web sites depend on). Multiple keypresses in this situation are a definite necessity. Thanks. Opera seems to get a way with the multiple keydowns. But, its user base isn't as large, so, I'm not sure how much weight that has. Note that 'keyup' may fire before 'keypress' if you release the key before an alert() inside the 'keydown' handler shows and blocks. This seems unfortunate, but ok. Is there a good way to solve that though? Or is that something that should just be left as YMMV? Well, you could require an alert to block all key event delivery to the web page, right? Would that be a desirable solution? Is that hard to implement? -- Michael
Re: [whatwg] focus change inside keypress event handler
On 10/30/09 6:41 PM, Michael A. Puls II wrote: Is there a good way to solve that though? Or is that something that should just be left as YMMV? Well, you could require an alert to block all key event delivery to the web page, right? Would that be a desirable solution? Is that hard to implement? I don't know, and I don't know. The answer to the latter question depends strongly on the precise event model the browser is using, how it interacts with the OS, what it actually does for alert, etc. -Boris
Re: [whatwg] focus change inside keypress event handler
On Fri, 30 Oct 2009 18:56:33 -0400, Boris Zbarsky bzbar...@mit.edu wrote: On 10/30/09 6:41 PM, Michael A. Puls II wrote: Is there a good way to solve that though? Or is that something that should just be left as YMMV? Well, you could require an alert to block all key event delivery to the web page, right? Would that be a desirable solution? Is that hard to implement? I don't know, and I don't know. The answer to the latter question depends strongly on the precise event model the browser is using, how it interacts with the OS, what it actually does for alert, etc. O.K. Thanks -- Michael
Re: [whatwg] focus change inside keypress event handler
On Fri, 30 Oct 2009 00:34:14 -0400, Doug Schepers schep...@w3.org wrote: Hi, Folks- Scott González wrote (on 10/29/09 11:03 AM): On Thu, Oct 29, 2009 at 9:20 AM, Michael A. Puls II shadow2...@gmail.com mailto:shadow2...@gmail.com wrote: Safari and Firefox will allow focus() inside the handler to decide where the character gets inserted, but only with keydown. With keypress (and textInput in webkit) in Firefox and Safari, it appears that the char was already inserted right after keydown, so a focus() change is already too late. Despite that though, preventDefault() still works in Firefox and Safari inside a keypress handler to prevent the char from being inserted. So, I'm not exactly sure what's they're doing behind the scenes. DOM Level 3 Events says The default action of the keypress event depends upon the key and the context: if the key is associated with a character, and if there currently focused element in the document can receive text (such as a form input or an editable text block), the default action is to dispatch a textInput event with the character as the value of the TextEvent.data attribute The default action of a keypress is not to insert a character in the element that has focus, but to insert a character on the element that represents the context of the keypress. In the given example, the keypress's context is the first field, not the second. Correct. So, you're saying that changing the focus() to another field inside the 'keydown' handler (or keypress handler in the case of Opera and IE) MUST NOT change the insertion context (the field in this case that the text gets inserted into)? If so, that would seem to contradict what browsers do when the focus changes inside a 'keydown' handler and contradicts Opera and IE for focus changes inside a 'keypress' handler. Not allowing that would break chase.com's SSI entry for example. (It uses 3 fields and moves to the next field after you've entered 3 numbers, then 2, then 4. I've noticed lots of sites that change focus as you're typing to move the rest of the text to the next field. I'm not sure how many do the focus change inside a handler instead of after/before though. -- Michael
