Re: [csswg-drafts] [css-cascade-5] Reconsider placement of unlayered styles, for better progressive enhancement? (#6284)

The primary deciding factor (for anyone who hasn't been part of the conversation from the start) was this:

- One of the primary use-cases is to give _site authors_ final control over where external-party tools fit into their cascade. That doesn't only include third-party libraries, but also design systems, etc. The author of the site should have final say.
- It's possible to import an external stylesheet _into a layer_ (name-spacing it, and placing it as desired). But it's not possible to import a stylesheet _and remove all the layers inside it_.
- If layers had priority by default, it would be _impossible to override any layers in third-party tools_ without layering everything essential on your site. That's a bad situation to put site authors in. 

Because it's possible to add and nest layers, but not possible to remove or un-nest layers, this is the only solution that gives site authors long-term control over the entire system. Does that mean it's perfect? No. But the alternative seemed (and still seems to me) worse. We made a tradeoff, as we often do.

We can't change that decision. But we can add to it. Documenting the pain-points that remain, and looking for ways to address them is what we're here for! I think the main one is to give authors some ability to place layers above the unlayered styles. We have an active thread for that. It's a complex problem, but I think we can get to something that works.

I think tool-makers (like WordPress) should also think of ways to let site authors put their tool-provided styles into layers. That doesn't have to be WP adopting layers for everyone, but providing a way that authors can opt-into layering WP styles would be great. (WP is just one example of many)

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


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

Received on Wednesday, 3 July 2024 21:56:11 UTC