This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Created attachment 1026 [details] Demo page (the demo immitates a frameset page) ISSUE: * @autofocus is currently permitted only on 5 elements: button; input; keygen; select; textarea * HOWEVER, javascript is used to set focus also on other elements. One usecase can be elements that imitated a frame: If the main content of the page is kept inside that element, then authors would like to give focus to that element, so that the user can start to scroll the page by pressing the SPACE key. * Of course, it must continue to only be permitted to have a single @autofocus per page. EXAMPLE PAGE: (also available as attachment): http://tinyurl.com/4xy4nr8 ADVANTAGES: Currently, one must use javascript to do this. This means that autofocus can't be set whenever javascript is disabled or when the author is unfamiliar with javascript. DISADVANTAGE OF CURRENT SITUATION: If a page contains e.g. a <button autofocus> element, the author might still use javascript to give focus to another element than the one with @autofocus set - making @autofocus virtually useless. But, if autofocus could be used to give focus to any element with @tabindex, then the author is more likely to keep @autofocus and javascript in sync (e.g. if he/she uses javascript to target legacy browsers).
MORE ON THE NEED FOR THIS CHANGE: It is currently rather common to "imitate frames" by using position:fixed banners and menus on the top of the page. However, authors often do not realize that this simplistic approach typically will cause the banner to hide content when the user is SPACE key scrolling. Example: http://www.gp.se/ (Swedish news paper with a banner that hides content - 3 to 4 lines - when SPACE key scrolling.) Some are are aware of the issue, and creates a banner that is so low that it doesn't create problems. Example: http://www.bt.no/ (Norwegian newspage where a fixed menu of low hight "pops up" when user is scrolling.I) On the other side, there exists more "true" frame imitations, which however suffer from the problem of getting focus on the content element. Example: http://www.cssplay.co.uk/layouts/fixit.html (A complete frame emulation which suffer from lack of interactivity, since it doesn't give focus to the main content element.) And lastly, frame pages and iframe pages are still in use - and often critisized. However, fact is that frame pages and iframe pages are simpler to give focus to (via Javascript) than it is to give focus to emulated frames: Firefox has a bug when it comes to setting focus on "imitation frames": https://bugzilla.mozilla.org/show_bug.cgi?id=682763 And Opera has a similar bug. These bugs are not present for "real" frame and iframe elements, where it is easy and safe to set the focus. Example of frame based page: http://di.se ( This page does not seem to manage focus - so it is not an example in that regard. So this page ony shows that setting focus via javascript can be a challenge to authors ... Please see the mozilla bug above for test frame and ifram tests. ) SUMMARY: @autofocus on any element with @tabindex will *not* be able to *automatically* solve all the above problems. However, I believe it would: make socalled "CSS frames" (that is: imitated frames) a more serious alternative. We have been bashing frames for a long time, but when one actually try to do CSS frames, then one stumbles on some much of the same problems. Permitting @autfocus on any element with @tabindex, could raise awareness about the correct way as well as raise the awareness of what it actually takes to imitate frames.
PROPOSED NEW SPEC TEXT: ]] The autofocus content attribute allows the author to indicate that a control <INS>or specially focusable element</INS> is to be focused as soon as the page is loaded, allowing the user to just start <INS>interacting with the element via the keyboard (for example </ins> typing<ins> or SPACE key scrolling a scrollabel element)</ins> without having to manually focus the main control <INS> or specially focusable element</INS>. [[
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: Let's see how people do with autofocus on <input> before we start making it even easier to move focus around.
*** Bug 24124 has been marked as a duplicate of this bug. ***