发布于 2015-09-05 20:07:58
基于我在这个演示中发现的这个问题,我得到了以下答案:
tabindex 只需将属性添加到您希望具有可聚焦性的元素中.
// Add this to createdCallback function:
if (!this.hasAttribute('tabindex')) {
// Choose one of the following lines (but not both):
this.setAttribute('tabindex', 0);
this.tabIndex = 0;
}
// The browser automatically syncs tabindex attribute with .tabIndex property.单击该元素将使其具有焦点。按下标签就行了。在CSS中使用:focus也是可行的。keydown和keyup事件可以工作,尽管keypress不工作(但是无论如何,这是不可取的。)。在Chrome 44和Firefox 40上进行了测试。
还请注意,即使缺少this.tabIndex属性,也会返回-1,但这与设置tabindex="1"不同。
<foo></foo>:没有tabindex属性,元素是不可聚焦的。<foo tabindex="-1"></foo>:该元素无法通过选项卡导航访问,但仍然可以通过单击进行调整。参考文献:
发布于 2015-09-15 00:20:47
@Denilson,我想向您提供更多的信息。
正如您说过的,当您的when组件不包含可聚焦的元素时,this.tabIndex = 0可以工作。如果是的话,就会变得更复杂。
例如,如果组件包含一个或多个输入,那么“整体”组件首先获得焦点,然后,只有在选项卡时,每个内部输入逐个获得焦点。这通常不是你想要的。通常,当组件获得焦点时,这意味着它的第一个输入立即获得焦点。
此外,还有一个反向制表的问题。如果您的第一个输入有焦点,并且您按SHIFT-TAB,那么“整体”组件将获得焦点,并且您被迫按SHIFT-TAB两次才能移动到前面的元素。
我发现这解决了所有的焦点和标签问题:
// At first, the component may get focus and accept tabbing.
createdCallback = function () { this.tabIndex = 0; }
// When the component gets focus, pass focus to the first inner element.
// Then make tabindex -1 so that the component may still get focus, but does NOT accept tabbing.
focus = function (e) { firstFocusableInnerElement.focus(); this.tabIndex = -1; }
// When we completely left the component, then component may accept tabbing again.
blur = function (e) { this.tabIndex = 0; }备注:到目前为止(2015年9月),如果一个内部元素获得焦点,那么:focus伪选择器(仅在Chrome中测试)不匹配“整体”元素。如果发现这种行为完全是错误的。焦点事件被触发,而模糊事件没有被触发。所以元素应该有焦点,对吗?我希望他们将来能改变这一点。
发布于 2022-09-27 16:30:50
简单回答:你需要的是delegatesFocus tabindex**.** ,而不是
详细信息:假设您在阴影DOM中有交互式元素,没有令人满意的方法可以让组件以编程方式使用tabindex
0,则将主机元素添加到制表符序列(“顺序键盘导航”)中,并有一个额外的制表符停止。-1,那么不仅要从制表符序列中移除主机元素,而且还要移除其阴影DOM中的任何交互元素,这样键盘用户就无法访问整个事件。有一个web就是这样的:ShadowRoot.delegatesFocus,参见这里。将此设置为true,您将得到:
.focus()或单击组件中任何不可聚焦的部分都会聚焦阴影DOM中的第一个可聚焦元素:focus样式除了应用到主机中的焦点元素之外,还应用于主机。它是支持的,因为阴影DOM v1。
https://stackoverflow.com/questions/32417235
复制相似问题