Created attachment 1026 [details]
Demo page (the demo immitates a frameset page)
* @autofocus is currently permitted only on 5 elements: button; input; keygen; select; textarea
* 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
DISADVANTAGE OF CURRENT SITUATION:
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.
(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.
(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.
(A complete frame emulation which suffer from lack of interactivity,
since it doesn't give focus to the main content element.)
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.
authors ... Please see the mozilla bug above for test frame and ifram tests. )
@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:
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. ***