Re: [csswg-drafts] [css-anchor-position-1][css-display-4] Anchor Positioning and Display Order (#9356)

As a counter-example, and a demonstration of how we can't reasoanbly infer these relationship, consider a big grid of data, and the sorting controls are a positioned element anchored to it, just outside the grid and flush against its top edge

```
.data-table {
  anchor-name: --data-table;
}
.sort-controls {
  position: fixed;
  position-anchor: --data-table;
  inset-area: top span-right; /* outside the grid, this bottom edge against the grid's top edge */
  justify-self: start; /* left edge aligned with the grid's left edge */
}
```

Here, you probably want the sort controls to show up in the tab order *before* the contents of the big data grid, by default.

Contrast that with this commentary case:

```
.item {
  anchor-name: --item;
}
.comment {
  position: fixed;
  position-anchor: --item;
  inset-area: top span-right;
  justify-self: start;
}
```

Here, you probably want it to read/tab the item's contents first, *then* go to the comment.

The styles in these cases are *exactly identical*, the difference is purely contextual, not expressed in the style system at all. The correct thing to do is annotate these elements appropriately: in the first case, probably just `aria-controls` on the positioned element, pointing to the data grid, and maybe `aria-owns` on the grid pointing to the controls; in the second case, `aria-details` on the item, pointing to the tooltip, and `role=comment` on the comment.

I simply don't think that either case can be reasonably inferred from the style system. I tried *really hard* to infer similar relationships from the style system when working on [CSS Toggle States](https://tabatkins.github.io/css-toggle/), but that also ended up being too complex and ambiguous to do anything useful. The final conclusion there was that we needed more targeted proposals that *did* naturally impose specific semantics - things like popover, `details` groups, and the in-early-development carousel-related properties.

-----------

Note that "as an option" is still on the table; what I'm pushing back against is "as a default". If we want to make tab ordering more controllable *from CSS*, with some explicitly-designed properties, I think that's a *great* idea. But it goes beyond Anchor Positioning and is instead a separate feature that could be used much more broadly.

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


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 3 May 2024 22:09:18 UTC