[whatwg] Two propositions for the autofocus attribute

On Thu, Apr 15, 2010 at 3:43 PM, Mounir Lamouri
<mounir.lamouri at gmail.com> wrote:
> 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.

Sorry to butt in, but I should clarify *why* this change is needed.
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.


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".

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?

/ Jonas

Received on Thursday, 15 April 2010 16:08:46 UTC