- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Mon, 27 Jul 2020 23:55:50 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-cascade] What are the proper "levels" for managing Cascade Layers?`. <details><summary>The full IRC log of that discussion</summary> <dael> Topic: [css-cascade] What are the proper "levels" for managing Cascade Layers?<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/4969<br> <dael> chrishtr: I can summarize the latest update<br> <TabAtkins> q+<br> <dael> chrishtr: Discussed at previous F2F. I prop we start with simplest set of layers; 2. Base between UA and regular stylesheets and then regular stylesheets. Allows simple use case where you import a widget. You can define what's important to the widget and would break without and than use those customizable.<br> <dael> chrishtr: 3rd part dev marks what's important and can't be overwritten. Then with normal cascade if they want to override not required they put in their own rule to change.<br> <dael> Rossen_: Allow library or component authors to provide sensible defaults and allow consumers...<br> <dael> chrishtr: To customize properties that are appropriate to customize<br> <Rossen_> q?<br> <dael> chrishtr: We tried to make this polyfillable so that existing websites like nextJS could with small dev effort translate existing layers into an ordering of stylesheets on the page and the specificities that are eq.<br> <dael> chrishtr: Then sites could use right away in build steps until browsers finish impl<br> <dael> Rossen_: How does multiplicity here have anything additional against this? More than 2 layers?<br> <dael> chrishtr: How would that make it harder?<br> <dael> Rossen_: Yeah<br> <miriam> q+<br> <dael> chrishtr: Maybe there isn't a good reason other than 2 is smallest number. Kind of a joke, kind of not. Good principle to find smallest solution. Also use cases I've talked to devs about seem completely solved. You have component and site and I"m not sure you have 3 people<br> <dael> Rossen_: Reasonable. minimum and sufficient. We have lots of talk about how more layers can be used, but I buy this.<br> <Rossen_> ack TabAtkins<br> <dael> TabAtkins: Me chrishtr and miriam discussed and drilled pretyt heavy to predefined layers. It's important aspect. At the time we thought we needed 3, but number isn't important. Important is one of the big issues about how to make it make sense if if you you have arbitrary names and ordering you can define those reasonable<br> <dael> TabAtkins: But as soon as you add otehr libraries with custom layers if you're scoping and interoperate so theither normals go with yoru normals custom names become very difficult. If you have 1 library you can change but with 2 libraries there are too many names.<br> <dael> TabAtkins: It gets very complex<br> <dael> TabAtkins: Whereas if we start with a small number of predefined and named layers it lets us solve those issues w'o extra problems. You know what default layer is for and you can import. Everyone using default will use in roughly same way<br> <dael> TabAtkins: As long as people abide by what the layers mean you'll be able to integrate with 3rd party and they just work.<br> <dael> TabAtkins: I think that's important aspect that needs to be considered and we should go with for v1 of custom cascade. Having a small number defined hadnles a lot<br> <Rossen_> q?<br> <dael> chrishtr: Collapsing layers to 1 at run time is not trivial, miriam brought up. If you don't have polyfill offline it's not easy<br> <dael> miriam: I'm interested in finding the simpliest poss starting place. Agree a few named defined layers is good to start.<br> <Rossen_> ack miriam<br> <dael> miriam: A few concerns with this proposal where it's so focused on polyfill I'm not sure how it's helping. Offhand it supports use cases but doesn't do a lot toward them. Are we solving the problem or focused on polyfill. I don't know that's not sollving the problem<br> <dael> miriam: One feels to me like it could be a good place to start. The examples rely heavily on !important and where so I'm not sure I see how polyfill is simplier without extra steps<br> <dbaron> I thought TabAtkins said something above about an import mechanism that collapsed layers, but I didn't see it minuted, and I missed some of the detail of what he said.<br> <TabAtkins> dbaron, being able to say "import this library's styles, but just treat all of them as living in layer X of my page (while respecting their own internal layer usage)"<br> <dael> miriam: I also think there's a trade off when we go to predefined layers. It's that we don't get any modularization control which was another potential feature. Ability for final author to modularize by collaposing layers together and say I don't trust bootstrap to get this but can subsume it. It maybe can be handled sep but it's a trade off for same layers<br> <Rossen_> q?<br> <dael> fantasai: +1 to miriam<br> <Rossen_> ack fantasai<br> <dael> fantasai: I understand desire to make this polyfillable but I think we have not explored what it would look like concretely and take what miriam prop in Jan and make that real.<br> <dael> fantasai: What she prop is a really powerful system that adds abilities to cascade and authors would find powerful. Simplify to 2 layers is not that compelling. To try and design that would prevent us from trying to understand full picture<br> <dael> fantasai: At this stage I'd rather explore full context miriam proposed. Then if there is a subset we want to ship first that's fine. But taking on this restrictive set I don't think gives us something to build off of to get where we want to go<br> <dael> fantasai: Would rather explore original prop from miriam, get that concrete enough to know what it looks like and have specific issues. Shouldn't restrict to polyfillable since the whole point is platform isn't capable of what we want.<br> <dael> chrishtr: Which use cases not satisfied<br> <dael> fantasai: Prop is flatten out but when working with multiple systems you'll have all the problems with cascade. Point of this was encapsulate so you don't have specificity of selectors cross interacting. You lose that. If you're losing where for everything you can't control specificity of selectors. Won't have real effect of cascade layer by flattening all selectors<br> <dael> miriam: Answering it differently it doesn't break any of them but it doesn't go the full way in aiding complexity.<br> <emilio> q+<br> <dael> miriam: Something like this scaled back may be useful but I want to see in context of how it would expand. I want to see the whole system and than what a scaled back impl would look like. WHat's the potential to grow and how are we designing first impl so growth is in mind<br> <dael> chrishtr: Where is only to support polyfills.<br> <Rossen_> q?<br> <dael> TabAtkins: Using where as polyfill you can do arbitrary layers. THe details of that is not important<br> <dael> chrishtr: You can have a build tool that sticks thigns in where clause. Laying out what I thought of<br> <dael> emilio: Most use cases I read about are things conflicting inside same cascade origin. Rather than inventing new ones, sorting order in cascade is specificity and then source. WOuld it make sense to add a 3rd so it's user defined, then specificity, thank source.<br> <dael> emilio: Multi cascade explodes when you have shadow dom. With this you don't have the problem and solve use cases.<br> <dael> chrishtr: Would that take care of non-overridable library rules?<br> <dael> emilio: Potentially. You can define this number is sort of like cascade origins<br> <dael> miriam: I think difference is only if layers exist above or below shadow dom in cascade which is still open<br> <dael> emilio: Yeah. And I think this is more efficient to impl<br> <dael> TabAtkins: I think for spec complexity we'd have to impl this as new specificity.<br> <miriam> +1<br> <dael> emilio: Okay, that makes me less scared about perf implications<br> <Rossen_> q?<br> <emilio> ack emilio<br> <Rossen_> ack emilio<br> <Rossen_> ack dbaron<br> <dael> dbaron: I was trying to think about something TabAtkins said about an import mech that imports something with stuff from both layers and than collapses<br> <dael> dbaron: 2 ways to do that and not sure which talking about. One is pretend the layer never existed. Other is sort them in there as though layers and then collapse to one layer<br> <dael> dbaron: I guess that doesn't work. Now that I said it out loud.<br> <dael> TabAtkins: My intention was there is a strong case to not interleave but still let the library use layers for code org. Sort the rules specificity wise and then collapse to one layer to interact with yoru pages<br> <dael> dbaron: Not sure how that works if you interleave with non-collapsed rules<br> <dael> TabAtkins: I'm thinking it just lives on a layer. Ther ineroperate with other rules in that layer<br> <dael> dbaron: So it breaks some author assumptions who put in 2 layers about wat overrides what?<br> <dael> TabAtkins: Shouldn't. Their layers respected in their own thing.<br> <dael> dbaron: That's what I was starting to think but convinced myself it made more sense<br> <Rossen_> q?<br> <dael> TabAtkins: Definitely need more thought time on this topic.<br> <dbaron> s/more sense/no sense/<br> <dael> Rossen_: Going back to direction...2-layer approach vs continue to explore full set of options from jen and miriam. WHere are we swaying?<br> <dael> Rossen_: One thing I didn't grasp is would hte 2 layer prevent us from expanding later down the path to get full set of layers?<br> <dael> TabAtkins: I don't think it does. Particularly when we do it with a naming structure and we can distinguish between these defaults.<br> <dael> Rossen_: Same mental model as css properties then variables then custom properties? So we have properties now we're adding variables and we'll then expand<br> <dael> TabAtkins: yes<br> <Rossen_> ack fantasai<br> <dael> fantasai: I'm not convinced this requires naming. I would like to see us try and draft something more concrete.<br> <dael> fantasai: If we have multi prop that's interesting, but I haven't seen one that represents what we discussed in Jan and until we have one I don't think locking down is a good idea<br> <dael> TabAtkins: fantasai and I intend to put out a draft spec and will have miriam in that<br> <dael> fantasai: florian has also drafted ideas so we can talk together and see if we align or we come up with multiple proposals<br> <dbaron> I'm definitely interested in seeing more alternatives.<br> <dael> Rossen_: Last time we discussed we agreed to have a smaller taskforce. Is that forming?<br> <dael> many: yes<br> <dael> Rossen_: fantasai are you willing to take this on and get it organized?<br> <dael> chrishtr: miriam would you prefer to do it or have fantasai do it?<br> <dael> miriam: Fine if you take that<br> <dael> fantasai: miriam time zone?<br> <dael> miriam: Mountain<br> <dael> astearns: So I think we're done with this issue<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4969#issuecomment-664697335 using your GitHub account
Received on Monday, 27 July 2020 23:55:52 UTC