- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 26 Aug 2020 17:00:33 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-cascade] Custom Cascade Layers (formerly "custom origins")`, and agreed to the following: * `RESOLVED: move this proposal into the spec` <details><summary>The full IRC log of that discussion</summary> <dael> Topic: [css-cascade] Custom Cascade Layers (formerly "custom origins")<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/4470<br> <dael> miriam: Take everyone through the proposal?<br> <dael> astearns: Yeah. Summary would be helpful<br> <fantasai> Proposal: https://gist.github.com/mirisuzanne/4224caca74a0d4be33a2b565df34b9e7<br> <dael> miriam: Starting at the top, first question is where in cascade would author custom origin layer fit. Felt it could achieve all goals as higher then specificity. Putting it above shadow dom creates additional problems so putting it between solves problems<br> <astearns> zakim, open queue<br> <Zakim> ok, astearns, the speaker queue is open<br> <dael> miriam: Question about shadow dom at bottom of doc<br> <dael> miriam: Interacting with !important we suggest layers exist entirely within defined origin. They work like orgins so reverse in !important layers.<br> <dael> miriam: normal layers styles not explicit are at the top followed by named layers in order set up<br> <dael> miriam: Reversed in importat so unlayers are at bottom.<br> <dael> miriam: Keeps meaning and intent of !important more clear and working similar but internally<br> <dael> miriam: Talked about style attribute and suggestion is it continues to be above these layers. Have to redefine but I think has to anyway with scope being removed. Keeps style attribute like other styles.<br> <dael> miriam: Levels for managing layers; does it happen at selector or declaration or block or importing. Suggesting block similar to MQ and as with existing @rules blocks can nest. Then layering based on order of first appearance in code<br> <dael> miriam: Example reset-base components reset. reset lowest, base on top of that. Order they're first discovered is order of layering<br> <dael> miriam: In terms of ordering layers there's a way to cheat and declare them all. Could be with empty blocks but also proposing layers shorthand to let you define. That's above imports<br> <dael> miriam: Suggesting an import syntax. Way to name and group everything inside a file. Helps with encapsulation. Bootstrap exposes layers but we can create a wrapping alyer that keeps all boostrap inside. Nesting doesn't impact order, just naming<br> <dael> miriam: Various discussion on syntax and if it builds on @import or unique<br> <dael> miriam: Nesting doesn't change order, jsut groups. If wrapping layer has name can interact with nested layers by calling that with some syntax for getting to layers within layers.<br> <dael> miriam: By allowing unnamed layers allow a tool like bootstrap to have private layers. Wrap in unnamed layer and removes ability to call them later.<br> <dael> miriam: More detail in the proposal<br> <dael> miriam: Migration path since this is between specificity and style this can be mimiced with specifiity so clearest way to show is list of IDs.<br> <dael> miriam: Can be more clean using IS to get specificity of IDs. Path to polyfill<br> <dael> miriam: Weakness on refactor use case. Since layers reverse in !import not idea but doesn't seem changes are extensive. Have to do something with !import styles in legacy to make sure they don't override in new. Not a perfect solution but works with a little manipulation<br> <dael> miriam: Questions from thread, does load order of stylesheet matter so if a sheet is lazyload but lazyload first does it matter? no.<br> <dael> miriam: Can you nest layer blocks, yes. Specificity is unchanged inside layers. Just subsuming it.<br> <dael> miriam: If stylesheet is in multi layers it's in multi which is true currently<br> <dael> miriam: Best syntax is open question still. Are unnamed layers feature or a problem? Allow hiding which is risky but powerful.<br> <dael> miriam: Way to revert layers? Do we want that?<br> <emilio> q+<br> <dael> miriam: How does light dom layers affect shadow dom layers with same name. Complex but think a wrapper may be able to resolve that powerfully<br> <astearns> ack emilio<br> <dael> emilio: regarding shadow dom; how does it matter? rules in different trees are sorted diff on top of specificity. I don't know how that is a problem.<br> <dael> miriam: Comes into play b/c ordering of names determining the layering order<br> <dael> miriam: If there are layers inside shadow dom named main and base and layers outside named base and main which order are they used?<br> <fantasai> +1 to scoping layers to a shadow context<br> <miriam> +1<br> <dael> emilio: I see. I think layers should scope to a tree. Inside a tree is where you sort by specificity. Doens't make sense to me to have names interact between trees. I think that's wha tyou prop with anon.<br> <dael> miriam: Could be interesting to let you access layers inside a shadow dom.<br> <dael> emilio: Why would you want? But does seem different discussion<br> <dael> astearns: My prop is get this proposal into the spec and start opening issues to dig through<br> <dael> astearns: Objections to move this proposal into the spec?<br> <dael> RESOLVED: move this proposal into the spec<br> <dael> astearns: Doesn't mean we're done, means we open separate issues to discuss each bit instead of whole. Thanks so much miriam for putting this together.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4470#issuecomment-681004710 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 26 August 2020 17:00:35 UTC