Re: [css3-ui] Aligning 'nav-index' with HTML5 tabindex

On Tue, Nov 29, 2011 at 9:50 PM, Tantek Çelik <tantek@cs.stanford.edu> wrote:
> On Mon, Nov 21, 2011 at 09:23, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>> On Sun, Nov 20, 2011 at 3:09 PM, L. David Baron <dbaron@dbaron.org> wrote:
>>> In
>>> particular, HTML5 introduces additional rules for negative values of
>>> the tabindex attribute:
>>> http://dev.w3.org/html5/spec/editing.html#sequential-focus-navigation-and-the-tabindex-attribute
>>> which should probably be representable via a value in CSS.  It's
>>> probably more CSS-like to call this 'nav-index: none' than to assign
>>> special semantics to negative numbers as HTML does.  (CSS
>>> 'nav-index: auto' already corresponds, I believe, to HTML5
>>> tabindex="0".)
>>
>> Not quite.  'auto' corresponds to omitting the HTML attribute
>> entirely.  HTML's "0" value puts it in the 'auto' order, but also
>> makes it focusable if it wasn't already.  'none' is indeed a better
>> name for the "-1" value.
>
> I believe the resolution (or at least perceived consensus from the
> discussion) at the F2F was to harmonize the sets of values. Thus make
> nav-index:auto do the same as HTML's "0" value, and 'none' for -1.

'auto' *can't* mean the same as HTML's "0" value.  If it did, then
there'd be no way to express the same thing as omitting the tabindex
attribute.  In other words, if we did this, every element in the
document would become focusable.

At minimum, we need another value to represent HTML's "0" value.  (I'd
prefer separating out the functionality into another property, as I
expressed.)


>> Given that, I think we might be better
>> served by putting this into a different property, since it's
>> controlling focusability rather than navigation order.
>
> Perhaps, though we tried that in a previous draft of CSS3-UI
> ('user-focus' IIRC) and dropped it.  We can try again with such a new
> property in CSS4-UI perhaps.
>
> See also the existing -moz- prefixed property:
>
> [1] https://developer.mozilla.org/en/CSS/-moz-user-focus

This in incomplete (it's missing the ability to force an element to be
focusable, like @tabindex=0), but it's a good start.


>> I also note that nav-index commits the cardinal sin of allowing only
>> non-zero positive <number>s, which means that its range is bounded but
>> has no minimum value.  This should either allow 0 or allow the full
>> <number> range.
>
> Why?

Not having a minimum value means we can't do things like setting it to
its minimum value when attr() results in a number below its range.


>> HTML only allows integers, but I don't think we should follow, for the
>> same reasons that flex-order is a <number> (and z-index should be).
>>
>> HTML defines that setting tabindex to a valid positive integer *makes*
>> the element focusable.  UI currently does it the other way around -
>> *if* it's focusable, *then* it pays attention to a valid positive
>> nav-index.  We should match HTML here.
>
> Not necessarily. It makes sense for CSS properties to sometimes be a
> *modifier* of existing behavior rather than replace it.
>
> Though in this case it may make sense to make the element focusable.
> We should check what implementations do.

If the intent is to complement the HTML behavior rather than
expose/replace it, then the UA stylesheet is wrong.  Still, in this
case I strongly believe that nav-index should be exposing the behavior
of @tabindex so that authors can manipulate it.

>> Finally, at the last f2f we expressed that -order is a better name for
>> these kinds of properties than -index.  Several compatibility tables
>> tell me that *no one* supports nav-index yet,
>
> Please provide the URLs to the "Several compatibility tables" that
> told you that "*no one* supports nav-index" -
>
> so we know *which* compatibility tables to be wary of since they are
> all wrong on this point.

I used Wikipedia
<http://en.wikipedia.org/wiki/Comparison_of_layout_engines_(Cascading_Style_Sheets)>,
W3Schools <http://www.w3schools.com/cssref/css3_pr_nav-index.asp> and
MSDN <http://msdn.microsoft.com/en-us/library/cc351024(v=vs.85).aspx>.


>>  so can we change this to
>> nav-order?
>
> I'm going to reject bikeshedding/namesmithing a property which has
> already been through a CR.
>
> If we end up dropping it completely, then we can reconsider redefining
> the feature/name however it makes sense for CSS4-UI.

If it's already implemented, then we're probably stuck, yeah.  My
suggestion was based on the assumption that it wasn't implemented yet.


>> Given all this, I suggest the following:
>>
>> 1. Add a property called 'nav-focus', which controls whether an
>> element is focusable or not.  It takes 3 values, 'focus', 'none', and
>> 'auto' (the default).  'focus' makes the element focusable, 'none'
>> makes it unfocusable, and 'auto' makes it focusable if the UA wants
>> to, or if the 'nav-index' property has a <number> value.  Regardless
>> of the value, the UA should apply additional heuristics to determine
>> whether an element can be focused, such as disallowing it if the
>> element is display:none or visibility:hidden.
>
> I think brainstorming in email tends to be a bad idea.
>
> Nonetheless, if you're serious about your proposal, I encourage you to
> write-up additional UI related proposals (or even suggestions,
> requests) on the CSS4-UI wiki page:
>
> http://wiki.csswg.org/spec/css4-ui

Done.


>> 3. Make 'nav-order' follow the HTML tabindex conventions, where
>> providing a value makes the element focusable (mention the 'nav-focus'
>> property here?).  Then, just lean on the set of focusable elements,
>> rather than trying to be explicit about what's navigable, so that
>> future changes to HTML or CSS can grow or shrink the set of focusable
>> elements without us needing to update anything.
>
> It's not clear that's what's been implemented for 'nav-index' so
> that's not within the scope of CSS3-UI. If you can provide test cases
> demonstrating as such in Opera for example, we can reconsider.

Is Opera the only impl?  If so, I'd suggest changing it even if it
didn't match, because having its behavior differ gratuitously from the
same mechanism in HTML is all kinds of bad.

Testing on a recent public Opera, I can't get nav-index to work at
all.  It's recognized as a property, but it has no effect even on
focusable elements, while @tabindex works as normal.

>> 4. Make 'nav-order' accept 0 as a valid value.  Preferably, make it
>> accept negative numbers as well.
>
> Seems fine. I'll add it to CSS3-UI if Opera is ok with implementing
> this addition.
>
> I can see the reasoning of being able to re-use the tabindex attribute
> values, e.g. as you wrote:
>  attr(tabindex as number, auto);

Cool.

~TJ

Received on Thursday, 1 December 2011 23:31:30 UTC