Re: [csswg-drafts] [css-cascade-5] Allow authors to explicitly place unlayered styles in the cascade layer order (#6323)

Should we maybe reopen this issue? Or should we open a new one?

From what I understand, the initial issue was the one preventing the browsers from shipping this as a feature. Now that the layers have shipped, it is obvious that a bunch of use cases are not covered by them.

Both the [Candidate Recommendation](https://www.w3.org/TR/css-cascade-5/#issue-e29f5f96) and [the latest Editor's Draft](https://drafts.csswg.org/css-cascade-5/#issue-e29f5f96) list this as an issue, highlighted in red and linked there. But the issue itself is closed.

The initial WG resolution is this:

> RESOLVED: Reject this proposal; unlayered styles have a specified location in the layer stack which can't (currently) be controlled

Note the “(currently)”. I would interpret this as “ok for the first implementation, which we could return later to”. And this was actually the way I did interpret this in the past, and usually looking in the specs, seeing the still-present issue mentioned, I thought that this was a still-open issue.

[I did bring this issue up recently on Mastodon](https://front-end.social/@kizu/111291721848435193), where it got some support.

The main use cases that interest me personally are style overrides for any sites or apps from outside:

- User styles (extensions and Safari's ability to add a custom stylesheet) are often used by people to customize websites to their liking, often as a way for users to make sites accessible for them.

    Two recent places where I saw custom style overrides mentioned in context of accessibility are [this issue](https://github.com/w3c/csswg-drafts/issues/9510) and [this Mastodon reply](https://mastodon.social/@simevidas/111339944808288995) by @simevidas (and the whole [original thread](https://kolektiva.social/@delan/111335493108706114) by @delan).
    
    Right now, anyone writing such overrides has to either fight with specificity, or push the `!important` everywhere (or both, where the original pages contain heavy selectors with important declarations inside).

- Custom CSS for various apps like Mastodon (usually available as a field for the instance admins) or Obsidian (ability to add just any CSS).
  
    Apps like these do not come with all their styles neatly wrapped in layers, and for a long time, due to backwards compatibility issues, they won't. And many legacy similar apps never would (think of something like LiveJournal style overrides).
    
    In all these cases, this case is similar to the first one: they need to either bump the specificity or use `!important`.

One of the best things of CSS, its first letter — the Cascade — always had this intent of treating the _users_ as those who should be able to write CSS as a way to customize websites. Not allowing the users to have a simple way to override things goes against this intent. While it can be argued that maybe browsers themselves should provide convenient ways of writing user origin styles, in reality they don't. Layers seem like the perfect place to unlock the overridability of the web, and make it more accessible for everyone.

I acknowledge that it is not as easy to decide how exactly the ability to add layers that go above unlayered styles should be defined, but I strongly think that we require this ability.

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


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

Received on Tuesday, 7 November 2023 20:34:29 UTC