- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 20 Oct 2022 05:45:02 -0400
- To: www-style@w3.org
========================================= These are the official CSSWG minutes. Unless you're correcting the minutes, Please respond by starting a new thread with an appropriate subject line. ========================================= Meeting Schedule ---------------- - There will be an extended meeting on Wed Oct 26, 2022 from 7:00am – 10:00am PT CSS Values 3 ------------ - RESOLVED: Close no change (Issue #7431: Restrict none/auto/normal from <custom-ident>) Media Queries ------------- - RESOLVED: Properly define resolution of media type and top-level MQ (Issue #7595: Merge error handling section into evaluating section) - RESOLVED: Clarify the spec text to reflect intended unknown mechanics (Issue #7595) - RESOLVED: Replace "replace by not all" with "evaluates to false", open a separate issue on serialization (Issue #7595) CSS Contain ----------- - RESOLVED: content-visibility applies to elements that can have size containment (Issue #7658: Should content-visibility apply to elements when size containment has no effect?) CSS Overflow ------------ - RESOLVED: For overflow:auto and size containment, 1st phase sizes without scrollbars, 2nd pass adding scrollbars doesn't change the size (because it is fixed). Clarify (Issue #7875: overflow: auto incompatible with size containment and container queries) CSS Nesting ----------- - The discussion for issue #7834 (Syntax Invites Errors) began by reviewing the four proposals and the feedback gathered on them: https://github.com/w3c/csswg-drafts/blob/main/css-nesting-1/proposals.md - The voting indicated options 1 & 3 and the group affirmed interest in those options. There was also a desire to investigate option 4 further, but the group ran out of time to discuss further on the call. ===== FULL MINUTES BELOW ====== Agenda: https://lists.w3.org/Archives/Public/www-style/2022Oct/0007.html Present: Rachel Andrew Adam Argyle Rossen Atanassov Tab Atkins David Baron Emilio Cobos Álvarez Erika Etemad Robert Flack Simon Fraser Brad Kemper Jonathan Kew Una Kravets Vladimir Levin Daniel Libby Peter Linss Alison Maher Eric Meyer François Remy Morgan Reschenberg Florian Rivoal Khushal Sagar Jen Simmons Alan Stearns Miriam Suzanne Bramus Van Damme Lea Verou Regrets: Chris Harrelson Chris Lilley Chair: astearns Scribe: fantasai Scribe's scribe: vmpstr Administrative ============== astearns: Reminder that we have a multi-hour format next week fantasai: Publishing? <fantasai> https://lists.w3.org/Archives/Member/w3c-css-wg/2022OctDec/0033.html <fantasai> https://lists.w3.org/Archives/Member/w3c-css-wg/2022OctDec/0026.html <fantasai> Values 3 CR update <fantasai> and Box Model 3 PR ? <fantasai> https://lists.w3.org/Archives/Member/w3c-css-wg/2022OctDec/0034.html <fantasai> Values 4 WD ^ astearns: Let's try to do those async, and get to publishing next week lea: Want to make sure we get to the nesting syntax discussion today lea: since it's shipping <argyle> the eng on chrome's side spent a very small amount of time on that work (@nest), and is anticipating changes CSS Values 3 ============ Restrict none/auto/normal from <custom-ident> --------------------------------------------- github: https://github.com/w3c/csswg-drafts/issues/7431#issuecomment-1178237576 TabAtkins: I filed the issue, happy to withdraw fantasai: Would've been nice to make it excluded, but I understand there's compat risk astearns: Proposed resolution is to close no change <TabAtkins> I didn't file the issue actually, Elika did. (But it happened as a result of us discussing it together.) RESOLVED: Close no change Media Queries ============= Merge error handling section into evaluating section ---------------------------------------------------- github: https://github.com/w3c/csswg-drafts/issues/7595 gsnedders: We currently don't have interop with some types of errors around invalid media features gsnedders: because essentially we don't define clearly how any of this is meant to work gsnedders: There were proposals to put this into Interop 2023 gsnedders: need to know what exactly we'll be testing gsnedders: A few sections gsnedders: First, we don't define how to evaluate media type or the top-level media query at all gsnedders: and we just say that an unknown media type is treated as not matching gsnedders: whereas unknown media feature [logic] gsnedders: Suggest to define how to evaluate MQ with handwavy definition of media types matching if appropriate TabAtkins: Agree florian: I agree, media type is not properly defined, but that's not hard. Can be more specific than mentioned florian: since most deprecated by now florian: so only two cases where we differ from screen florian: for top-level MQ, what it ought to be is fairly obvious but we should write it down gsnedders: Proposed resolution is to define how to evaluate media query and media type gsnedders: in somewhat obvious way astearns: any objections? <TabAtkins> I think we should keep it undefined, to keep things interesting. RESOLVED: Properly define resolution of media type and top-level MQ gsnedders: Next, unknown media name or ??? gsnedders: results in value of unknown gsnedders: but we don't say what exactly is given unknown gsnedders: an MF name or MF value doesn't have a value gsnedders: Currently FF and Chrome differ gsnedders: FF makes the entire MQ unknown if any media feature name or value is unknown gsnedders: whereas Chrome only makes that specific one unknown florian: Chrome is right, the whole point of this logic is doing this TabAtkins: [agrees] gsnedders: I can justify both behaviors from current spec text florian: We'll clarify, the intention is 100% clear to the spec editors, so we just need to fix the test RESOLVED: Clarify the spec text to reflect intended unknown mechanics gsnedders: Final bit is, MQ whose value is unknown must be replaced with "not all" gsnedders: but not clear what it means to replace an MQ gsnedders: maybe need to define MQ serialization? TabAtkins: I think that's right, but... TabAtkins: I think it's a serialization issue gsnedders: I think we need to say that unknown MQ evaluates to false, and serializes to "not all" florian: Makes sense to me emilio: We don't have this thing to support ... with generalized enclosed emilio: Is that a compat requirement? florian: Part where unknown MQ evaluates to false, that is absolutely desired intent florian: whether accidentally replaced with "not all" with no effect on serialization or whether was intended to talk about serialization, then I don't know gsnedders: I think it goes back to CSS2 gsnedders: It could literally just be copy-pasted from earlier level with no thinking <TabAtkins> MQ has a bunch of legacy weirdness that I didn't replace emilio: We don't implement this update to the spec, but if we did we'd probably want to be consistent with @supports emilio: and @supports when you throw something random at it, you serialize that emilio: rather than a false statement florian: Should we say, gets evaluated as false? or does that lose something important? emilio: I think so, but not sure how that maps. I think spec said this had to be some value with 3-way state... florian: When you propagate unknown ... emilio: That was not the desired behavior, and we changed it. Unknown just evaluates as false emilio: so probably we want to be consistent, and unknown evaluates as false? TabAtkins: We very specifically want @supports unknown to be false, because if you can't parse it you definitely don't support it TabAtkins: but for MQ, whether you are that type of media or not, you don't know if you can't parse the MQ <fremy> +1 to what TabAtkins just said florian: I think that the "gets replaced by not all" is an ancient and imprecise way of saying evaluate as false, and we should replace this and not talk about serialization gsnedders: With prior resolution, very few if anything will result in the whole MQ being unknown TabAtkins: Not necessarily true, e.g. combine with and and you'll get unknown propagate up gsnedders: Yes, nevermind astearns: Should we resolve, or need more time? emilio: Fine as long as we're all on the same page florian: Instead of "replace by not all" say "evaluates to false" gsnedders: Define serialization of unknown MQ to be "not all", is that still the intention? florian: Let's open a separate issue for serialization, since might have compat concerns florian: Want to look into that offline RESOLVED: Replace "replace by not all" with "evaluates to false", open a separate issue on serialization <gsnedders> florian: are you gonna be able to make these MQ edits in the nearish future (as in weeks), or should someone else do so if we want it in the spec soon? CSS Contain =========== Should content-visibility apply to elements when size containment has no effect? ----------------------------------------------------------------- github: https://github.com/w3c/csswg-drafts/issues/7658 florian: The content-visibility property is said to apply to elements to which layout containment can apply florian: to keep simple, there's a hidden value and an auto value florian: when you turn on hidden, it turns on all four types of containment florian: but there exist elements for which layout containment can apply but size containment doesn't florian: if you're on such an element, content-visibility doesn't do what you expect because can't get the 4th type of containment florian: similar issue with 'auto' florian: so I think we should change the applicability of content-visibility florian: to elements to which size containment can apply vmpstr: I agree, when we wrote layout containment I didn't realize it was possible to have only one of size/layout containment vmpstr: I would have hoped the condition for containers being the same, switching content-visibility to track size containment makes sense to me fremy: I actually have one question, when we say doesn't apply, constants will still be visible? florian: yes, property doesn't take effect fremy: For visible, should be obvious, you're the author you try to understand why fremy: but for auto it's tricky, because you might not notice it doesn't apply florian: Interesting point, and probably should do something to that florian: but not strictly about this issue florian: because we're changing what it applies to, but already have case where it doesn't apply to some boxes fremy: Why do you need size containment for content-visibility? fremy: oh, because we don't want to relayout ... astearns: Proposed to have content-visibility to apply to elements that can have size containment (only requirement) astearns: objections? RESOLVED: content-visibility applies to elements that can have size containment CSS Overflow ============ overflow: auto incompatible with size containment and container queries ----------------------------------------------------------------------- github: https://github.com/w3c/csswg-drafts/issues/7875 oriol: When have overflow auto, only scrollbars when overflowing oriol: but that can affect sizing oriol: According to spec, there are 2 ways of handling these oriol: one behavior, if element is intrinsically sized oriol: then inner size of element will be intrinsic size, and scrollbar added onto that oriol: this makes the element bigger oriol: other behavior is when element is extrinsically sized oriol: inner size is reduced to make room for scrollbar without affecting outer size oriol: Blink has implemented oriol: firefox and webkit only do this in inline axis oriol: Having said this, behavior is problematic in different ways related to containment oriol: examples in the issue oriol: There's an optimization that browsers can apply oriol: when descendant changes size, we don't have to compute size of size-contained element and its ancestors oriol: but if this element has overflow:auto and intrinsically sized, then adding the scrollbar can cause the outer size to grow oriol: so we cannot apply this optimization oriol: and then browsers are broken because they assume they can apply the optimization, and it looks bad oriol: can get scrollbars floating outside the element, or have sudden changes in size ... florian: I think they're broken, but for a different reason florian: I think spec is correct florian: because contain:size is defined to work in 2 phases florian: in the first phase, you size as if empty florian: not going to get scrollbars florian: but then you fix that size florian: then you're no longer intrinsically sizing florian: so when you're adding content into the fixed size, you are no longer intrinsically sized florian: at that point, you need ot add the scrollbars inside <iank> I agree with florian florian: I think that's the bug in the implementations florian: so Chrome is putting the bottom scrollbar outside, as if intrinsically sizing, but we're not oriol: I guess this argument would apply even without size containment, in the normal case you have 'width: max-content' then you could say the same oriol: during first phase you do intrinsic size, and then element gets is size computed, and then you do final sizing fantasai: Is the example with max-content with or without size containment? If it doesn't have it, we don't fix the size so we get weird results with scrollbars if you have normal element with normal sizing oriol: In grid layout, if grid container has width:max-content, then first you run track sizing algo with indefinite size oriol: and then when you know this size you fix the grid container and lay out again oriol: regardless of size containment or not oriol: so maybe the behavior of scrollbars added on top, reduce the inner size, maybe this wording may need to be different or maybe I didn't explain it well oriol: but the same argument would apply in both contained an non-contained one iank: I think this is two problem iank: I agree with florian, initially size it without scrollbars present and then it will overlay content if you overflow in that direction iank: I think that's straightforward, should get a resolution iank: more general problem of sizing things in the presence of auto scrollbars iank: is complicated iank: we have our layout engine a little state machine that will go through and basically add scrollbars [missed] iank: still bugs trying to get rid of iank: but that's a separate issue florian: Might be complications in various layout modes, I think for contain case the spec is clear florian: about the 2 phases oriol: So final outer size does not depend on whether it gets scrollbars or not? florian: Correct oriol: Then we have circularity problem with Container Queries astearns: If you want to present an additional problem, that should be in the issue or separate issue astearns: we do need to get to next item [discussion of resolution to take] florian: I think the spec specifies this correctly florian: could be clearer, but it's there oriol: I think it needs to be clarified with interaction with spec prose in css-overflow oriol: Because overflow says to recalculate sizes astearns: So one proposal is to clarify that when things are initially sized under size containment, they're sized without scrollbars florian: That's clear florian: it's the other part that's less clear florian: once you add the content, size containment says you keep the size fixed florian: and just because you have scrollbars, doesn't change that fact <iank> I'm fine with that. astearns: Proposal is to clarify that in 1st phase size without scrollbars, and in 2nd pass scrollbars don't change the size RESOLVED: For overflow:auto and size containment, 1st phase sizes without scrollbars, 2nd pass adding scrollbars doesn't change the size (because it is fixed). Clarify CSS Nesting =========== scribe: emeyer Syntax Invites Errors --------------------- github: https://github.com/w3c/csswg-drafts/issues/7834 astearns: fantasai has suggested we should focus on this call on whether we replace the text in the specification with option 3, and then have further discussion later on proposal 4. <TabAtkins> +1 <lea> +1 <bramus> SGTM <astearns> https://github.com/w3c/csswg-drafts/blob/main/css-nesting-1/proposals.md astearns: We have four options with pros and cons, and some poll results astearns: Most positions are between options 3 and 1, with a smattering of 2 and 4. <lea> I have added some vote counts under the table fantasai: Many considerations here. We have problems with the current syntax, which requires a lot of ampersands that are hard to remember where they're needed fantasai: we also want portability of the code structures is a concern with the current syntax fantasai: there was another concern about confusion over spaces, but that seems minor fantasai: Our options are: always prefix, nest into blocks, use a switch to change modes fantasai: We explored many possible syntaxes. Lea? lea: Option 3, you can nest without ampersands for most selectors lea: except the only descendants you need ampersands is element selectors lea: The advantage is there's no parser switch, and it's also much less verbose than current syntax lea: If you have a descendant selector that start with an element, you do need to ampersand that lea: Compatibility with Sass is not a concern here, because it's a one-time cost lea: In general, the closer we can get to the Sass syntax, the better; developers like it lea: People find the current syntax quite noisy lea: We might also be able to relax syntax in the future, if we can figure out a way to do so astearns: Ampersands not required, but allowed, yes? (collective affirmation) fantasai: Devs seem split 50/50 on use of ampersands or not fantasai: As far as the proposal, the basic rule for nesting a selector is that you can't start with a letter <dbaron> (I think it's a letter or a dash?) <lea> dbaron: yes TabAtkins: While I initially supported option 1, having looked through the details, option 3 is very good TabAtkins: It most of the time gives you the ability to write like in Sass, with one awkward exception that's easy to tell apart TabAtkins: Most of the time you can use an ampersand to nest and it works out fine TabAtkins: The rule for whether you need it or not is very clear, and this does allow us to be close to Sass jensimmons: There are a lot of things about option 3 I really like, but the one thing I feel is a non-starter from my perspective is that not all selectors are treated the same jensimmons: Authors have to know that nesting is easy most of the time, except in this one case jensimmons: I understand the mitigations, the problem is teaching authors that this one selector type is weird, and the syntax isn't consistent across all selector patterns <lea> Clarification: I didn't say element selectors were rare *at all*. Element selectors where the parent selector is inserted later (e.g. strong &) is rare. argyle: When you go to paste and forget the &, that's a problem, but syntax highlighters are there to help authors argyle: Option 1 is the most portable because it's unambiguous argyle: The community outside the WG has already passed the WG, which may be why a lot of people didn't seem to case about the verbosity argyle: Option 1's simplicity is appealing for tooling and to machines argyle: Teaching option 1 is easy, because it's very consistent argyle: Teaching 3 or 4 gets muddy and complicated argyle: I did like the idea that most of the suggestions of 3 and 4 build on option 1, so I like the idea of going with option 1 and then in Level 2, we could use 3 and 4 argyle: This would let us unblock engines that already do option 1 now <fantasai> 4 doesn't build on 3 or 1 or anything <fantasai> and also doesn't have any exceptions <TabAtkins> 3 has exactly one exception, same as 1 (and imo of the same complexity). 4 has no exceptions. It was the 2 variants that had slightly more complex requirements. <argyle> correct, 4 doesn't build on 1, my bad fremy: I'm glad that we aren't considering option 2. I'm mixed between 1 and 3, and agree with the points mentioned before fremy: I'm kind of okay with 1, would be fine with 3, the consistency of 1 feels better fremy: If I had to choose, I'd probably say 1, but wouldn't be mad if we choose 3 fremy: I see myself converting nested rules into scoped rules, which we aren't really addressing fremy: Having a syntax incompatible with :scope is annoying and a downside fremy: You should be able to copy and paste anything and not have to rewrite anything <argyle> memorizing idents shouldn't be a requirement to nest effectively.. lea: Replying to jensimmons, I didn't say element selectors are rare, but that element selectors where the ampersand comes later are rare <fantasai> lea mentioned that `strong &` is rare, but `& strong` is fairly common and can be done with & as today miriam: Both proposals have weird edge cases miriam: in option 1, you have to learn when to use or not use @nest miriam: in option 3, you have to learn when to use ampersands with a descendant miriam: In my mind it's a little easier to teach, because I can teach that you always have to start with a symbol miriam: I do see Adam's point that 1 and 3 are interoperable if we want them to be miriam: I don't know if that's an interesting approach to take, but it is possible <fremy> miriam, we could just replace `@nest` with `&` and say that if there are one at the start and one later one, the one later one wins astearns: I think it's intriguing to do 1 and then allow 3 in the future <jensimmons> I wish we had time to talk about option 4. If we ended up like 4 best, there's no need to debate 1 vs 3, etc. <fremy> jensimmons I agree, we will have more time next week <bradk> I agree with the idea that #3 still allows you to do #1 astearns: We need to take this back to the issue and come back to this next week with another scoped-time discussion astearns: Please do discuss further in the issue.
Received on Thursday, 20 October 2022 09:45:44 UTC