https://bugzilla.wikimedia.org/show_bug.cgi?id=29199
Matthew Flaschen <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords|easy | --- Comment #34 from Matthew Flaschen <[email protected]> --- We should consider possible options we have other than lastTabIndex. According to http://www.w3.org/TR/html401/interact/forms.html#adef-tabindex , positive tabindexes are first (this is how it works with lastTabIndex). Then come tabindex 0 elements, which come in character stream order. This could work, since navigation comes late in our document. However, I think 0 tabindex is equivalent to omitted in most cases. That also raises the important question, why exactly is an explicit tabindex needed here (I don't have OTRS access)? In Firefox and Chromium, it seems that the search box included in the actual tab order anyway, and late in the page. Is the goal to make search late in the tab order, but still before the navigation elements with no tabindex (e.g. Read/Edit tabs)? Could we potentially solve this by having a dedicated tabindex range for navigation elements in particular areas of the page? We have 0 and 32767 available according the W3C, and it doesn't have to be contiguous, so reserving ranges would seem to be doable. -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
