[whatwg] Two propositions for the autofocus attribute

[Garrett Smith]

On Thu, Apr 15, 2010 at 4:08 PM, Jonas Sicking <jonas at sicking.cc> wrote:
> On Thu, Apr 15, 2010 at 3:43 PM, Mounir Lamouri
> <mounir.lamouri at 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