[whatwg] Two propositions for the autofocus attribute

[Paul Ellis]

 On Thu, Jul 29, 2010 at 2:53 PM, Ian Hickson <ian at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100729/fc20c2b8/attachment-0002.htm>