CSS 中的选项卡索引
是否可以使用 CSS 控制 tabindex,如果可以,哪些浏览器支持它以及哪些元素支持它?
编辑
我应该说,我的目标是捕获 div 上的 keydown 事件。我看到了这个页面 http://www.quirksmode.org/js/events/keys.html# 测试键盘事件,它表明 keydown 在除文档和正文或某种表单元素或链接之外的任何内容上触发的唯一方法是在其上声明 tabindex。但我在 W3C 网站上读到:
以下元素支持 tabindex属性:A、AREA、BUTTON、 输入、对象、选择和文本区域。
所以我有点困惑,该怎么做才能符合标准并使我的用例发挥作用?
EDIT2
我的整个用例是一个包含大量内容和人工滚动条的 div。我可以通过鼠标事件滚动它,但到目前为止键盘还没有运气。
Is it possible to control tabindex with CSS and if yes, which browsers support it and on which elements?
EDIT
I should say, my goal is to catch keydown events on a div. I saw this page http://www.quirksmode.org/js/events/keys.html# that tests keyboard events and it shows that the only way keydown fires on anything other than document and body or some kind of form element or link is to have tabindex declared on it. But I read on W3C site:
The following elements support the
tabindex attribute: A, AREA, BUTTON,
INPUT, OBJECT, SELECT, and TEXTAREA.
So I am a little confused, what to do in order to be standarts compliant and make my use case work?
EDIT2
My whole use case is a div with a lot of content with an artificial scroll bar. I am able to scroll it with mouse events but no luck with the keyboard so far.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
更新 2017
正如 @Wallop 在评论中指出的,
nav-index
属性是 由于“缺乏实施兴趣”而于 2015 年从规范中删除。查看 W3C 在 CSS3-UI。
此属性与
tabindex
具有完全相同的行为,并且适用于任何元素。nav-index
可能是该用例的最佳符合标准的解决方案,到目前为止仅由 Opera 解释(截至 2012 年 6 月)并且还被 W3C 标记为“存在风险的功能”,因此可能随时被删除。替代的跨浏览器解决方案有:
不符合标准:在
DIV
上设置tabindex
属性。这适用于所有常见浏览器。符合标准:将
DIV
替换为不带href
属性集的锚元素 (A
),并使用display 对其进行样式设置:块
并添加tabindex
属性。关于 BoltClock 的观点,我同意 Tab 键顺序非常符合逻辑(文本选择顺序和 Tab 键顺序都与文档中元素的排列顺序密切相关)。另一方面,CSS 如今有着更广泛的用途。它不仅可以操作文档的内容(
content
属性),还可以操作事件触发时的行为:即使用pointer-events
、display
或z-index
指针事件的顺序将会改变。如果这些是非常基本的 CSS 属性,为什么您也不能影响 KeyBoardEvents?Update 2017
As pointed out by @Wallop in the comments, the
nav-index
property was dropped from the spec in 2015 due to "lack of implementation interest".Take a look at the
nav-index
property introduced by W3C in CSS3-UI.This property has exactly the same behavior as a
tabindex
and is applicable to any element.Being probably the best standards-compliant solution for the use case,
nav-index
is interpreted only by Opera so far (as of June 2012) and is also marked as "Feature at risk" by W3C, therefore may be dropped any time.Alternative cross-browser solutions are:
non-standards-compliant: set the
tabindex
attribute on aDIV
. This will work in all common browsers.standards-compliant: replace
DIV
by an anchor element (A
) without ahref
attribute set, style it withdisplay: block
and add thetabindex
attribute.With respect to BoltClock´s point, I agree that the tabbing order is very logical (both the text selection order and tabbing order are closely related to the sequence in which elements are aranged in the document). On the other hand, CSS has a wider purpose today. It can manipulate not just the content of a document (
content
property) but also the behavior when and if events are to be fired: i.e. usingpointer-events
,display
orz-index
the pointer event's order will change. If these are very basic CSS properties, why you should not be able to influence KeyBoardEvents, too?这有点旧了,但现在有像 -moz-user-focus 这样的 css 选项。我确信有一个 webkit 等效项。
https://developer.mozilla.org/en-US /docs/CSS/-moz-user-focus
user-focus
是标准的跨浏览器属性。This is a bit old but now there are css options like -moz-user-focus. I'm sure there is a webkit equivalent.
https://developer.mozilla.org/en-US/docs/CSS/-moz-user-focus
user-focus
is the standard cross browser attribute.我需要用键盘禁用焦点,这对我没有帮助。我最终使用这个作为一个足够好的解决方法:
这似乎工作得足够好,屏幕阅读器不会宣布瞬时焦点,并且它几乎不会眨眼。
I needed to disable focus with keyboard, which
pointer-events: none
would not help me with. I ended up using this as a good enough workaround:This seem to work good enough, screen readers do not announce that momentary focus and it barely ever blinks for a moment.