- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 08 Jun 2022 16:49:22 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-contain-3] Revisit decision to make style the default container-type`.
<details><summary>The full IRC log of that discussion</summary>
<fantasai> Topic: [css-contain-3] Revisit decision to make style the default container-type<br>
<fantasai> github: https://github.com/w3c/csswg-drafts/issues/7066<br>
<fantasai> miriam: We've discussed this a few times, but the resolution we took last time need some clarification either way<br>
<fantasai> miriam: We resolved last time we talk to make every element a style container by default<br>
<fantasai> miriam: On the one hand, in this thread, it seems we feel confident that's a good choice in terms of author expectations in terms of style queries<br>
<fantasai> miriam: really helps for inherited properties, if you can assume that you always get the value from the parent<br>
<fantasai> miriam: if we stick with that direction, need to clarify what it means for being default<br>
<fantasai> miriam: does that mean style is the default, but if set other type, would drop style type?<br>
<fantasai> miriam: more likely, would mean every container is a style container, always true of all elements don't have a value for it<br>
<fantasai> miriam: So if we want to stick with that resolution, need to clarify that this is how it works<br>
<fantasai> miriam: On the other hand, all three browser engines have commented that this would be a performance hit<br>
<fantasai> miriam: I'm not sure how we want to weigh those two things<br>
<fantasai> miriam: allowing people to set them individually let's people control performance<br>
<fantasai> miriam: but if set style globally to get the behavior we want, then would have to juggle carefully your values because then it would get overridden when you try to set up other types of containers<br>
<fantasai> miriam: so we have a potential perf issue vs author usability<br>
<futhark> q+<br>
<fantasai> Rossen_: Want to know if implementers would clarify the exact perf implications<br>
<Rossen_> ack futhark<br>
<fantasai> futhark: I'm not sure we can say it's a perf issue in general, but in certain cases can get into one<br>
<fantasai> futhark: if you look at example I gave, where you have a universal first-child rule that queries a custom property.. if you don't use container names<br>
<fantasai> futhark: you could query a custom property that only makes sense for certain parents in the document<br>
<fantasai> futhark: but in order to figure out that this custom property can cause invalidation of children, would have a lot of overhead<br>
<fantasai> emilio: Would make style queries evaluate against all elements by default, which is not amazingn<br>
<Rossen_> ack fantasai<br>
<emilio> fantasai: I think the authoring usability problems are actually pretty severe<br>
<emilio> ... it's not too bad to require somebody who wants to use style queries to set this extra rule on all elements<br>
<emilio> ... but the fact that it becomes nearly impossible for the author to then juggle to different values<br>
<emilio> ... so that when they want to set a size container they also need to set style size instead of just style<br>
<emilio> ... that's very tricky and easy to get wrong<br>
<emilio> ... if you have multiple sets of libraries it's very easy to get conflicts<br>
<emilio> ... only way to resolve that problem would be to split the container property into multiple boolean properties<br>
<emilio> ... in order to allow authors to turn them on and off independently<br>
<emilio> ... if we want to avoid making this the default we need to turn them into longhands<br>
<emilio> ... and I suspect most libraries would set style containment as a convenience to the author<br>
<emilio> ... and we're going to have to make these optimizations anyways<br>
<emilio> ... so if we end up having to make these optimizations I'd say we'd rather do this<br>
<emilio> q+<br>
<Rossen_> ack emilio<br>
<fantasai> s/do this/make it the default/<br>
<fantasai> emilio: the problem with making style containment the default, that wouldn't solve the problem with conflicts right?<br>
<fantasai> fantasai: if we make it the default, it would always be a style container regardless of other containment set on it<br>
<fantasai> fantasai: same way list-item is always incremented, unless you explicitly say not to<br>
<fantasai> miriam: that's the clarification we needed if we went in that direction<br>
<jensimmons_> q+<br>
<fantasai> emilio: I don't quite get why style queries are useful<br>
<fantasai> emilio: it seems that regardless of what path we take, the initial value for container type should be 'none' and when we get to style queries, just make every element magically a style query container<br>
<fantasai> emilio: does that sound like a reasonable description of what we're proposing?<br>
<fantasai> fantasai: I think so yes<br>
<fantasai> jensimmons_: I'm still confused about the author experience here<br>
<fantasai> jensimmons_: I think we'll teach everyone to use size queries for the next 2 years, and in that teaching they will be taught that you have to define your container<br>
<fantasai> jensimmons_: your query will be against that container<br>
<fantasai> jensimmons_: when style queries come along, I think authors will expect it to work the same way<br>
<fantasai> jensimmons_: I think they will define a container on the root, or on the main div, or a side element, or whatever<br>
<fantasai> jensimmons_: rather than * { everything }<br>
<fantasai> jensimmons_: I agree that there's a problem with size queries and style queries both being set on the same element and accidentally overriding each other, and we can address that problem<br>
<Rossen_> ack jensimmons_<br>
<fantasai> jensimmons_: that's a flaw, maybe we can address it<br>
<fantasai> jensimmons_: they're going to be designing components and dropping randomly in the page<br>
<fantasai> jensimmons_: there's 2 components, sans-serif and then serif typography stuff, and want to query which one is set and query on that<br>
<fantasai> jensimmons_: but this particular component is going in different places, so font-family is inherited through the tree<br>
<fantasai> jensimmons_: so idk maybe answering question as I talk<br>
<fantasai> jensimmons_: but maybe Miriam you can explain why we want to get away from the idea of defining container<br>
<fantasai> miriam: For non-inherited properties it would work fine to set the container and query it, but for inherited properties you always need to check the parent<br>
<fantasai> miriam: otherwise not getting an accurate idea<br>
<fantasai> miriam: you're generally always going to want to know the closest answer<br>
<fantasai> miriam: and it becomes very fragile if you have to set that explicitly<br>
<emilio> q+<br>
<fantasai> miriam: every time I want to check whether font is italic, I have to make sure the parent has the right style container type before I can find out whether I'm inheriting italics<br>
<fantasai> miriam: and I think that's one of the key use cases<br>
<fantasai> miriam: if the parent's italic, make me normal, if the parent is normal make me italic<br>
<fantasai> miriam: this use case is only possible if we can assume querying parent<br>
<fantasai> miriam: for non-inherited properties, we can always set a name<br>
<fantasai> miriam: and we've gone out of our way to encourage naming containers, both with size queries and style queries<br>
<fantasai> miriam: so that will transfer, there will be differences in these two in how they're used, but if querying something specific you'll give a name<br>
<emilio> q- later<br>
<Rossen_> ack fantasai<br>
<emilio> fantasai: The case where you want to have 2 different styles, you don't actually want to be querying the font-family property<br>
<emilio> ... you likely want to query a custom property<br>
<emilio> ... and you just want to make a custom property that represents your style<br>
<emilio> ... you'll want to track those through custom properties and the style query would let you query what kind of thing you're inside<br>
<emilio> ... and querying always the parent makes sense even if you want to switch (e.g., if you want to switch your color-scheme)<br>
<emilio> ... so I think you want to track that info through a custom property rather than attaching everything to a container<br>
<fantasai> dbaron: Wanted to comment on a use case Miriam raised wrt font-style italicy toggling<br>
<emilio> dbaron: Just wanted to comment on one of the use cases miriam mentioned (toggling between italic/normal)<br>
<fantasai> dbaron: I think using style queries for that feels like a very heavyweight mechanism for solving that problem<br>
<fantasai> dbaron: we had the cycle()/toggle() proposal for that<br>
<fantasai> dbaron: I think a mechanism like that would be more efficient way to address that sort of use case, whereas doing that with style queries, you're using something that's got much bigger perf implications<br>
<fantasai> dbaron: because it's a mechanism that can query any property and apply the result to any other property<br>
<Rossen_> ack fantasai<br>
<bkardell_> I was going to queue to say similar to dbaron - for that specific case at least<br>
<Rossen_> ack dbaron<br>
<Rossen_> ack emilio<br>
<fantasai> emilio: Wanted to make a comment similar to dbaron's, other proposals that may address many of these use cases<br>
<emilio> like `if(<foo>, <bar>, <baz>)<br>
<fantasai> jensimmons_: From what fantasai described, using custom properties and querying them<br>
<fantasai> jensimmons_: put the word style aside, it becomes a way to define variables and query which one is being used right now<br>
<fantasai> jensimmons_: which CSS doesn't have right now<br>
<fantasai> jensimmons_: when people get their heads around that, they might not care about styles, they might just need variable queries<br>
<fantasai> jensimmons_: and that's what they'll start using it for<br>
<fantasai> miriam: large overlap with leaverou's higher-level custom properties proposal, in terms of use cases<br>
<fantasai> miriam: setting properties that you can query and use them in selectors, and make larger changes based on the value of a property<br>
<fantasai> fantasai: There was some issue Oriol raised against toggle(), we decided didn't matter because moving to style queries, but if not need to dig up that issue and see if solvable<br>
<SebastianZartner> If it's mainly about querying custom properties, why not restrict to them for now to do style queries?<br>
<fantasai> fantasai: Regardless of this, do we need to split contain property into longhands per containment type?<br>
<fantasai> fantasai: to avoid conflicts<br>
<fantasai> jensimmons_: If we land somehwere that every element is style container always, then no problem, but otherwise we need to solve the problem<br>
<fantasai> jensimmons_: if someone wants to set up a size query ends up accidentally turning off a style query, that's accidental result<br>
<fantasai> jensimmons_: consider working across teams, across time<br>
<fantasai> fantasai: lots of room for error if we don't split<br>
<fantasai> jensimmons_: especially since the whole point is to allow ppl to create [missed]<br>
<fantasai> jensimmons_: don't know what kind of collisions you'll create<br>
<fantasai> Rossen_: doesn't sound like we're approaching consensus, if anything sounds like we're expanding the problem space of the issue and underlying features<br>
<fantasai> Rossen_: If this was in times when we have more regular F2Fs, I'd say let's do a breakout and come back with proposed changes and move on from there<br>
<fantasai> Rossen_: so perhaps that's what we need to do, do a breakout similar to scroll animations and hash it out<br>
<fantasai> Rossen_: sounds like topic is expanding rather than converging<br>
<fantasai> miriam: I think it's possible that emilio's suggestion would allow browsers to release without a problem<br>
<fantasai> miriam: initial value is 'none', and if make style containers the default, not doing with an initial value of style would do it more globally<br>
<fantasai> miriam: so that might be a resolution that gets us able to release size queries without solving this<br>
<emilio> fantasai: I have a different idea<br>
<emilio> ... that'd solve style queries, but not other types of containment in the future<br>
<emilio> ... cause we want to also allow for other containment types in the future<br>
<emilio> ... we'd need to release a longhand<br>
<emilio> ... my concern is that grouping these into this one property causes issues in the future<br>
<emilio> ... I think that's something we are going to need to explore before we ship<br>
<emilio> ... because if we ever add another type of containment that isn't size containment...<br>
<emilio> jensimmons_: maybe we don't even need to make them a shorthand<br>
<emilio> ... whatever gets decided I'd argue for folks to decide soon<br>
<emilio> ... because Safari 16 is going to ship container queries<br>
<emilio> Rossen_: I don't think we'd like to suggest to punt on this for weeks or months<br>
<emilio> ... still not hearing good consensus<br>
<emilio> ... do we want to try to resolve on anything today?<br>
<emilio> ... or do a breakout session next week or so?<br>
<emilio> fantasai: I'd say we discuss and explore the longhands approach and come back next week<br>
<emilio> Rossen_: I think there are a couple of other issues in the same space that deserve focus time<br>
<emilio> ... happy to help organize something<br>
<emilio> ... if that moves the ball forward quicker<br>
<emilio> emilio: It seems there's agreement on `style` not being a value on `container-type`<br>
<emilio> ... regardless of whether we split `container-type` into longhands or not<br>
<emilio> fantasai: I wouldn't be happy to resolve without an alternative<br>
<emilio> Rossen_: let's take it back to the issue<br>
<emilio> ... and bring it back next week. Happy to prioritize if there's progress / something we can resolve on<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7066#issuecomment-1150156723 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 8 June 2022 16:49:24 UTC