W3C home > Mailing lists > Public > www-style@w3.org > May 2013

[css3-ui] objections to nav-* properties

From: James Craig <jcraig@apple.com>
Date: Thu, 02 May 2013 14:38:22 -0700
Message-id: <D04B020C-3D38-4385-BE94-7D54841EDFB2@apple.com>
Cc: James Craig <jcraig@apple.com>
To: "www-style@w3.org list" <www-style@w3.org>
I mentioned these issues to Tantek at the 2012 TPAC in Lyon. I can't recall whether I sent them to the CSS list at the time, but just in case, here it is again.

http://dev.w3.org/csswg/css-ui/#nav-index
http://dev.w3.org/csswg/css-ui/#nav-dir

I believe the currently at-risk features nav-index, nav-up, nav-right, nav-down, and nav-left should be either be removed from the CSS3 UI specification, or completely overhauled to account for a cascading navigation context.

As specified, nav-index has the same serious negative implications of positive integer values of tabindex, where in order to be specified usefully, each node has to know about the layout order of every other node in the document. If you're only specifying nav index on first level branches, this is fine, but there is no good way to use this on leaf nodes, and it has severe consequences for breaking index order of keyboard navigation.

This particular problem *might* be solvable with an additional property used on parent or ancestor nodes such as:

	nav-context:  ignore (default) | relative | absolute;

Or potentially by allowing the nav-index context to inherit and cascade. For example:

	[role="toobar"] {
		nav-index: 0; /* retain default tab order until you the user reaches this element or a descendant. */
		nav-context: relative; /* sets the root nav context for this container */
	}
	[role="toobar"] button#b1 {
		nav-index: 1; /* first focusable element within the toolbar; does not override root tab order. */
	}
	[role="toobar"] button#b2 {
		nav-index: 2; /* second focusable element within the toolbar; does not override root tab order. */
	}

Another problem the spec does not solve is the potential for infinite navigation loops with circular references using any of the nav-* properties. The specification should define that circular references are illegal, and it should also define recovery behavior when a rendering engine encounters circular navigation loops.

Unless these issues are addressed or the features are dropped due to lack of implementations, I'll probably file or otherwise recommend a formal objection 

Thanks,
James
Received on Thursday, 2 May 2013 21:38:50 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:11 UTC