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

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:
>> One of the issues that came up in the joint meeting between CSS and
>> WAI Protocols & Formats at TPAC (on October 31) was the 'nav-index'
>> property in http://dev.w3.org/csswg/css3-ui/#nav-index .  (This is
>> the first of two messages (on different topics) to follow up on that
>> discussion.)
>
> Thanks for the followup, David!
>
>> There was some discussion about aligning it with HTML5.

Yes I've captured that in my notes as well.


>> 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.


> 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


>> Additionally, I suspect some additional changes are needed to align
>> the description with the one given in HTML5, though I haven't looked
>> into this closely.  (I did notice that css3-ui refers to content
>> order as "the order they appear in the character stream", which
>> doesn't appear to me to be a sensible definition following DOM
>> manipulation.)
>
> Shame on Tantek for the layering violation!  Nothing in the platform
> sees a character stream unless it's actually doing parsing.  Just
> doing a s/the order they appear in the character stream/document
> order/ will fix it.

Good catch and thanks. Fixed.


> 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?


> 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.


> 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.

Opera has supported[2] nav-index for some time.
[2] http://www.opera.com/docs/specs/presto22/#css

In addition, Tasman v1 (incorporated into MSTV for various set top
boxes) supported nav-index.
The DVB-HTML and ATSC specifications incorporated nav-index as well.

However, I am unable to find current web simulators for MSTV Tasman,
DVB-HTML, or ATSC that could be used to test their support, thus I'm
placed 'nav-index' (and the directional nav properties) "at risk"
since there is only one known current implementation (Opera).

Consider this an open request for anyone to find/provide MSTV Tasman,
DVB-HTML, or ATSC simulators.

Perhaps someone from Microsoft can look into providing a URL to a MSTV
Tasman simulator.  Folks involved with DVB-HTML (is it even used any
more?) and ATSC should provide a (preferably free) downloadable web
content simulator.


>  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.


> 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


> 2. Change 'nav-index' or 'nav-order', to match the future precedent
> being set by 'flex-order' rather than the old precedent set by
> 'z-index', because the WG generally agrees that it's a better name.

"future precedent" sounds a bit too double-thinky to me. Insufficient
to justify a name change.

Not to mention reasoning on a to-be-published Working Draft update vs.
something that's already been through a CR.


> 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.


> 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);

Thanks,

Tantek

-- 
http://tantek.com/ - I made an HTML5 tutorial! http://tantek.com/html5

Received on Wednesday, 30 November 2011 05:52:19 UTC