W3C home > Mailing lists > Public > www-style@w3.org > October 2022

[CSSWG] Minutes Telecon 2022-10-19 [css-values-3] [mediaqueries] [css-contain-2] [css-overflow] [css-nesting]

From: Dael Jackson <daelcss@gmail.com>
Date: Thu, 20 Oct 2022 05:45:02 -0400
Message-ID: <CADhPm3uOgNfO6xTjNXO0oRpFdQp-qN4+QhKtXCQwaz-19m-r4g@mail.gmail.com>
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

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:15:21 UTC