[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 clarifications:
> 
> First, the spec currently says:
> "The autofocus  content attribute allows the user to indicate that a
> control is to be focused *as soon as the page is loaded*" (emphasis
> mine).
> 
> However it then goes on to describe that the control should receive 
> focus as soon as it's inserted into the document. I would recommend 
> changing the emphasized part to say "as soon as it's inserted into the 
> document".

While that would be more accurate, I don't think most authors think of 
parsing as inserting elements into the document, so I fear it may end up 
being less understandable. (The statement is non-normative, so I don't 
think it is of huge importance that it be technically precise.)


> Second, the only normative requirement that I can find is: "Whenever an 
> element with the autofocus attribute specified is inserted into a 
> document whose browsing context did not have the sandboxed automatic 
> features browsing context flag set when the Document was created, the 
> user agent should queue a task that checks to see if the element is 
> focusable, and if so, runs the focusing steps for that element"
> 
> 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?

Only form controls have the autofocus attribute. An attribute with the 
name "autofocus" on other elements is not the autofocus attribute.



On Fri, 16 Apr 2010, Kit Grose wrote:
> 
> I do think if the behaviour you describe is implemented in the spec, 
> pages with multiple elements set to autofocus should be invalid.

They are.


On Fri, 16 Apr 2010, Markus Ernst wrote:
> 
> Is it not possible to say the autofocus attribute is readonly?

No, DOM attributes are inherently writable. It would be a layering 
violation to require otherwise.


On Fri, 16 Apr 2010, Markus Ernst wrote:
> 
> 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 don't think it makes sense for the focus to move multiple times, so I 
don't think we should allow multiple autofocus="" attributes. This is 
doubly the case now that multiple autofocus="" attributes have no effect.


On Sun, 25 Apr 2010, Benjamin Hawkes-Lewis wrote:
> 
> 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?

I think once we introduce a "dialog box" concept, that it would make sense 
to reset the "autofocus" concept to apply again in that context. But we 
don't currently have such a concept.


On Sun, 25 Apr 2010, Garrett Smith wrote:
> 
> The specification uses the term "user" in double meaning, in the same sentence:
> 
> | The autofocus content attribute allows the user to
> | indicate that a control is to be focused as soon as the
> | page is loaded, allowing the user to just start typing
> | without having to manually focus the main control.
> 
> Change to:
> "The autofocus content attribute allows the author..."

Fixed.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Thursday, 29 July 2010 14:53:30 UTC