Re: [csswg-drafts] [css-ui] `interactivity: focusable` (#13040)

@jyasskin 
> I noticed that this issue _starts_ with a proposed solution, in the title, and only later steps back to some use cases. This is an anti-pattern in designing features. As described in the [Explainer Explainer](https://www.w3.org/TR/explainer-explainer/#introduction), and in [Mozilla's elaboration](https://github.com/mozilla/explainers?tab=readme-ov-file&rgh-link-date=2025-11-04T19%3A21%3A22.000Z#minimum-viable-explainer), it's best to lay out the problems that need to be solved before jumping straight to a proposal.

Come on Jeffrey, do you really think you need to explain to me that features need to be motivated by use cases? My understanding was that the use cases are well established and known to all of us here. If that’s not the case, sure, I can put together a list, but it will take some time.

@bkardell I thought the opposition had been resolved at this point. I will dig through, but it will be interesting to investigate if the pushback is around `inert` specifically, or the broader concept of controlling such functionality in CSS. I can imagine a lot more problematic scenarios around `interactivity: inert` than `interactivity: focusable`, so opposition towards the former doesn't necessarily translate to opposition towards the latter. Though if `interactivity: inert` is not happening, it means we don't have to use that property name, which could produce better designs (e.g. one could conceive a property that forces authors to specify an ARIA role as well, eliminating one of my main concerns around this).

@lukewarlow 
> To help with this discussion and per the above comment hopefully steer the discussion in a different direction it would be good to get some actual concrete use cases to measure against.
> 
> More than just "want to make something focusable". For example, if there's a strong desire to control this without JS and based on something dynamic such as screen siz, I suspect something rooted in HTML and then e.g. cascading attribute sheets is actually a far better direction for the platform.

In general, the need for declarative aggregation keeps coming up over and over across a variety of web platform features. Cascading Attribute Sheets *could* be great in theory, but the current proposal is so severely restricted wrt invalidation (and reactivity is kind of the entire point — declarativeness one can get via userland solutions too) that it manages to both add immense complexity to the platform while simultaneously _not_ addressing use cases well. Adding CSS properties for the most pressing pain points may be less philosophically pure, but is the path of least resistance. And even architecturally, it's unclear whether the complexity of CAS is warranted for a largely arbitrary split of element traits (even without `interactivity`, there is already significant enough overlap that it's hard to explain the split in a coherent way).

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


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

Received on Tuesday, 4 November 2025 19:57:12 UTC