Re: [csswg-drafts] [css-cascade] Custom cascade origins (#4470)

came here via one of Jen's Tweet. https://twitter.com/jensimmons/status/1219351448028356609
>     * IDs are explicitly one-off, so we can't re-use anything in the component layer
well, actually CSS doesn't bother. You can have multiple elements with the same ID and they'd be styled according to the current rules.
It's JS that'd likely choke or sth. like a XSLT processor.

Maybe I got lost in translation reading this proposal (and what happend around Jen's tweet) and I'm going to state the obvious; but here are my 2ct.

FWIW both Cascade and Specificity are and always have been perfectly fine the way they are: the closer to the element (origin/location/cascase) considering the selector specificity. Done. 
What's not to grasp? :)
It's kinda like with using Layers and Masks in Photoshop: some ppl just can't get their head around it :)
If you one doesn't understand pointers in C++ or references iin Java[Script] s/he equally screwed.

However, the culprits IMHO happen to be "modern" design patterns and philosophies like BEM or Atomic Design & such that are causing the issues ppl. apparently have with "specificity": you either have a rather flat hierachiy where everything has virtually the same specificity (i.e. BEM) (and origin/order matters) or the HTML is poluted with a gazillion cryptic utility classes and what-not that might end up raising the specificity over the roof. And then there are some Framework / Library creators that don't get it either and butcher our beautiful Cascade adding `!important` all over the place.

There's only one addition to the Level in the Origin line of things I'd imagine to be helpful in some situations and to some people. It'd be considerably 1. logical and 2. following the current rules of the Cascade but applied a different "weight" to stylesheets served from 3rd party domains (CDN et al) and one's own (sub-)domain. 
That's something crafty people can easily understand and hopefully handle responsibly.
That's also how CDN based CSS Frameworks would get a lower significance than author and user styles.
Currently only _source order_ matters, IIRC.

With such a distinction **equal selectors** and **equally specific selectors** in an author style (even if `@import`ed) served from the same domain/origin as the document could overrule one from a CDN'ed Framework w/o using !important.

Here's how things could work **bold** = _"new" origin level_ (out of my head from lower to higher priority)
- UserAgent
- **`link` with `@import` 3rd party domain (external origin)**
- **`link` 3rd party domain (external origin)**
- `link` with `@import` to author styles (same/local origin)
- `link` to author styles (same/local origin)
- document level `<style>@import`
- document level `<style>`
- element level (inline) `style` attribute / JS
- user styles
Order of appearance in each "level" applies as usual; that is the closer the more significant.
Somewhere in each level would be animation/transition and the daddy of all Evil `!important`.

Since this additional level of origin _would change the current browser behaviour_, authors should "opt-in" to enable the new origin level by adding a `<meta>` tag to the document or sending a response `Header`. 
That's similar to the well accepted `<meta viewport>` which also changes the way CSS works with dimensions, or how oldIE was told to toggle its `X-UA-Compatible` mode back in the days.

René

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

Received on Saturday, 25 January 2020 15:41:38 UTC