- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 22 Jan 2020 17:38:29 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Custom Origins`. <details><summary>The full IRC log of that discussion</summary> <fantasai> Topic: Custom Origins<br> <jensimmons> https://noti.st/jensimmons/QOEOYT/three-topics#srFUYHC<br> <astearns> github: https://github.com/w3c/csswg-drafts/issues/4470<br> <TabAtkins> jensimmons: Possibility of custom cascade origins, controlled by authors.<br> <TabAtkins> jensimmons: Part of a larger convo, which could be called "modernize the cascade"<br> <TabAtkins> jensimmons: Why modernize? Some folks argue that specificity was designed for a simpler time, when one or a small number of people wrote the CSS for a site. Today CSS is maintained over years by large teams, and the cascade gets really hard.<br> <TabAtkins> jensimmons: If a dev gets a ticket, they can't really rearchitect the whole page's cascade to fix that one thing.<br> <TabAtkins> jensimmons: Lots of ways people attack this.<br> <TabAtkins> jensimmons: (1) just do it right the first time<br> <TabAtkins> jensimmons: (2) OOCSS, SMACSS, BEM, etc<br> <TabAtkins> jensimmons: (3) Only ever use one class, to give identical specificity and remove the cascade.<br> <TabAtkins> jensimmons: (4) overuse !important<br> <TabAtkins> jensimmons: (5) CSS-in-JS, ignoring cascade again<br> <TabAtkins> jensimmons: Problem there is no way to control order CSS is loaded. No wonder the cascade is confusing!<br> <TabAtkins> jensimmons: (6) just inline-style everything, screw selectors<br> <TabAtkins> jensimmons: Why not use specificiy as designed?<br> <TabAtkins> jensimmons: IDs increase specificity, but can only use it once per page<br> <TabAtkins> jensimmons: Not great for components.<br> <TabAtkins> jensimmons: Element selectors work well for simple defaults, but too dependent on doc structure, and hard to use otherwise.<br> <TabAtkins> jensimmons: So leaves a lot of these teams only using classes, attributes, and !important<br> <TabAtkins> jensimmons: [shows example]<br> <TabAtkins> jensimmons: [Tailwind CSS]<br> <TabAtkins> jensimmons: [everything's inline, with no cascade]<br> <TabAtkins> jensimmons: A lot of possible ideas here too, web components, scoping, etc.<br> <TabAtkins> jensimmons: A project I did last year is how to protect CSS from this hate.<br> <TabAtkins> jensimmons: So we put together a hard-core course on teaching the cascade.<br> <TabAtkins> jensimmons: Miri Suzanne did a deep dive into the history/etc.<br> <TabAtkins> jensimmons: She began thinking about how we could change CSS to modernize the cascade and work better.<br> <TabAtkins> jensimmons: One of her ideas is to extend selectors, in #4690.<br> <astearns> https://github.com/w3c/csswg-drafts/issues/4690<br> <TabAtkins> jensimmons: Another idea is to allow authors to make custom cascade origins.<br> <TabAtkins> jensimmons: I didn't really know what a cascade origin was until Miri taught me.<br> <TabAtkins> jensimmons: [describes the cascade origins]<br> <fantasai> See https://www.w3.org/TR/css-cascade-4/#cascade-origin<br> <TabAtkins> jensimmons: Proposal is for custom origins. Say, create 3 named origins (get !important variants automatically that work as expected), and put styles in the chosen origin to get auto-overriding.<br> <TabAtkins> jensimmons: So use case.<br> <TabAtkins> jensimmons: Reset styles in one origin, design system in another, then one-off overrides into a third.<br> <TabAtkins> jensimmons: Or split apart the design system: reset -> defaults -> patterns > layouts -> components, all distinct origins.<br> <emilio> q+<br> <TabAtkins> jensimmons: Or CMS Core -> CMS Extensions -> Base theme -> site styles<br> <TabAtkins> jensimmons: Or a team trying to rewrite their CSS. Can't fix it all at once, but could put all their old code in one origin, and put their new code in a higher origin, to piecemeal fix it as they go.<br> <TabAtkins> jensimmons: Or Bootstrap -> 3rd party -> ad networks -> actual site styles<br> <TabAtkins> jensimmons: Adventages?<br> <TabAtkins> jensimmons: Coudl help with specificity wars between frameworks and author styles.<br> <TabAtkins> jensimmons: Could put !important back into its proper role, rather than being abused just to get a second origin.<br> <TabAtkins> jensimmons: Or just using origins as a type of !important; might be just as annoying?<br> <TabAtkins> jensimmons: Pulled some use-cases from Twitter (already mentioned)<br> <TabAtkins> jensimmons: So what do you think? Want to pursue?<br> <hober> q?<br> <florian> q+<br> <fremy> q+<br> <astearns> ack emilio<br> <fremy> q-<br> <TabAtkins> emilio: I'm a bit confused abuot !important.<br> <TabAtkins> emilio: If you want ad networks on an origin, and your styles on a higher origin, the ad networks could still override everything with !important style. Maybe that's not what you want?<br> <bkardell_> q+<br> <TabAtkins> emilio: Second, it may be invalid, but IDs *can* be repeated on the page...<br> <TabAtkins> emilio: There are ways for authors to use cascading origins that have better behavior - web components.<br> <fantasai> fantasai: They're really hard to use<br> <fantasai> TabAtkins: And also won't handle these use cases<br> <TabAtkins> TabAtkins: WC doesn't solve any 0f Jen's use-cases, tho.<br> <TabAtkins> emilio: When we discussed custom element default styles behavior, Apple was strongly against. Unsure if the'd still have complaints.<br> <fantasai> i/emilio/iank_: We should add declarative shadow roots<br> <TabAtkins> hober: I'l talk to Ryosuke/Antii, see if they have feelings on this.<br> <emilio> Though ++ to declarative shadow roots<br> <astearns> ack florian<br> <TabAtkins> florian: I think it's a brilliant idea.<br> <TabAtkins> florian: We've had the luxury of multiple origins here in CSS, letting us design thru problems. Authors haven't had that.<br> <TabAtkins> florian: I think it would be great. Almost want to stop talking about whether or not to do it and jus tstart talking syntax.<br> <TabAtkins> florian: Even as a singl eauthoe this seems useful.<br> <TabAtkins> q+<br> <astearns> ack fantasai<br> <TabAtkins> fantasai: I always want to say I love it.<br> <astearns> ack dbaron<br> <TabAtkins> dbaron: I'm also a big fan.<br> <TabAtkins> dbaron: There are multiple choices we coudl make about !important.<br> <TabAtkins> dbaron: Don't have to say they go in the opposite order. They could go in the same order, or be configurable, etc.<br> <fantasai> +1<br> <TabAtkins> dbaron: Maybe have the !important right after the normal origin.<br> <fantasai> essentially an origin can encapsulate its !important level<br> <TabAtkins> dbaron: So lots of options we could choose between, or let authors configure.<br> <AmeliaBR> +1 to dbaron says. Definitely don't want !important to automatically do reverse order.<br> <TabAtkins> fantasai: Along those lines, might have an origin with sub-origins.<br> <heycam> q+<br> <TabAtkins> fantasai: Which might have its !important held within the larger origin<br> <astearns> ack bkardell_<br> <TabAtkins> bkardell_: First, thanks for bringing it up.<br> <astearns> q+<br> <TabAtkins> bkardell_: I've had these same conversations and I think this is really healthy.<br> <fantasai> Examples (from slide 25):<br> <fantasai> Reset < Design System < Overrides<br> <fantasai> Reset < Defaults < Patterns < Layouts < Components<br> <fantasai> CMS Core < CMS Extend < Base Theme < Site Styles<br> <fantasai> Old Styles < New Styles<br> <astearns> q-<br> <fantasai> Bootstrap < 3rd-party libs < Ad network < Site Styles<br> <TabAtkins> bkardell_: To discuss what people are actually doing, rather than just relying on education<br> <TabAtkins> bkardell_: I think CSS-in-JS does have an order...<br> <TabAtkins> jensimmons: They can, but don't always<br> <TabAtkins> bkardell_: wrt WC, they don't solve all problems, but they do solve some. They're already .2% of the web archive, despite only getting the last impl this week.<br> <TabAtkins> bkardell_: Do we really rely on origin for UA level? I thought we kept them low speicficity.<br> <TabAtkins> TabAtkins: We don't use IDs, no, but we do freey use attribute selectors, which can easily clash if it wasn't for the origin difference.<br> <jensimmons> slides (again): https://noti.st/jensimmons/QOEOYT/three-topics#srFUYHC<br> <fantasai> yes, we really rely on origin for UA level<br> <TabAtkins> bkardell_: I do believe we'r emissing something here. I don't know if this addresses or exacerbates the problem. At some level it addresses their complaints, but by doubling down on what they're complaining about.<br> <TabAtkins> jensimmons: Agree.<br> <astearns> ack TabAtkins<br> <fantasai> Scribnick: fantasai<br> <fantasai> TabAtkins: I totally like this idea<br> <fantasai> TabAtkins: had similar thoughts, but never did the use case exploration<br> <fantasai> TabAtkins: Definitely agree we should pursue this, and the use cases made me absolutely sure we should pursue this<br> <TabAtkins> ScribeNick: TabAtkins<br> <astearns> ack heycam<br> <TabAtkins> heycam: I think it's very important fo rus to try to address these problems.<br> <TabAtkins> heycam: A little of a shame that it's taken several years after people started complaining, biut glad we're addressing it now.<br> <TabAtkins> heycam: What I like about this is that it's so simple, and slots into the existing model.<br> <astearns> q+<br> <TabAtkins> heycam: Not super sure about whether it really will capture all of these use-cases, or might need more discussion with real proponents of CSS-in-JS to see how well it works.<br> <emilio> q+<br> <TabAtkins> heycam: I'd want to be more sure this is the right way to go for solving that.<br> <TabAtkins> heycam: But see th eother use-cases anyway.<br> <TabAtkins> astearns: I agree this is very nice it slots into our model, but a little concerned it's not the general author model.<br> <TabAtkins> astearns: You had to learn about the concept anyway.<br> <TabAtkins> astearns: So as Tess said, "origin" is an overloaded term, maybe we can come up with something else?<br> <TabAtkins> [various suggestions]<br> <astearns> ack astearns<br> <astearns> ack fantasai<br> <dbaron> "style sources"?<br> <TabAtkins> fantasai: Some discussion about this addressing all the cases; I don't think it does, biut it addresses quite a few, and addresses the organizational layer of many projects.<br> <TabAtkins> fantasai: So I think it fits well with how people put together their sites.<br> <TabAtkins> fantasai: There's other places in the cascade where specificity gets unwieldy. I don't think WC is great here; it adds a *ton* of encapsulation.<br> <TabAtkins> fantasai: Another proposal was scoped styles in CSS, which might also help.<br> <jensimmons> q?<br> <bkardell_> if we had this, would we need leaverou 's zero specificity pseudo still too?<br> <TabAtkins> fantasai: They let you say "within this sidebar, these styles win over other things".<br> <fantasai> s/things/things, regardless of specificity/<br> <TabAtkins> TabAtkins: I think declarative shadow dom addresses a lot of the problems with WC; I'd like to explore that more seriously first before we add something that is 98% identical to WC's model, but with 2% weird differences that make impl complicated.<br> <astearns> ack emilio<br> <fantasai> bkardell, you wouldn't need it for an entirely swath of styles, but would likely still be useful locally, for specific selectors or parts of selectors<br> <AmeliaBR> q+<br> <TabAtkins> emilio: I agree this is neat. Is there a concrete proposal? Is that at the stylesheet level, or allow 3rd party styles to choose their origin, etc?<br> <TabAtkins> emilio: Depending on details it might solve some use-cases but not vice-versa.<br> <TabAtkins> emilio: Also need to figure out how this interacts with shadow dom.<br> <leaverou> bkardell_: I believe so. This is great, but sometimes you need more fine-grained control. E.g. when theming *within* the same origin<br> <TabAtkins> emilio: Shadow DOM introduces a stack of origins; introducing this naively makes it a matrix, which is harder.<br> <jensimmons> q?<br> <astearns> ack AmeliaBR<br> <TabAtkins> AmeliaBR: echo Emilio's concern that we need details to see exactly how this sort of thing works.<br> <TabAtkins> AmeliaBR: Coming up with specific proposals and cross-reffing them with specific use-cases would be helpful.<br> <TabAtkins> AmeliaBR: So we should work from the use-cases to what features we actually need.<br> <astearns> ack fantasai<br> <TabAtkins> fantasai: For "how do you control", an easy way to think of it would be the person importing the sytlesheet bea ble to say what level it imports at.<br> <TabAtkins> fantasai: And within each level, maybe you can have sub-ordering.<br> <florian> q+<br> <TabAtkins> fantasai: And with a nesting block that lets you specify the layer within a single file.<br> <TabAtkins> fantasai: Using numbers to establish the ordering might work if there's only one controller; multiple controllers gives you the z-index wars.<br> <faceless2> q+<br> <TabAtkins> emilio: My concern with nubmers or letting stylesheets choose their own levels becomes a z-index fight.<br> <astearns> ack florian<br> <TabAtkins> florian: One thing I'm a little concerned is how we figure out the syntax to have a migration path toward this from legacy CSS.s<br> <TabAtkins> florian: In particular, a syntax ignorable by old browsers is bad because the cascade will be all mushed up; but making it hide rules from old browsers means they'll just miss a lot of code.<br> <TabAtkins> florian: Writing everything twice is bad, but not having an upgrade path is bad.<br> <astearns> ack faceless2<br> <astearns> ack faceless<br> <TabAtkins> faceless2: What if you had two toolkits, importing the same stylesheet at different levels?<br> <astearns> zakim, close queue<br> <Zakim> ok, astearns, the speaker queue is closed<br> <fantasai> TabAtkins: Same as importing a style sheet twice, it's just present in both places<br> <fantasai> TabAtkins: cascades together; effectively later one wins<br> <TabAtkins> jensimmons: So got a lot of good issues and concerns.<br> <bkardell_> +1 to talk about "this set of problems" for sure<br> <TabAtkins> jensimmons: I do think it's worth looking deeply at the solutions we might need for the complete set of problems, not just what this particular solution could address, so we can tell if this is a good idea in the totality of a complete solution.<br> <TabAtkins> jensimmons: I've even convinced myself that if we ship this today by itself, it could get abused pretty badly.<br> <TabAtkins> jensimmons: (similar to people abusing Flexbox to do grids)<br> <TabAtkins> jensimmons: Putting this on Twitter, I got a lot of trepidation from folks. Powerful tool, could be bad.<br> <TabAtkins> jensimmons: But I got that people who really knew CSS the most thought this was a terrific idea.<br> <TabAtkins> jensimmons: I think it does require some teaching, but it's not that complicated.<br> <TabAtkins> jensimmons: So I'm hearing a tentative "yeah, this is good", but I think there is a bigger metaproject to modernize the cascade.<br> <TabAtkins> jensimmons: Also, Miri has been very active in Sass to push CSS to be a featureful language; did crazy things with Sass variables back in the day.<br> <TabAtkins> jensimmons: So I'd like to invite her as an IE.<br> <TabAtkins> [intentionally not minuting]<br> <TabAtkins> fantasai: Where to put it?<br> <TabAtkins> TabAtkins: Suggest putting it in WICG until it gels, then merge it into Cascade 5.<br> <fantasai> i/fantasai/astearns: So sounds like interest in the room, try to move proposal forward/<br> <TabAtkins> jensimmons: And I want to get some highly-skilled authors involved in the convo too, so hopefully WICG works there.<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-577300816 using your GitHub account
Received on Wednesday, 22 January 2020 17:38:31 UTC