This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Section: http://www.whatwg.org/specs/web-apps/current-work/#element-level-focus-apis Comment: With Rietveld we have the opposite problem - keyboard shortcut is used to call dialog box with a textarea. When user clicks "Esc" dialog hides, but the focus stays in textarea preventing interaction with other keys. document.body is not focusable, and saved document.activeElement doesn't allow to restore focus. element.blur() seems the only viable alternative. A good alternative would be to traverse up the dom tree to find first focusable element, but AFAICS there is not property that allows to check if an element is focusable. -- anatoly techtonik <techtonik@gmail.com> Posted from: 86.57.247.127
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: I don't understand. Could you elaborate? Opposite problem of what?
You do not recommend to use blur(). More than that - you allow browsers to ignore calls to blur(), and this creates problem in the above user story. 1. you have focused element that user hides by pressing a key (textarea) 2. you need to remove focus that stays on hidden element 3. you can't do body.focus(), because body is not focusable 4. previous element saved in activeElement may not be focusable also 5. so you need to go up the DOM tree to find first focusable element using your custom JavaScript.. ..instead of just calling blur().
Why do you need to remove focus?
Keyboard shortcuts work differently inside and outside of textarea. Go http://codereview.appspot.com/ and press ?
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: Rejected Change Description: no spec change Rationale: I don't see the problem here. Yes, the spec says that browsers are allowed to ignore .blur(), but the specs also say that the user agent can completely ignore the author's style sheets and apply different ones. That's just the way the Web works: user agents work on behalf of the user, not the author. That's why they're called _user_ agents. You can still call .blur() for your case, and if the user trusts you then it'll work fine. If the user doesn't trust you then he'll be in the text area and be able to type, and if he wants to be elsewhere he can manually move focus.
Clarify, please. What does it mean "user trusts you". Do you mean there will be access controls between plain elements on HTML5 pages? You probably did't pay attention to the usability use case of this mouseless keyboard interface. Inside textarea (or any other elements) there are shortcuts that work to provide features for textarea editor. When textarea is hidden (dialog is not on the screen) using keyboard shortcut to save the form - the control should be removed from dialog the same way like it happens with ordinary desktop windows. However, I am not asking to remove the focus automatically from hidden element (but you should consider it), but to make to process easier. Only this way you will be able mouseless user interfaces. You say that "if the blur() method is unwisely being used to remove the focus ring for aesthetics reasons, the page would become unusable by keyboard users". But I try to show you the opposite with real world example - your interface will become unusable if you don't use blur(). You explanation of protecting from "unwise use" is poor. You need a better example on the page.
Don't add TrackerRequest if you reopen.
(In reply to comment #6) > Clarify, please. What does it mean "user trusts you". I mean if the user has indicated (either implicitly or explicitly, depending on the user agent) that the page should be allowed to mess with the focus. (Most browsers assume that their users trust the pages to this extent, for instance.) > Do you mean there will be > access controls between plain elements on HTML5 pages? That's what the browser is. I'm not saying anything new will be introduced though. > You probably did't pay attention to the usability use case of this mouseless > keyboard interface. I actually did. :-) > Inside textarea (or any other elements) there are shortcuts > that work to provide features for textarea editor. When textarea is hidden > (dialog is not on the screen) using keyboard shortcut to save the form - the > control should be removed from dialog the same way like it happens with > ordinary desktop windows. An element that is not being rendered is not focusable, so once you remove the <textarea> there's no need to call .blur() on that element, it's implied. > However, I am not asking to remove the focus > automatically from hidden element (but you should consider it), but to make to > process easier. It can't be much easier than simply happening automatically. :-) > You say that "if the blur() method is unwisely being used to remove the focus > ring for aesthetics reasons, the page would become unusable by keyboard users". > But I try to show you the opposite with real world example - your interface > will become unusable if you don't use blur(). > > You explanation of protecting from "unwise use" is poor. You need a better > example on the page. I disagree with your premise (that the page is unusable if you _don't_ use blur). The example is correct: if you are calling blur() just for aesthetic reasons (which is not the case in your example) then you're going to make the page inaccessible to keyboard users. Your example is not a counter-example to this, it's just an example where someone could use blur() in a way that isn't harmful (but also a way that is not necessary blur(), per the specification, would have no effect in the case you describe, since the element can't be focused at the time the method is called). 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: Rejected Change Description: no spec change Rationale: see comments above
(In reply to comment #8) > > Inside textarea (or any other elements) there are shortcuts > > that work to provide features for textarea editor. When textarea is hidden > > (dialog is not on the screen) using keyboard shortcut to save the form - the > > control should be removed from dialog the same way like it happens with > > ordinary desktop windows. > > An element that is not being rendered is not focusable, so once you remove the > <textarea> there's no need to call .blur() on that element, it's implied. Specification doesn't mention if hidden elements are focusable or not. > > However, I am not asking to remove the focus > > automatically from hidden element (but you should consider it), but to make to > > process easier. > > It can't be much easier than simply happening automatically. :-) Right, but seems like Chrome doesn't support this HTML5 feature. BTW, why the language is so complex? "When an element that is focused stops being a focusable element, or stops being focused without another element being explicitly focused in its stead...". Why not to just say "When focused element becomes non focusable, or focus is removed from it without selecting another element..."?
> Specification doesn't mention if hidden elements are focusable or not. Yes it does. It says "An element is focusable if the user agent's default behavior allows it to be focusable or if the element is specially focusable, *but only if the element is either being rendered*". > Right, but seems like Chrome doesn't support this HTML5 feature. File a bug on Chrome. :-) > BTW, why the language is so complex? > "When an element that is focused stops being a focusable element, or stops > being focused without another element being explicitly focused in its > stead...". Why not to just say "When focused element becomes non focusable, or > focus is removed from it without selecting another element..."? Because it has to be precise. Consider the text you wrote: what does it mean for another element to be selected? Is that to do with text selection? Also, your grammar is not correct English... many of the words you omit are actually needed to be correct English. :-) 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: Rejected Change Description: no spec change Rationale: see above
(In reply to comment #10) > > Specification doesn't mention if hidden elements are focusable or not. > > Yes it does. It says "An element is focusable if the user agent's default > behavior allows it to be focusable or if the element is specially focusable, > *but only if the element is either being rendered*". > > > > Right, but seems like Chrome doesn't support this HTML5 feature. > > File a bug on Chrome. :-) I've made a workaround for all browsers by reimplementing "unfocus steps" logic in JS. > > BTW, why the language is so complex? > > "When an element that is focused stops being a focusable element, or stops > > being focused without another element being explicitly focused in its > > stead...". Why not to just say "When focused element becomes non focusable, or > > focus is removed from it without selecting another element..."? > > Because it has to be precise. Consider the text you wrote: what does it mean > for another element to be selected? Is that to do with text selection? Also, > your grammar is not correct English... many of the words you omit are actually > needed to be correct English. :-) I'd really like to fill the gaps in my education, as I can't see the missing parts. =) On the other side the spec will be useless if there won't be a person who can read correct English. I know that it is better is spec is concise, but you may be compressing the text of spec too much, throwing out user stories on the way. But user stories help to decompress the sense much faster. Maybe they still can be attached externally.