Re: [csswg-drafts] Please add "tab-index" to CSS specification

Browsers correctly recognize tab-index="100" for many elements. They are tabbed then in the order of tags (after all other) elements. But tab-index can be also defined like "z-index" (similar behaviour) but then... the default value cannot be coded as CSS (like above) - local mode. 

The tab-index is supported by all browsers identically except of firefox for input[type="radio"] if all are unchecked. Firefox tabs via all unchecked radio's, other browsers tabs only via first of group. 

Thus this behaviour is the easiest to implement. 
Ascending order - I used this term on purpose. We can treat [1, 2, 4, 8, 100, 105] as ascending and [1, 2, 2, 2, 3, 4, 5, 5, 5] also. Maybe "not descending order" will be more correct phrase?

My description can be updated by other users. I poorly speak english. 

Nav-pre, nav-next (if there will be identifiers) can make infinite loop and trigger developers to "id-itis" ("id"-like div-itis/class-itis).  

BTW. I tkink, the tab-index will by used mainly for elements with set "tabindex" property and form controls. In this purpose, here is a little elements for styling and developer for each skin (layout) can define it if it is possible. 

If other solution is better, it also can be implemented instead this, but Opera (Presto, before WebKit) has implemented this algorithm (except "none"). Currently tab order in many layouts is chaotic and there is possible to access controls that should by inaccessible. It is more needed than pointer-events. Disabling of elements (for mouse and touch only) can be reached via negative z-index and additional layer (via ::after or ::before) on other element. 

Does new-pre/next is able to disable any element from tab-queue? 

-- 
GitHub Notification of comment by Nadya678
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1748#issuecomment-323996826 using your GitHub account

Received on Tuesday, 22 August 2017 11:20:26 UTC