Re: [csswg-drafts] [css-nav-1] Reordered sequential navigation (#3377)

(This is probably the wrong place to put this but I'm replying to posts in this thread about reading order and 2D order).

Right now we have the dom order, the reading order, the tab order, and the visual order.

Ignoring `tabindex`, the dom order = the reading order = the tab order (for some sufficiently permissive definition of equality) but the visual order is essentially decoupled from these by CSS.

The reading order and the tab order can be affected by CSS with `display: none` but that only removes subtress from the reading and tab orders—it does not allow them to be permuted.

The end result is that there are these neat things I can do visually with CSS that I cannot do when taking accessibility into account (which should be always) because the reading and tab orders remain unchanged and fall out of sync with the visual order. Grid and flexbox allow a lot of cool, easy layouts but the dom order remains a hard constraint on what can be done. Generally, reading and tab order should follow dom order, but a sensible escape hatch would be a great enabler.

From what I can tell, css-nav-1 allows the focus order to be extended to 2d based on visual distance and spatial navigation containers. This is very cool and useful, but does not seem to affect the reading order.

Reading up on the issues that led to this draft, I saw a lot of calls to control the tab order in CSS, either explicitly or to follow ordering changes by, say, flexbox. That would allow reordering things visually while maintaining a natural tab order, but the reading order would still fall out of sync and skip around unnaturally.

Generally, I think it's good to keep the tab order bound to the reading order. Those go together naturally. If two buttons are right next to each other in the reading order they should be next to each other in the tab order and logically next to each other in the visual order. 

While the reading order and, barring css-nav-1, the tab order are linear in nature, even without any CSS they are still laid out in 2d based on the dimensions of the language by chunking it into strips in the inline dimension that are stacked in the block dimension. I'm going to stick with top to bottom, left to right from now on, because it's the only one that I'm sufficiently familiar with. This defines an approximate lexicographical order where, for English at least, something in the top left is before something in the bottom right, but this could be cultural bias on my part that does not generalize. Regardless, I don't think this alone is sufficient to define an order since layouts are really 3d and you can have non-statically positioned elements floating about or even just 2d layouts that fit together in visually clear ways that would be hard to determine programatically.

Using CSS to create layouts lets you rearrange items into new layout orders, like putting a sidebar next to the main content or displaying a list of images in a grid, but inside those placed elements things still follow the language's visual dimensions. If you do this in a way that does not contradict the dom order and the language's dimensions, everything continues to work as expected. If I have a list of linked images using an implicit grid keeps the reading and tab orders top-to-bottom, left-to-right. The visual, reading, and tab order all remain natural and in accord with the language order. But if I use flexbox to show them in reverse, the reading and tab order become the opposite of the visual order.

If there were a way to control the reading order independent of the dom order, there would be more latitude to arrange things visually, which would be handy for fitting everything into differently sized viewports. As long as the tab order remains bound to the reading order and the changes to the reading order reflect the visual order of the layout everything works out.

Since the reading order is linear and the layout is 2d this would be some kind of projection declaring stuff like "the header goes first, then the main content, then the sidebar, then the footer" irrespective of their dom order and within those items reading and tab order follow as normal, excepting additional overrides.

I'm not sure how that would or should be specified in CSS, but it seems like it could be very similar to (but simpler than) flexbox: define a "reading container" and set the relative or absolute "reading order" of its items. That would only allow you to permute adjacent elements, but that seems sufficient and more complicated cases would get quite complicated. It's possible that there are a lot of things I'm not taking into account, though. One thing this still wouldn't let you deal with is dense grid layouts since you don't know where things end up. It would be sad not to handle that. And I'm not sure how something like that would interact with spatial nav, if it even should or has to.

-- 
GitHub Notification of comment by jimmyfrasche
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3377#issuecomment-493248224 using your GitHub account

Received on Thursday, 16 May 2019 22:06:19 UTC