- From: Leif Arne Storset <lstorset@opera.com>
- Date: Wed, 31 Jul 2013 11:01:44 +0200
- To: "www-style@w3.org list" <www-style@w3.org>, "James Craig" <jcraig@apple.com>
- Cc: "Giuseppe Pascale" <giuseppep@opera.com>
On Wed, 31 Jul 2013 10:51:41 +0200, Leif Arne Storset <lstorset@opera.com> wrote: > On Thu, 02 May 2013 23:38:22 +0200, James Craig <jcraig@apple.com> wrote: > >> 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. > > [snip nav-index objection] > >> 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. > > I don't see how navigation cycles present a problem. Consider a set of > links, for example a script-animated slideshow or featured products, > arranged horizontally: > > [A celebrity] [B celebrity] [C celebrity] [D celebrity] [Related > celebrity stories] > [A product] [B product] [C product] > > It's entirely reasonable to want the user to be able to navigate right > from the "Related stories" pane and reach A. (In code, something like > '#a {nav-right: #b } /* etc. */ #related { nav-right: #a }'). With > appropriate UI (for instance, a right arrow labeled "Back to start") it > could even be intuitive. (Granted, ID specification would probably be > superfluous, but it doesn't seem reasonable to make it illegal.) > > I didn't implement this, so I may be overlooking some hidden complexity, > but I assume the UA can look up elements by ID quite simply. I don't see > that the UA needs to pre-compute navigation paths, and thus deal > programmatically with cycles as such. I forgot to mention that with four navigation directions, it would actually be strange if cycles are not encountered. For example, with links organized in a diamond, together with Back and Close links: [←] [Coffee] [x] [Vision] [Mission] [Fission] the author might choose to explicitly state that navigating down from Coffee leads to Vision or to Fission, and that navigating up from Vision goes back to Coffee instead of Back. -- Leif Arne Storset Opera Software
Received on Wednesday, 31 July 2013 09:02:26 UTC