[whatwg] an odd example of the meter element
Hi, all I found an odd example in the meter element section of the spec. http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-meter-element metermax: 100; current: 75/meter According to steps for finding one or two numbers of a ratio in a string, does it means that the actual value is 100 and the max value is 75? http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#steps-for-finding-one-or-two-numbers-of-a-ratio-in-a-string If so, the gauges would end up looking maxed out. Should it be as below? metercurrent: 75; max: 100;/meter Thank you. -- Futomi Hatano www.html5.jp
Re: [whatwg] an odd example of the meter element
Futomi Hatano wrote: Hi, all I found an odd example in the meter element section of the spec. http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-meter-element metermax: 100; current: 75/meter According to steps for finding one or two numbers of a ratio in a string, does it means that the actual value is 100 and the max value is 75? http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#steps-for-finding-one-or-two-numbers-of-a-ratio-in-a-string If so, the gauges would end up looking maxed out. Should it be as below? metercurrent: 75; max: 100;/meter Thank you. No, the larger number is always used as the max, and the smaller as current. In the meter section: (...) if there were two numbers parsed out of the textContent, then the maximum is the higher of those two numbers. and (...) if the result of processing the textContent of the element was two numbers, then the actual value is the lower of the two numbers found. -- Magnus Kristiansen Don't worry; the Universe IS out to get you.
Re: [whatwg] an odd example of the meter element
On Thu, 29 Oct 2009 10:58:17 +0100 Magnus Kristiansen magnusrk+wha...@pvv.org wrote: No, the larger number is always used as the max, and the smaller as current. In the meter section: (...) if there were two numbers parsed out of the textContent, then the maximum is the higher of those two numbers. and (...) if the result of processing the textContent of the element was two numbers, then the actual value is the lower of the two numbers found. Oh!, I'm sorry. I overlooked what you pointed out. Thank you for letting me know. -- Futomi Hatano www.html5.jp
Re: [whatwg] window.setInterval if visible.
On Thu, Oct 15, 2009 at 10:53 PM, Markus Ernst derer...@gmx.ch wrote: From a performance point of view it might even be worth thinking about the contrary: Allow UAs to stop the execution of scripts on non-visible windows or elements by default, and provide a method to explicitly specify if the execution of a script must not be stopped. fwiw, the N900 browser (microb) does this by default. it breaks google talk in gmail among other things. (You can turn this option off through the browser menus, you don't need to use about:config.) in many ways it's bad, especially since once broken, pages can't really be fixed, and users don't really understand that we broke it because they let us. being able to send a Hibernate and Resume event pair to web apps could be neat, but we don't have the resources to see if we could convince pages to respond to them. If you provide methods to check the visibility of a window or element, you leave it up to the author to use them or not. I think performance issues should rather be up to the UA. We're trying, but, well, it's too early to see what people will say about our efforts. (fwiw, I work on the team which did this, but I'm entirely opposed to it, because explaining it to authors and users is impossible/impractical).
Re: [whatwg] window.setInterval if visible.
On Fri, Oct 30, 2009 at 12:23 AM, timeless timel...@gmail.com wrote: On Thu, Oct 15, 2009 at 10:53 PM, Markus Ernst derer...@gmx.ch wrote: From a performance point of view it might even be worth thinking about the contrary: Allow UAs to stop the execution of scripts on non-visible windows or elements by default, and provide a method to explicitly specify if the execution of a script must not be stopped. fwiw, the N900 browser (microb) does this by default. it breaks google talk in gmail among other things. (You can turn this option off through the browser menus, you don't need to use about:config.) in many ways it's bad, especially since once broken, pages can't really be fixed, and users don't really understand that we broke it because they let us. being able to send a Hibernate and Resume event pair to web apps could be neat, but we don't have the resources to see if we could convince pages to respond to them. Why don't you just treat this like bfcache and fire pagehide and pageshow events? 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
Nikita Popov wrote: In the spec the use of the rp-tag is shown like this: ruby 漢 rp(/rprtかん/rtrp)/rp 字 rp(/rprtじ/rtrp)/rp /ruby What semantic function has the rp-tag? No. It is only styling for browsers not supporting ruby-text. So I think this element musn't be in the HTML5 spec. You can add the brackets before and after the ruby text using CSS pseudoclasses (:after, :before). Putting ruby content into CSS is a really really bad idea since this will become generated content and have all the issues of selectability and voice-over readability of generated content... /Daniel -- W3C CSS WG, Co-Chair
Re: [whatwg] focus change inside keypress event handler
On Wed, 28 Oct 2009 10:57:43 -0400, Jacob Rossi ro...@gatech.edu wrote:
On Wed, Oct 28, 2009 at 2:43 AM, Michael A. Puls II
shadow2...@gmail.comshadow2...@gmail.com?subject=re%3a%20%5bwhatwg%5d%20focus%20change%20inside%20keypress%20event%20handlerIn-Reply-To=%253Ca9699fd20910280201h3c7990a1s7cb9a7e5dc2c60c1%40mail.gmail.com%253EReferences=%253Ca9699fd20910280201h3c7990a1s7cb9a7e5dc2c60c1%40mail.gmail.com%253E
wrote:
(CCing DOM list just in case anyone there has any comments)
With:
pinput onkeypress=this.nextSibling.focus()input/p
, if you type a character in the first field, should the character be
entered in the second field or the first?
In Firefox and Safari, it's the first field. In IE and Opera, it's the
second.
[...]
I do think FF and Safari's way makes more sense and I think most will
agree.
The keypress event is similar to textInput. Their intent is to indicate
when character data has been entered. textInput is more powerful and
captures character input from a number of input sources (keyboard, IME,
voice, etc). In both cases, I would consider the default action to be the
insertion of the characters into the DOM. For *most* events, the default
action isn't performed until after event dispatch. Accordingly, I would
expect that calling focus() during the dispatch of the keypress (or
textInput) event would result in moving the cursor prior to the character
data being inserted (because events are synchronous). Thus I think it
makes
most sense for the character to appear in the second input box.
Another reason why this should be the case is what happens when you
cancel
the default action (call preventDefault() ). Canceling a textInput or
keypress event should prevent the character from being inserted. So
that's
further evidence that the character insertion should happen after
dispatch
of the event.
Thanks. That makes sense technically.
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.
Note that Opera for example doesn't allow preventDefault() to have any
effect in the keydown handler. It only works in the keypress handler
more like you expect.
For clarification, if I press 'd' in the first input of:
pinputinput/p
script
window.onload = function() {
var inp = document.getElementsByTagName(input)[0];
function test(e) {
alert(e.type);
}
inp.addEventListener(textInput, test, false);
inp.addEventListener(keydown, test, false);
inp.addEventListener(keypress, test, false);
inp.addEventListener(keyup, test, false);
};
/script
1. What order do those fire in?
2. What ones can you use preventDefault() in to stop the character from
being inserted?
3. For each one that you can use preventDefault() in to stop the insertion
of the 'd', if you use preventDefault(), which of the others will not fire?
4. When is the 'd' actually suppposed to be inserted (what the spec says,
not necessarily what browsers do)? (This will help determine what handlers
you can use focus() in to change what field the typed char gets inserted
in)
Also:
5. What are the list of keys that trigger keydown? (or do not if that's
easier)
6. What are the list of keys that trigger keypress? (or do not if that's
easier)
7. What are the list of keys that trigger keyup? (or do not if that's
easier)
8. For HTML5 and the 'input' event, if I add another lineto the above,
inp.addEventListener('input', test, false), when does 'input' fire? Before
the others? After the others? Does #3 apply here?
Basically, if anyone can describe in words all the steps that should
happen with the example code above, that'd be great. (If it's even defined
anywhere)
Thanks
In short though, browsers don't agree on this stuff and it's difficult to
decide what the right thing to do is in regards to how it's supposed to
work. I could even throw other events that detect modification of the
fields value to complicate things even more.
--
Michael
Re: [whatwg] focus change inside keypress event handler
On 10/29/09 9:20 AM, Michael A. Puls II wrote: 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. Last I checked in Gecko, things looked somewhat like this: Editors (those editable things inside text inputs) set up some default actions (effectively event listeners in the system event group). The default keypress event action is to enter the character. When you press a button on your keyboard, the focus is used for one thing and one thing only: to decide where to dispatch the key events. So the keypress event is dispatched to the thing that has focus. If one of the event handlers for keypress changes what has the focus, that doesn't change where the default action of the keypress event takes place (since the event target chain is built completely before any of the event handling takes place). Make sense? Note that Opera for example doesn't allow preventDefault() to have any effect in the keydown handler. It only works in the keypress handler more like you expect. You might be interested in https://bugzilla.mozilla.org/show_bug.cgi?id=167145 1. What order do those fire in? 2. What ones can you use preventDefault() in to stop the character from being inserted? 3. For each one that you can use preventDefault() in to stop the insertion of the 'd', if you use preventDefault(), which of the others will not fire? These are all excellent questions that the spec should answer. 4. When is the 'd' actually suppposed to be inserted (what the spec says, not necessarily what browsers do)? (This will help determine what handlers you can use focus() in to change what field the typed char gets inserted in) This is two separate questions: 1) When is the 'd' actually inserted? 2) When is the element the 'd' will be inserted in determined? In Gecko, the answers are effectively: 1) During the default action phase of the keypress event, assuming that it has not had preventDefault() called via various mechanisms (e.g. preventDefault() on keydown will trigger preventDefault on all resulting keypresses in Gecko). 2) Immediately before the keypress event is fired. (two sides of the same coin, really, since this is just how default actions work in DOM event land). In short though, browsers don't agree on this stuff and it's difficult to decide what the right thing to do is in regards to how it's supposed to work. I could even throw other events that detect modification of the fields value to complicate things even more. Yep. And you could use script to set .value at various points in there, leading to fun questions about how onchange should work, too. It's a mess. ;) -Boris
Re: [whatwg] focus change inside keypress event handler
On Thu, Oct 29, 2009 at 9:20 AM, Michael A. Puls II shadow2...@gmail.comwrote: 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. I agree though that the documentation could be clearer about this as it's not explicitly stated.
[whatwg] Character casing for Appropriate End Tags and the temporary buffer
Prior to r4177, the matching of tag names for exiting the RCDATA/RAWTEXT states was done as follows: ...and the next few characters do no match the tag name of the last start tag token emitted (compared in an ASCII case-insensitive manner) However, the current revision doesn't include any comment on character casing in its discussion of Appropriate End Tags. Similarly, certain tokenizer states require that you check the contents of the temporary buffer against the string script but there is no indication of whether or not to do this in a case-insensitive manner. In both cases, should this comparison be done in an ASCII case-insensitive manner or not? It might be helpful to clarify the spec in both places in either case. Thanks! -Matt
Re: [whatwg] Character casing for Appropriate End Tags and the temporary buffer
Apologies for the repost -- here is the original e-mail in plain text: Prior to r4177, the matching of tag names for exiting the RCDATA/RAWTEXT states was done as follows: ...and the next few characters do no match the tag name of the last start tag token emitted (compared in an ASCII case-insensitive manner) However, the current revision doesn't include any comment on character casing in its discussion of Appropriate End Tags. Similarly, certain tokenizer states require that you check the contents of the temporary buffer against the string script but there is no indication of whether or not to do this in a case-insensitive manner. In both cases, should this comparison be done in an ASCII case-insensitive manner or not? It might be helpful to clarify the spec in both places in either case. Thanks! -Matt
Re: [whatwg] Character casing for Appropriate End Tags and the temporary buffer
Matt Hall wrote: Apologies for the repost -- here is the original e-mail in plain text: Prior to r4177, the matching of tag names for exiting the RCDATA/RAWTEXT states was done as follows: ...and the next few characters do no match the tag name of the last start tag token emitted (compared in an ASCII case-insensitive manner) However, the current revision doesn't include any comment on character casing in its discussion of Appropriate End Tags. Similarly, certain tokenizer states require that you check the contents of the temporary buffer against the string script but there is no indication of whether or not to do this in a case-insensitive manner. In both cases, should this comparison be done in an ASCII case-insensitive manner or not? It might be helpful to clarify the spec in both places in either case. It is already case-insensitive as you lowercase the characters when creating the token name and when adding them to the buffer. -- Geoffrey Sneddon — Opera Software http://gsnedders.com/ http://www.opera.com/
Re: [whatwg] Character casing for Appropriate End Tags and the temporary buffer
Of course :-). Thanks a lot, Geoffrey! -Matt -Original Message- From: Geoffrey Sneddon [mailto:gsned...@opera.com] Sent: Thursday, October 29, 2009 8:59 AM To: Matt Hall Cc: whatwg@lists.whatwg.org Subject: Re: [whatwg] Character casing for Appropriate End Tags and the temporary buffer Matt Hall wrote: Apologies for the repost -- here is the original e-mail in plain text: Prior to r4177, the matching of tag names for exiting the RCDATA/RAWTEXT states was done as follows: ...and the next few characters do no match the tag name of the last start tag token emitted (compared in an ASCII case-insensitive manner) However, the current revision doesn't include any comment on character casing in its discussion of Appropriate End Tags. Similarly, certain tokenizer states require that you check the contents of the temporary buffer against the string script but there is no indication of whether or not to do this in a case-insensitive manner. In both cases, should this comparison be done in an ASCII case-insensitive manner or not? It might be helpful to clarify the spec in both places in either case. It is already case-insensitive as you lowercase the characters when creating the token name and when adding them to the buffer. -- Geoffrey Sneddon - Opera Software http://gsnedders.com/ http://www.opera.com/
Re: [whatwg] focus change inside keypress event handler
On Thu, 29 Oct 2009 10:14:42 -0400, Boris Zbarsky bzbar...@mit.edu wrote: On 10/29/09 9:20 AM, Michael A. Puls II wrote: 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. Last I checked in Gecko, things looked somewhat like this: Editors (those editable things inside text inputs) set up some default actions (effectively event listeners in the system event group). The default keypress event action is to enter the character. When you press a button on your keyboard, the focus is used for one thing and one thing only: to decide where to dispatch the key events. So the keypress event is dispatched to the thing that has focus. If one of the event handlers for keypress changes what has the focus, that doesn't change where the default action of the keypress event takes place (since the event target chain is built completely before any of the event handling takes place). Make sense? I think so. The event target isn't changed by focus(). But, in Firefox, Safari and Opera, it's possible to change what element the text is inserted into by changing the focus in 'keydown'. Note that Opera for example doesn't allow preventDefault() to have any effect in the keydown handler. It only works in the keypress handler more like you expect. You might be interested in https://bugzilla.mozilla.org/show_bug.cgi?id=167145 Thanks. Read all of it. That helps with the history of it and the thoughts at the time. 1. What order do those fire in? 2. What ones can you use preventDefault() in to stop the character from being inserted? 3. For each one that you can use preventDefault() in to stop the insertion of the 'd', if you use preventDefault(), which of the others will not fire? These are all excellent questions that the spec should answer. Yes indeed. 4. When is the 'd' actually suppposed to be inserted (what the spec says, not necessarily what browsers do)? (This will help determine what handlers you can use focus() in to change what field the typed char gets inserted in) This is two separate questions: 1) When is the 'd' actually inserted? 2) When is the element the 'd' will be inserted in determined? In Gecko, the answers are effectively: 1) During the default action phase of the keypress event, assuming that it has not had preventDefault() called via various mechanisms (e.g. preventDefault() on keydown will trigger preventDefault on all resulting keypresses in Gecko). 2) Immediately before the keypress event is fired. (two sides of the same coin, really, since this is just how default actions work in DOM event land). O.K., thanks. In short though, browsers don't agree on this stuff and it's difficult to decide what the right thing to do is in regards to how it's supposed to work. I could even throw other events that detect modification of the fields value to complicate things even more. Yep. And you could use script to set .value at various points in there, leading to fun questions about how onchange should work, too. It's a mess. ;) :) Does the following description make sense (ignoring textInput for now) or sound good? 'keydown' fires first. If a handler for 'keydown' calls preventDefault() (explicitly or implicitly via returning false), do not fire 'keypress' after the 'keydown' handler returns. If a handler for 'keydown' does not call preventDefault(), and the key pressed represents text, after the 'keydown' handler returns, fire 'keypress' with the insertion context element (Thanks Scott for the 'context' hint) being the element that's currently focused after the 'keydown' handler returns and right before 'keypress' is fired. If the key pressed does not represent text, do not fire 'keypress'. If 'keypress' was fired, and the handler for it calls preventDefault() (explicitly or implicitly via return false), after the handler returns, do not insert the text. If 'keypress' was fired and the handler for it does not call preventDefault(), after the handler returns, insert the text in the insertion context element. If the key is being held down, 'keydown' or both 'keydown' first and then 'keypress' second will fire repeatedly according to the rules above. Once the key is finally released and 'keydown' stops firing, always fire 'keyup' no matter what. Note that 'keyup' may fire before 'keypress' if you release the key before an alert() inside the 'keydown' handler shows and blocks. In short, 'keydown' and 'keyup' *always* fire when pressing and releasing a key. Whether 'keypress' is fired and something is inserted into the field (and which field) and whether keypress fires before keyup, depends on the rules above. (Note that the above description describes how things seem from testing on the user/author side, not from the
[whatwg] Request to reconsider input minlength=
Greetings,
I saw HTML5 was put into last call, and I wanted to add my request to
reconsider adding input minlength= to HTML5. With some searching,
I found the following threads on the topic:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2006-February/005892.html
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-June/011661.html
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-October/016881.html
From these threads, I've seen the main reasons not to add the
attribute are:
* Lack of use cases
* input pattern= / can do the same job
* Unclear how user agents should implement the UI
* It's not compelling enough to balloon the spec
I recently completed a JavaScript form validation implementation using
HTML5 attributes and similar DOM methods (form.checkValidity(),
input.checkValidity() and input.setCustomValidity()). This API was
perfect, with the exception of missing minlength=.
Use Case
Our username and password fields require a minimum of four characters.
These fields have a simple pattern validation as well. I initially set
up the inputs as:
input required pattern=[a-z0-9]{4,} maxlength=20 /
This performs the desired validation correctly, but the problem comes
when reporting the validation error to the user.
validity.patternMismatch is semantically different than
validity.tooShort
In order to correctly report the error to the user, I would have to do
a second check of the value to figure out the problem. The only way to
determine that the error was caused by too few characters as opposed
to invalid characters would be to parse the pattern= attribute in
order to determine a minimum length required by the RegExp. Yuck. If
the value was too long, this job would be handled by maxlength=. I
added a minlength= attribute.
The final result:
input required pattern=[a-z0-9]+ minlength=4 maxlength=20 /
Is more readable, provides a validation task I believe to be quite
common without requiring knowledge of regular expressions.
Michael Fortin asked this question:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-June/011683.html
Should an
input with minlength smaller than it's value be filled with padding
characters? Before or after the value? And what happens to those
characters as you type?
My answer: the UI should not be altered due to the presence of
minlength until validating the input value. There's no need to pad the
value or prevent deletion of characters.
Although I lack formal numbers, pretty much every password field I've
seen on the Internet requires a minimum number of characters, as do
most usernames.
The only legitimate argument against minlength= is that there is no
room for it in the spec, and I personally disagree with that assessment.
Cheers,
--
Ryan Cannon
http://ryancannon.com/
Re: [whatwg] Request to reconsider input minlength=
On Thu, Oct 29, 2009 at 3:03 PM, Ryan Cannon r...@ryancannon.com wrote: In order to correctly report the error to the user, I would have to do a second check of the value to figure out the problem. The only way to determine that the error was caused by too few characters as opposed to invalid characters would be to parse the pattern= attribute in order to determine a minimum length required by the RegExp. I have two problems with this argument: * It assumes you know enough detail of your validation pattern to know that it can fail distinctly for too short versus something else, and you want to report those differently, yet you don't actually know the precise conditions that trigger those errors well enough to code them directly, and instead you have to parse the pattern yourself after-the-fact. This seems like a stretch. * It assumes that too short is semantically distinct from fails validation for other reasons, when other distinctions seem potentially just as important. For example, many password implementations require a minimum number of numeric digits or characters of some other type. Why is too few characters of type X so much less worthy of distinct handling in the spec than too few characters of any type, if the primary use cases here are fields like passwords and usernames? Should an input with minlength smaller than it's value be filled with padding characters? Before or after the value? And what happens to those characters as you type? My answer: the UI should not be altered due to the presence of minlength until validating the input value. There's no need to pad the value or prevent deletion of characters. With maxlength, UAs can provide a version of the user's input that obeys the constraints. Without some form of padding, the same is not true of minlength. The distinction in handling these makes me uncomfortable. I agree with you that if your sole goal is to tell the user that something is too short, minlength saves you a bit of code. I'm not convinced it's compelling enough that it must go in. PK
Re: [whatwg] focus change inside keypress event handler
On 10/29/09 5:24 PM, Michael A. Puls II wrote: I think so. The event target isn't changed by focus(). 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. 'keydown' fires first. If a handler for 'keydown' calls preventDefault() (explicitly or implicitly via returning false), do not fire 'keypress' after the 'keydown' handler returns. No. That breaks sites, at least in our experience (as described in https://bugzilla.mozilla.org/show_bug.cgi?id=167145). If the key is being held down, 'keydown' or both 'keydown' first and then 'keypress' second will fire repeatedly according to the rules above. This seems wrong to me. If a key is held down, I would expect a single keydown followed by multiple keypresses. 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. When holding down a key, it just repeatedly fires 'keypress', instead of just 'keydown' or both 'keydown and 'keypress' like Firefox and Safari. That behavior makes a lot of sense to me, actually. As for Firefox, it's different too in that preventDefault() doesn't stop any events from firing. It just stops text insertion in some cases. Yes. We found that to be necessary for web compat. Ultimately though, the spec should define all this stuff clearly in a way that all browsers can implement. Yes, though there might be some interesting differences here modulo what events the browser's host environment supports... -Boris
Re: [whatwg] focus change inside keypress event handler
On Thu, 29 Oct 2009 20:51:48 -0400, Boris Zbarsky bzbar...@mit.edu wrote: On 10/29/09 5:24 PM, Michael A. Puls II wrote: I think so. The event target isn't changed by focus(). 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? 'keydown' fires first. If a handler for 'keydown' calls preventDefault() (explicitly or implicitly via returning false), do not fire 'keypress' after the 'keydown' handler returns. No. That breaks sites, at least in our experience (as described in https://bugzilla.mozilla.org/show_bug.cgi?id=167145). O.K., will assume that 'keypress' always needs to fire then. If the key is being held down, 'keydown' or both 'keydown' first and then 'keypress' second will fire repeatedly according to the rules above. 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? 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? When holding down a key, it just repeatedly fires 'keypress', instead of just 'keydown' or both 'keydown and 'keypress' like Firefox and Safari. That behavior makes a lot of sense to me, actually. O.K., cool. As for Firefox, it's different too in that preventDefault() doesn't stop any events from firing. It just stops text insertion in some cases. Yes. We found that to be necessary for web compat. O.K., cool. Ultimately though, the spec should define all this stuff clearly in a way that all browsers can implement. Yes, though there might be some interesting differences here modulo what events the browser's host environment supports... Understood. I'll put together a new description with the changes to see if sounds good. Thanks very much. -- Michael
Re: [whatwg] focus change inside keypress event handler
On Oct 29, 2009, at 5:51 PM, Boris Zbarsky wrote: On 10/29/09 5:24 PM, Michael A. Puls II wrote: I think so. The event target isn't changed by focus(). 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. 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. Regards, Maciej
Re: [whatwg] focus change inside keypress event handler
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. -Boris
Re: [whatwg] focus change inside keypress event handler
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? 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. 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? -Boris
