Re: [whatwg] Two propositions for the autofocus attribute
On Thu, 29 Jul 2010, Paul Ellis wrote:
In this kind of situation, you'd just use focus(). There's not much
point using autofocus if you're already running code; the main win of
the attribute is simplifying the page and not requiring scripting, but
if you've already got code the cost of an additional focus() is
minimal.
I agree that if you are comparing:
var html = input id='mySearch' type='text' autofocus;
document.getElementById('myDiv').innerHTML = html;
to
var html = input id='mySearch' type='text';
document.getElementById('myDiv').innerHTML = html;
document.getElementById('mySearch').focus();
then the cost is minimal.
However there are a lot of instances of scripts retrieving HTML blobs
where it is much more convenient and compatible with the work flow that
the focus is determined using HTML instead of JS. If you take a common
example such as a Facebook-style modal dialog you can see that it
would be easy to return HTML with an input autofocus. Any HTML
editor/generator could set focus this way and it would be easy to convey
that functionality to the UA as it is part of the content.
Sure but in this kind of scenario the focus is already somewhere, so the
user agent wouldn't move the focus automatically anyway -- it would assume
that would annoy the user.
I think long-term we're better off adding an explicit dialog element
where we can do this kind of thing (and then it would make sense to reuse
autofocus).
It would seem to me that focus should always be set on the last element to
have autofocus.
That's what we used to have, but it makes the focus jump around while the
page is loading, which is why we changed this in the first place.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Two propositions for the autofocus attribute
On Thu, Jul 29, 2010 at 2:53 PM, Ian Hickson i...@hixie.ch wrote:
On Fri, 16 Apr 2010, Kit Grose wrote:
I agree with you both generally, but I disagree that there are no
downsides. I imagine the main use-case where this sort of behaviour
might be expected is a Javascript application which dynamically adds a
new form to the page based on some user interaction and one of those
fields should be autofocused when it's been added to the DOM.
I don't think that's the main use case. The main use case is static pages
that just use script to focus the control.
However, I could see an argument that we should handle the case of a page
that loads a stub script which then loads a blob of HTML in and inserts it
after onload -- that, in combination with the points above, argues that we
should not prevent autofocus from working after onload, but that we should
make it only work once. I've specced that.
For instance, picture the Gmail model. When you first load, the
autofocus attribute could conceivably be on the inbox search field. When
you click Compose, the compose form will be dynamically added and the
To field should be autofocused (but the search field is still
on-screen)
I suppose you could argue that it'd be up to the application to go and
*remove* the previous autofocus attribute from the search field, or
should manage focus as they currently do with HTMLInputElement.focus(),
but I can see the simplicity that automatically moving the focus would
represent for these sorts of applications.
In this kind of situation, you'd just use focus(). There's not much point
using autofocus if you're already running code; the main win of the
attribute is simplifying the page and not requiring scripting, but if
you've already got code the cost of an additional focus() is minimal.
I agree that if you are comparing:
var html = input id='mySearch' type='text' autofocus;
document.getElementById('myDiv').innerHTML = html;
to
var html = input id='mySearch' type='text';
document.getElementById('myDiv').innerHTML = html;
document.getElementById('mySearch').focus();
then the cost is minimal.
However there are a lot of instances of scripts retrieving HTML blobs where
it is much more convenient and compatible with the work flow that the focus
is determined using HTML instead of JS. If you take a common example such as
a Facebook-style modal dialog you can see that it would be easy to return
HTML with an input autofocus. Any HTML editor/generator could set focus
this way and it would be easy to convey that functionality to the UA as it
is part of the content.
As soon as it you get into requiring JS to call .focus() for any focus
action after onload then things get complicated. It becomes something that
has to be conveyed out-of-band from the HTML throughout the whole work flow.
Now my HTML form editor needs to tell the backend to tell the UA to call
.focus() on a specific element after that HTML has been sent _and_ rendered
to the client. That can be done, but it certainly isn't elegant or simple.
It would seem to me that focus should always be set on the last element to
have autofocus. This would address the dialog scenario and work well with
common CMS practices. A site may use a CMS (e.g. a blog, Drupal, SharePoint,
etc) that may generate a static page (from the perspective of the UA) that
has autofocus on a search box at the top of the page. However, when the user
goes to a page with a form it would autofocus on the form as it would be
farther down the page (presumably).
Paul Ellis
Re: [whatwg] Two propositions for the autofocus attribute
On Fri, 16 Apr 2010, Mounir Lamouri wrote: At the moment, the autofocus attribute specification [1] is quite permissive: only one element should have the autofocus enabled in the document but each time an element with autofocus is inserted into the document, the UA should give it the focus. The UA can disable the autofocus request for some reasons like if the user is already typing into a document. As far as I know, the autofocus attribute has been introduced to autofocus a form field during the load process to prevent doing that in js and thus focusing an element after the load of the document. To better fulfill this need, I think we should add two rules for the autofocus attribute behavior: - only the first element with the autofocus attribute specified should get the focus. All other autofocus requests should be ignored. This is exactly the same for authors because they should not have more than one element with the autofocus attribute specified but that would be better for the user because it will prevent autofocus to move from a field to another. - if an element with the autofocus attribute specified is inserted after the load event (or the 'DOMContentLoaded' event) it should not get the focus. Having an element inserted in the document with the autofocus attribute specified is just a way to prevent using .focus(). That is not why autofocus has been introduced. If an author want to focus an element after the load event, he/she should use .focus(). On Thu, 15 Apr 2010, Jonas Sicking wrote: Consider the following document: html body form input id=c1 autofocus /form ...lots of content here... form input id=c2 autofocus /form /body /html When the c1 element is inserted into the DOM, the UA focuses this control. Later, when the c2 element is inserted into the DOM, the spec currently states that the c2 element is the one that should be autofocused as that is the last one with autofocus specified. However the spec also makes the, IMHO good, recommendation to not autofocus an element if the user is already interacting with some other form control. The simplest way to implement this would be to not honor the autofocus attribute if another form control already has focus. This is technically implementable. However it means that you have to keep track of if c1 was focused due to the user clicking on c1 (or otherwise navigate to, for example using the keyboard), or if it was due to autofocus being specified. But this isn't enough, as the user might have already started interacting with c1 by typing into it. Technically, c1 could still have been focused due to the autofocus, but if the user has started interacting with it, then this doesn't really matter. To make matters worse, the user might *just* be about to start interacting with it, but haven't yet done so. While we could deploy a bunch of heuristics, it seems much simpler to just say that it is the *first* element with autofocus that should receive focus. I can't think of any significant downsides with this. On Fri, 16 Apr 2010, Kit Grose wrote: I agree with you both generally, but I disagree that there are no downsides. I imagine the main use-case where this sort of behaviour might be expected is a Javascript application which dynamically adds a new form to the page based on some user interaction and one of those fields should be autofocused when it's been added to the DOM. I don't think that's the main use case. The main use case is static pages that just use script to focus the control. However, I could see an argument that we should handle the case of a page that loads a stub script which then loads a blob of HTML in and inserts it after onload -- that, in combination with the points above, argues that we should not prevent autofocus from working after onload, but that we should make it only work once. I've specced that. For instance, picture the Gmail model. When you first load, the autofocus attribute could conceivably be on the inbox search field. When you click Compose, the compose form will be dynamically added and the To field should be autofocused (but the search field is still on-screen) I suppose you could argue that it'd be up to the application to go and *remove* the previous autofocus attribute from the search field, or should manage focus as they currently do with HTMLInputElement.focus(), but I can see the simplicity that automatically moving the focus would represent for these sorts of applications. In this kind of situation, you'd just use focus(). There's not much point using autofocus if you're already running code; the main win of the attribute is simplifying the page and not requiring scripting, but if you've already got code the cost of an additional focus() is minimal. On Thu, 15 Apr 2010, Jonas Sicking wrote: I'd also like to ask for two
Re: [whatwg] Two propositions for the autofocus attribute
On Mon, Apr 26, 2010 at 1:54 AM, timeless timel...@gmail.com wrote: On Mon, Apr 26, 2010 at 2:14 AM, Garrett Smith dhtmlkitc...@gmail.com wrote: we had a manager who insisted on a feature where the browser would move focus to the urlbar in certain cases. [...] Maybe his typing is also slow or maybe he doesn't use the feature repeatedly/ on most static pages, his intended behavior is arguably useful. (his claim was if nothing is focussed, and the url bar isn't visible, then typing should jump to the urlbar, so that i can easily type 'google.com'.) No accesskeys or tabbing? [...] Sure, and that code would surely e a mistake; perhaps using two separate include files. The developer adding the second might wonder: Why does c2 not get focus? He would find his mistake, eventually (hopefully soon!) and fix it. developers are unlikely to find such mistakes because they're likely to have very fast computers with very short links to their servers. users otoh tend to have slow computers with long and slow links to the real servers. besides, i believe we've established that c2 would get focus (unless there's a user involved), so that developer wouldn't notice a problem at all. Yes, that was established. The problem is that c2 gets focus; the developer won't notice that; but the user on the slow wifi connection will get a very bad experience when the focus is shifting automatically. I can easily see such problem being created on a project where a page happens to have two features with autofocus, uses multiple includes, and has different developers working on separate features. The proposed behavior would help eliminate problems like that because when a second autofocus is added, it won't get autofocused. The developer should then notice that his autofocus did not work and problem should be more obvious. My comments were an argument to justify the proposed change. Considering a case where a page contains an iframe, the iframe's content is replaced entirely:- iframeDoc.body.innerHTML = divinput autofocus type='text'\/div; - should the input get autofocus or not? What other edge cases are there? (I still think its a bad feature). Garrett
Re: [whatwg] Two propositions for the autofocus attribute
- multiple autofocused elements per page are valid, but only one per form Is it possible to focus on multiple elements at the same time even in different forms? If they are both text boxes and a user types which element gets the keyboard input? Autofocus only really makes at load time - for any other dynamic focus I think .focus() should be used.
Re: [whatwg] Two propositions for the autofocus attribute
On Thu, Apr 15, 2010 at 11:43 PM, Mounir Lamouri mounir.lamo...@gmail.com wrote: To better fulfill this need, I think we should add two rules for the autofocus attribute behavior: - only the first element with the autofocus attribute specified should get the focus. All other autofocus requests should be ignored. This is exactly the same for authors because they should not have more than one element with the autofocus attribute specified but that would be better for the user because it will prevent autofocus to move from a field to another. But it wouldn't prevent /focus/ moving, since publishers could call focus(), so from a user perspective I can't see the advantage? - if an element with the autofocus attribute specified is inserted after the load event (or the 'DOMContentLoaded' event) it should not get the focus. Having an element inserted in the document with the autofocus attribute specified is just a way to prevent using .focus(). That is not why autofocus has been introduced. If an author want to focus an element after the load event, he/she should use .focus(). I think focusing using autofocus is better than forcing developers to use focus(). Consider a dialog box added to a webpage using JS. autofocus allows separation of concerns between the layout of controls within the dialog and the script. If you use focus() only, you must update the script with knowledge of which control to focus as the layout of controls changes. If you use autofocus, the first focused control in the dialog can be changed without touching the script. Maybe I'm just missing the problem you're trying to solve here? -- Benjamin Hawkes-Lewis
Re: [whatwg] Two propositions for the autofocus attribute
On Thu, Apr 15, 2010 at 10:52 PM, timeless timel...@gmail.com wrote: fwiw, w/ the mobile browsers i work w/, random focus changes are incredibly annoying. we had a manager who insisted on a feature where the browser would move focus to the urlbar in certain cases. Why is the manager making decisions about U/X? Does he believe he is qualified to do that? Unless somebody properly tells him otherwise, he may likely go on believing that. as a result users often have text they're typing spread across at least two input areas. Is it username and password? GMail does that, changing focus around on me and it is annoying when I get the error message telling me that I typed the wrong password when I didn't; gmail just changed focus around on me and that caused a problem. needless to say, our users/engineers are not amused. Did you demonstrate the problems? There is a chance that he is totally ignorant to the consequences of doing that. Maybe his typing is also slow or maybe he doesn't use the feature repeatedly/ also note that dom insertion is somewhat random, so: form input id=c1 autofocus /form form input id=c2 autofocus /form could either focus c1, or it could focus c2, depending on random-ish things like packet size. Sure, and that code would surely e a mistake; perhaps using two separate include files. The developer adding the second might wonder: Why does c2 not get focus? He would find his mistake, eventually (hopefully soon!) and fix it.
Re: [whatwg] Two propositions for the autofocus attribute
On Thu, Apr 15, 2010 at 4:08 PM, Jonas Sicking jo...@sicking.cc wrote: On Thu, Apr 15, 2010 at 3:43 PM, Mounir Lamouri mounir.lamo...@gmail.com wrote: Hi, [...] However the spec also makes the, IMHO good, recommendation to not autofocus an element if the user is already interacting with some other form control. The simplest way to implement this would be to not honor the autofocus attribute if another form control already has focus. People will want this for the worst reason. I am aware that this has been discussed on this list and that it is not going to go away. From the html 5 draft: | User agents may ignore this attribute if the user has indicated | (for example, by starting to type in a form control) that he | does not wish focus to be changed. What if the user indicates by pushing space bar, arrow key, page down, to scroll the document? What if the user clicks in the trackbar area. What if the user has already scrolled the document and that element is not within in view? Is it focused? Drawing focus to an element means that it is scrolled into view. A great example of awful usability with autofocus is PubMed. 0) Enable javascript and use a modern popular browser (Firefox 3.5+, IE7) with default settings 1) Go to: http://www.ncbi.nlm.nih.gov/sites/entrez 2) Type in search box testosterone 3) Hit Enter 4) When the search result appears, attempt to scroll the document using the spacebar or arrow keys. Expected result: Document scrolls. Actual result: When the onload fires, the input is focused. If the spacebar is pressed after that, the autocomplete widget is displayed. The actual U/X varies depending on time to onload. If the page loads before the space bar was pressed, the autocomplete shows and the page is not scrolled. If the page does not load before the space bar was pressed, the page is scrolled down, as expected. Then, if spacebar is pressed, the input is focused, causing the page to scroll back up to where the input is in view, and causing the autocomplete to be displayed. The reason I mention this in such painful detail is that the specification uses weasel words to describe U/X. Once more, those words: | User agents may ignore this attribute if the user has indicated | (for example, by starting to type in a form control) that he | does not wish focus to be changed. This puts undue burden on the implementation to try to determine the case where the user has indicated that he does not wish the focus to be changed. While we could deploy a bunch of heuristics, it seems much simpler to just say that it is the *first* element with autofocus that should receive focus. I can't think of any significant downsides with this. The downside is when the user does not want the element to autofocus. However, I also agree that the proposed change is less bad. [...] Nowhere in this does it restrict this to form controls. However the spec only defines the 'autofocus' attribute as valid on form controls. So I assume that the above requirement was intended to only apply to form controls? Or should you be allowed to autofocus links? You make it sound like links and inputs are the only focusable objects on a page. Garrett
Re: [whatwg] Two propositions for the autofocus attribute
Am 16.04.2010 02:44 schrieb Kit Grose: On 16/04/2010, at 9:08 AM, Jonas Sicking wrote: While we could deploy a bunch of heuristics, it seems much simpler to just say that it is the *first* element with autofocus that should receive focus. I can't think of any significant downsides with this. I agree with you both generally, but I disagree that there are no downsides. I imagine the main use-case where this sort of behaviour might be expected is a Javascript application which dynamically adds a new form to the page based on some user interaction and one of those fields should be autofocused when it's been added to the DOM. For instance, picture the Gmail model. When you first load, the autofocus attribute could conceivably be on the inbox search field. When you click Compose, the compose form will be dynamically added and the To field should be autofocused (but the search field is still on-screen) Is it not possible to say the autofocus attribute is readonly? It dose IMO not make sense to apply it via scripting, as focus() is available for scripting.
Re: [whatwg] Two propositions for the autofocus attribute
On 16/04/2010, at 5:06 PM, Markus Ernst wrote: Is it not possible to say the autofocus attribute is readonly? It dose IMO not make sense to apply it via scripting, as focus() is available for scripting. What if the form is received via XHR as HTML and simply injected to the page using innerHTML? I admit I don't know of any other read-only HTML attributes to test the standard behaviour under those conditions. A more similar outcome to this might be how browsers cope with adding an additional input type=radio name=foo checked/ element to a form with another radio button named accordingly. A cursory glance shows that WebKit checks the new input and unchecks the previous selection, even if the user had previously made a selection. —Kit
Re: [whatwg] Two propositions for the autofocus attribute
Am 16.04.2010 09:30 schrieb Kit Grose: On 16/04/2010, at 5:06 PM, Markus Ernst wrote: Is it not possible to say the autofocus attribute is readonly? It dose IMO not make sense to apply it via scripting, as focus() is available for scripting. What if the form is received via XHR as HTML and simply injected to the page using innerHTML? What would you say about this: - multiple autofocused elements per page are valid, but only one per form - the actual effect, as suggested before, is restricted to the page loading process and to the first element with the autofocus attribute Like this, if you write an application that relies on forms received by XHR, and if you don't know the form structure at authoring time, it is not difficult to add a function that, after the form is inserted, looks for an element with autofocus and focus()es it at runtime. I admit I don't know of any other read-only HTML attributes to test the standard behaviour under those conditions. A more similar outcome to this might be how browsers cope with adding an additional input type=radio name=foo checked/ element to a form with another radio button named accordingly. A cursory glance shows that WebKit checks the new input and unchecks the previous selection, even if the user had previously made a selection. I was thinking about checked (resp. defaultChecked) too, when I wrote my previous post. Anyway, the case is somehow different, as a change of checkedness is a visible change of the form values, and if it is made unexpectedly this is likely to be an authoring error. Unexpected focus changes on the other hand are a potential hassle which can even result in data loss or incomplete submission (if the focus changes from a textarea to an input element, and the user is not aware of it and hits enter).
Re: [whatwg] Two propositions for the autofocus attribute
On 2010-04-16 09:30, Kit Grose wrote: On 16/04/2010, at 5:06 PM, Markus Ernst wrote: Is it not possible to say the autofocus attribute is readonly? It dose IMO not make sense to apply it via scripting, as focus() is available for scripting. What if the form is received via XHR as HTML and simply injected to the page using innerHTML? If the user has already started interacting with other controls in the page, like form controls, a contenteditable region or is typing into some control in the browser chrome (e.g. the address bar or quickfind textbox), the autofocus behaviour should not occur. Otherwise, if the user hasn't interacted with the page, then the control should be focussed. Personally, I also agree that it makes sense for autofocus to only apply to the first such control. However, Opera's implementation currently works as specified in the spec, focussing the last such control that is inserted. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
[whatwg] Two propositions for the autofocus attribute
Hi, At the moment, the autofocus attribute specification [1] is quite permissive: only one element should have the autofocus enabled in the document but each time an element with autofocus is inserted into the document, the UA should give it the focus. The UA can disable the autofocus request for some reasons like if the user is already typing into a document. As far as I know, the autofocus attribute has been introduced to autofocus a form field during the load process to prevent doing that in js and thus focusing an element after the load of the document. To better fulfill this need, I think we should add two rules for the autofocus attribute behavior: - only the first element with the autofocus attribute specified should get the focus. All other autofocus requests should be ignored. This is exactly the same for authors because they should not have more than one element with the autofocus attribute specified but that would be better for the user because it will prevent autofocus to move from a field to another. - if an element with the autofocus attribute specified is inserted after the load event (or the 'DOMContentLoaded' event) it should not get the focus. Having an element inserted in the document with the autofocus attribute specified is just a way to prevent using .focus(). That is not why autofocus has been introduced. If an author want to focus an element after the load event, he/she should use .focus(). What is your opinion about these two propositions ? [1] http://dev.w3.org/html5/spec/forms.html#attr-fe-autofocus Thanks, -- Mounir
Re: [whatwg] Two propositions for the autofocus attribute
On 16/04/2010, at 9:08 AM, Jonas Sicking wrote: While we could deploy a bunch of heuristics, it seems much simpler to just say that it is the *first* element with autofocus that should receive focus. I can't think of any significant downsides with this. I agree with you both generally, but I disagree that there are no downsides. I imagine the main use-case where this sort of behaviour might be expected is a Javascript application which dynamically adds a new form to the page based on some user interaction and one of those fields should be autofocused when it's been added to the DOM. For instance, picture the Gmail model. When you first load, the autofocus attribute could conceivably be on the inbox search field. When you click Compose, the compose form will be dynamically added and the To field should be autofocused (but the search field is still on-screen) I suppose you could argue that it'd be up to the application to go and *remove* the previous autofocus attribute from the search field, or should manage focus as they currently do with HTMLInputElement.focus(), but I can see the simplicity that automatically moving the focus would represent for these sorts of applications. —Kit
Re: [whatwg] Two propositions for the autofocus attribute
On Thu, Apr 15, 2010 at 5:44 PM, Kit Grose k...@iqmultimedia.com.au wrote: On 16/04/2010, at 9:08 AM, Jonas Sicking wrote: While we could deploy a bunch of heuristics, it seems much simpler to just say that it is the *first* element with autofocus that should receive focus. I can't think of any significant downsides with this. I agree with you both generally, but I disagree that there are no downsides. I imagine the main use-case where this sort of behaviour might be expected is a Javascript application which dynamically adds a new form to the page based on some user interaction and one of those fields should be autofocused when it's been added to the DOM. For instance, picture the Gmail model. When you first load, the autofocus attribute could conceivably be on the inbox search field. When you click Compose, the compose form will be dynamically added and the To field should be autofocused (but the search field is still on-screen) I suppose you could argue that it'd be up to the application to go and *remove* the previous autofocus attribute from the search field, or should manage focus as they currently do with HTMLInputElement.focus(), but I can see the simplicity that automatically moving the focus would represent for these sorts of applications. You basically only have a 50/50 percent chance of things working anyway. You're assuming that the new forms will always be added after the new ones. It seems to me that it's quite likely that they will be before. Worse, the spec (IMHO rightly) suggests that if the user is already interacting with another part of the page, the autofocus attribute should be ignored. So in this case the 'compose' link will be focused, and so the UA should IMHO assume that the user is interacting with that link. Thus it would not focus the newly inserted form control. / Jonas
Re: [whatwg] Two propositions for the autofocus attribute
On 16/04/2010, at 10:54 AM, Jonas Sicking wrote: Worse, the spec (IMHO rightly) suggests that if the user is already interacting with another part of the page, the autofocus attribute should be ignored. So in this case the 'compose' link will be focused, and so the UA should IMHO assume that the user is interacting with that link. Thus it would not focus the newly inserted form control. Actually, you're right. I can't see any situation where this is expected behaviour if interacting includes scroll/link focus/keyboard events (which I can only imagine they do). I do think if the behaviour you describe is implemented in the spec, pages with multiple elements set to autofocus should be invalid. Hopefully if UAs implement ignore focus requests if the user is typing for the autofocus attribute they can extend that behaviour to the standard focus() function and it'll therefore be less user hostile to use the function on our sites. —Kit
Re: [whatwg] Two propositions for the autofocus attribute
fwiw, w/ the mobile browsers i work w/, random focus changes are incredibly annoying. we had a manager who insisted on a feature where the browser would move focus to the urlbar in certain cases. as a result users often have text they're typing spread across at least two input areas. needless to say, our users/engineers are not amused. also note that dom insertion is somewhat random, so: form input id=c1 autofocus /form form input id=c2 autofocus /form could either focus c1, or it could focus c2, depending on random-ish things like packet size. form input id=c1 autofocus /form form input id=c2 autofocus /form form input id=c1 autofocus /form form input id=c3 autofocus /form form input id=c4 autofocus /form form input id=c5 autofocus /form form input id=c6 autofocus /form form input id=c7 autofocus /form would not make me happy either.
