CSS 中的选项卡索引

发布于 2024-10-17 01:11:55 字数 542 浏览 6 评论 0原文

是否可以使用 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 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

空城旧梦 2024-10-24 01:11:56

更新 2017

正如 @Wallop 在评论中指出的,nav-index 属性是 由于“缺乏实施兴趣”而于 2015 年从规范中删除


查看 W3C 在 CSS3-UI

此属性与 tabindex 具有完全相同的行为,并且适用于任何元素。

“nav-index”属性是一种与输入方法无关的方式,用于指定顺序导航顺序(也称为“Tab 键顺序”)。
此属性是 HTML4/XHTML1 属性“tabindex”的替代品

nav-index 可能是该用例的最佳符合标准的解决方案,到目前为止仅由 Opera 解释(截至 2012 年 6 月)并且还被 W3C 标记为“存在风险的功能”,因此可能随时被删除。

替代的跨浏览器解决方案有:

  • 不符合标准:在 DIV 上设置 tabindex 属性。这适用于所有常见浏览器。

  • 符合标准:将 DIV 替换为不带 href 属性集的锚元素 (A),并使用 display 对其进行样式设置:块并添加tabindex属性。

关于 BoltClock 的观点,我同意 Tab 键顺序非常符合逻辑(文本选择顺序和 Tab 键顺序都与文档中元素的排列顺序密切相关)。另一方面,CSS 如今有着更广泛的用途。它不仅可以操作文档的内容(content 属性),还可以操作事件触发时的行为:即使用 pointer-eventsdisplayz-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.

The ‘nav-index’ property is an input-method-neutral way of specifying the sequential navigation order (also known as "tabbing order").
This property is a replacement for the HTML4/XHTML1 attribute ‘tabindex’

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 a DIV. This will work in all common browsers.

  • standards-compliant: replace DIV by an anchor element (A) without a href attribute set, style it with display: block and add the tabindex 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. using pointer-events, display or z-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?

雨后彩虹 2024-10-24 01:11:56

这有点旧了,但现在有像 -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.

双手揣兜 2024-10-24 01:11:56

我需要用键盘禁用焦点,这对我没有帮助。我最终使用这个作为一个足够好的解决方法:

.not-focusable {
  pointer-events: none;
}

.not-focusable:focus {
  visibility: hidden;
}

这似乎工作得足够好,屏幕阅读器不会宣布瞬时焦点,并且它几乎不会眨眼。

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:

.not-focusable {
  pointer-events: none;
}

.not-focusable:focus {
  visibility: hidden;
}

This seem to work good enough, screen readers do not announce that momentary focus and it barely ever blinks for a moment.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文