[whatwg] Two propositions for the autofocus attribute

[Jonas Sicking]

On Thu, Apr 15, 2010 at 5:44 PM, Kit Grose <kit at 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