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

[CSSWG] Minutes Telecon 2022-01-05 [css-flexbox] [css-values-4] [cssom] [css-break] [cssom-view] [css-contain-3]

From: Dael Jackson <daelcss@gmail.com>
Date: Thu, 6 Jan 2022 06:26:56 -0500
Message-ID: <CADhPm3tob1S2bv9c7t3OKrf+cP-J=MQ_0YPKbmkPmKP_V+FB=w@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.

CSS Flexbox

  - RESOLVED: We will spec that grid, flex, and table fragmentation
              align globally before fragments are created (Issue #6812:
              Flexbox alignment and fragmentation)
  - RESOLVED: We will not truncate margins at any break when aligning
              globally for fragmentation (Issue #6812)
  - alisonmaher will reach out to print formatters to get feedback on
      the above resolutions. If they have a different opinion the group
      will revisit.

CSS Values

  - RESOLVED: The mix interpolation function will only be used for
              top-level values with various discussed caveats. mix() is
              the name of the top level interpolation (Issue #6700:
              Validity of generic interpolation function mix())

CSSOM & Fragmentation

  - The general agreement from the github conversation for issue #6513
      (getComputedStyle and fragmentation) was to select a simple value
      to return, create exceptions where compat demanded, and direct
      authors toward existing fragment-aware APIs if they need an
      accurate answer.
  - On the call, there were concerns about breaking compat since these
      properties have existed for a while, even though there isn't
      interoperability. Suggestions were to do a deeper dive into
      properties and specify a compat-friendly requirement or to
      specifically state browsers handle this differently and there is
      no interop. Discussion will continue on github to reach a


  - RESOLVED: When an inline box is split by a block box, offsetWidth
              and offsetHeight will include dimensions of block box
              (Issue #6588: Needs more details for offsetWidth and

CSS Contain

  - RESOLVED: Property and fontface rules always work in an @container
              rule (Issue #6827: What happens to other @rules inside

===== FULL MINUTES BELOW =======

Agenda: https://lists.w3.org/Archives/Public/www-style/2022Jan/0003.html

  Rossen Atanassov
  Tab Atkins Bittner
  David Baron
  Simon Fraser
  Megan Gardner
  Chris Harrelson
  Daniel Holbert
  Dael Jackson
  Ian Kilpatrick
  Daniel Libby
  Ting-Yu Lin
  Alison Maher
  Cameron McCormick
  Florian Rivoal
  Jen Simmons
  Alan Stearns
  Miriam Suzanne

Scribe: dael

  astearns: Happy new year everyone. Thank you for coming back after
            the break
  astearns: On private list we have a backlog so we'll look for a
            longer form meeting. If anyone has preference for when
            please post to the private list


Flexbox alignment and fragmentation
  github: https://github.com/w3c/csswg-drafts/issues/6812

  alisonmaher: This is about handling alignment when fragmenting. Issue
               also applies to grid and tables
  alisonmaher: According to spec it suggests align per fragment.
               Flexbox is only that makes this suggestion. Can confuse
               implementers and may imply flexbox is unique.
  alisonmaher: Would it make sense to change to suggest align prior and
               can ignore
  alisonmaher: Advantage of ahead of time is it layout more similar to
               non-fragment. Consequence is how to handle margins. Spec
               says truncate at soft break and they can affect
               alignments so may not want to truncate
  alisonmaher: Firefox does not truncate
  alisonmaher: Proposal: update to match Firefox for margins during
               fragmentation and add similar language in grid and tables

  iank: Broadly supportive
  iank: When fragmenting, doing it globally somewhat makes most sense
        when you look. Otherwise you can get things in unexpected
        columns and not aligning at the end

  astearns: I'm not entirely convinced of the preference for stitching
            back together in way that looks more like unfragmented, but
            not against the change
  astearns: If there is a use case for align per fragment is that a
            switch we can add, maybe like how we do box decoration
            breaks where an author can choose?
  iank: Potentially. I think for that case what we might do is treat
        everything as start aligned and do alignment then
  iank: One thing that should be said is this would match what impl do
        in reality. Blink at the moment because we're adding proper
        fragmentation and fixing bugs
  iank: Theoretically possible to have a switch. Place where per
        fragment makes sense is content-alignment. But that's different
  dholbert: Justify content?
  iank: No, talking about...what's the keyword...we don't have it, I
        think only Firefox does. Let me look it up
  dholbert: first-baseline and last-baseline?
  iank: Ignore my last comment. I'm confused.

  florian: Usually when it comes to things that relate to fragmentation
           print formatters have spent more time on this. Prince at
           least supports both fragmentation and flexbox. Might be
           worth looking at what they do. If it's not what we're
           proposing we should think about it more
  iank: This is slightly larger than flexbox since it applies to grid
        and table
  florian: I don't remember if they do grid. Might
  iank: For grid doesn't make a lot of sense to do by fragment
  florian: I don't have an objection, but given it applies to things
           important to print formatters it's worth looking at what
           they do. We can make a revision and put a to do to look and
           revisit if needed
  astearns: Is there a good person to tag? I would go to Dave Cramer
            but I'm not sure how much time he has for CSS
  florian: That was my answer as well
  astearns: Maybe we can tag Dave and see if he can give us an idea of
            what Prince is doing. Somewhat convinced we should take the
            proposal since it's what Firefox is doing. If there is a
            difference we can think again
  dholbert: Firefox supports the change. It feels like most coherent
            thing to do
  iank: That's what I came to as well. It falls out to make most sense

  astearns: Prop 1: We will spec that grid, flex, and table
            fragmentation align globally before fragments are created
  alisonmaher: Correct
  astearns: Do we need anything about margins in that resolution?
  alisonmaher: Separate resolution
  astearns: Concerns about that resolution?
  astearns: Objections?

  RESOLVED: We will spec that grid, flex, and table fragmentation align
            globally before fragments are created

  alisonmaher: Margins want when handling alignment globally shouldn't
               truncate margins at soft breaks
  astearns: Can we do that without causing any cycles in determining if
            a soft break
  alisonmaher: I think Firefox already doesn't truncate margins in
               flexbox case so I think there's a prior for it
  astearns: Okay. Interested in seeing test cases we can apply for
            this. Seems to me lots of weird edge cases for particular
            kinds of margins. I suspect not well tested
  alisonmaher: Yeah
  astearns: Anything more to discuss about margins?
  dholbert: Additional point, when doing global alignment the thing
            aligned is the margin box which is why it makes sense to
            preserve the margins
  astearns: When we are aligning globally we will not truncate margins
            at any break
  alisonmaher: We could say it generally
  astearns: Prop: we will not truncate margins at any break when
            aligning globally for fragmentation

  RESOLVED: We will not truncate margins at any break when aligning
            globally for fragmentation

  astearns: Blink is going through this and will be adding new
            fragmentation code. Test cases as you go?
  alisonmaher: Yeah
  astearns: alisonmaher would you ping Dave Cramer?
  alisonmaher: Sure

CSS Values

Validity of generic interpolation function mix()
  github: https://github.com/w3c/csswg-drafts/issues/6700

  TabAtkins: Making sure we agree what generic interpolation does and
             if it's valid
  astearns: Only concern is last comment asked for fantasai to clarify
  TabAtkins: True. But not relevant for this, I think.

  TabAtkins: We have a couple of mixing functions like color-mix and
             calc. These functions have a type. Color-mix is a color,
             valid where ever a color is. But generic interpolation
             function, currently called mix(), I don't believe can be
  TabAtkins: It can interpolate things without describable types.
             Interpolate of a box shadow is only valid in box shadow.
  TabAtkins: Proposal is mix() is only allowed as top-level value of a
             property. That's all it would be produced as by UA, but if
             authors use it they could not combine with other things.
             Can't mix 2 box shadows and then add inset.
  TabAtkins: I believe that's all this is about, verifying that's what
             we want for the grammar of this function
  TabAtkins: If no one disagrees we can resolve

  smfr: Questions- if you have property with comma separated values
        like backgrounds, can you use mix() in the list or is the whole
        list a mix()?
  TabAtkins: Great question. Hmm.
  TabAtkins: I think still the entire thing. Even in lists of comma
             separated we can have distinct syntax at a position like
             background where only color in the last. We couldn't
             interpolate a mix() with a color unless it's final. So
             would have to be the entire thing

  smfr: High level, how does this interact with animations? Can I use
        it in keyframes?
  TabAtkins: Should be usable anywhere that accepts a value. Value is
             generatable by an animation so it should be a valid value.
             You can interpolate to this. Things you can do by hand
             should allow explicitly.
  smfr: keyframe? only animatable properties?
  TabAtkins: Yes, if property wasn't animatable then mix() wouldn't
             have a meaning. Great question and not in spec. I suspect
             should be properties that are not animatable mix is
             invalid at parse time.
  smfr: If you can spec in keyframes implies mix() can nest
  TabAtkins: because you can mix between and mixed value and something?
  smfr: Yeah
  TabAtkins: True. Good clarification. mix() should be able to be an
             entire argument of the mix(). You should be able to mix
  smfr: Shorthands vs longhands when mix is the entire value?
  TabAtkins: We had an answer. I believe it needs to be similar to
             variable in shorthands, but don't recall exactly. Whatever
             it was, we can't rely syntaxtically that something is a
             shorthand so whatever we define has to work well for
  TabAtkins: Mix should be allowed in a shorthand. Exact interpolation
             I can't answer but should be as reasonable as can make it
  smfr: Sounds good

  astearns: Looking for resolution to define mix() as only top level
  astearns: Issue also talks about adding another lower level value.
            Punt that for now?
  TabAtkins: Yeah, it's separate
  astearns: But if we expect lower question is which gets the shorter
  TabAtkins: My argument is the existing lower-level have longer names
             like color-mix. Completely usable anywhere should get the
             shortest name. No way to be generic low-level because we
             need to know type to parse. Interp at the value level will
             be type specific. mix() should have the short name and
             others longer and more specific
  astearns: Other questions or ideas?

  astearns: Prop: The mix() interpolation function will only be used
            for top-level values with various discussed caveats
  TabAtkins: Should also resolve on name
  astearns: And mix() is the name of the top level interpolation
  astearns: Objections?

  RESOLVED: The mix interpolation function will only be used for
            top-level values with various discussed caveats. mix() is
            the name of the top level interpolation

  astearns: Since this issue discusses lower level, is that captured
            elsewhere or should we open another issue?
  TabAtkins: One talked about is numeric and that does have an issue
             for it
  astearns: I'll see if I can find it and link it

CSSOM & Fragmentation

getComputedStyle and fragmentation
  github: https://github.com/w3c/csswg-drafts/issues/6513

  florian: A while ago looking at definition of getComputedStyle and it
           does not mention fragmentation. This is a problem because
           element fragmentation gives multiple answer to value of
           property. What to do?
  florian: GH suggestion which is roughly okay with commenters is other
           APIs are fragment aware so people who want per fragment
           should use those. This API we should do simplest with tweak
           for compat
  florian: Simplest is return first fragment. Might need to tweak based
           on historic impl. Assuming horizontal writing mode, height
           of the block chrome returns sum, though Firefox returns
           first. Probably not compat problem there, but might have it
  florian: Suggestion is document that getComputedStyle returns based
           on first fragment and we document compat issues separately
  florian: Suggestion from fremy to make it a little smarter and answer
           on last for other writing modes. I think I would suggest not
           taking the suggestion. This will not be smart enough to
           describe everything so you need fragment aware APIs
  florian: If compat dictates smarter this could be one of the things,
           but would rather not if we can keep it simple
  TabAtkins: I think I agree. Don't think we can get smarter without
             being complex. Going with simple answer of first fragment
             is easier

  iank: Not wild about first fragment. Larger set of problems about
        client width and height and how they interact
  iank: In a lot of libraries they compute to width and height and used
        interchangeably. Someone using this naively they would get
        unexpected results when printing. If you sum as I suggest in
        the issue you get broadly expected
  iank: I don't expect a large compat issue, but it's a little
  florian: Can we say unless documented we go with first fragment but
           with block dimensions we sum up. And maybe for padding,
           border, margin we take last for inline-end and block-end.
           Maybe that's enough of an exception?
  iank: What properties return used? width height padding border margin?
  florian: More. Offsets as well
  florian: width height margin padding, top left bottom right
  florian: Another complication is we're baking selectors that let you
           style different fragments differently and then any property
           could have a different answer. Not exposed, but might be
  iank: With that we would start not to return...you can't really...a
        lot will break if you set different margin-top per fragment.
        Skeptical we'll need to do something for that case
  florian: Even if we don't get that. For margin-bottom return the
           first, last, depend on box-decoration-break? If compat
           dictates we should take that
  iank: Rather then applying general rule would be good to go through
        cases individually and come up with answers. I suspect I agree
        with margin and padding for first/last fragment but width and
        height we want different.
  iank: It would be better to do case by case

  Rossen: I'm more closely aligned with iank then the simplicity.
          Generally I'm all for simpler and more definitive answer. I
          believe there will be unfortunate compat breakage we'll see
          for apps building pagination-ish presentations
  Rossen: I've seen a number of apps using multicol to drive book-like
          experiences. For them, back in the time this is why we into
          getClientRects and go down patch of fragment aware things.
          Zooming out, not being able to know where a box starts which
          is what you will run into if you only give results on first
          fragment which could give you a result under the 2nd, that
          would be unfortunate
  Rossen: I'm closer aligned with iank's point
  florian: Strongly agree we need something that's fragment aware. But
           getComputedStyle isn't fragment aware. As to breaking
           interop, we don't have interop.
  florian: Another thing I forgot to mention is we don't need to get to
           fancy APIs to get into trouble. We could sum heights, but
           what to do with width when fragments have different width?
           Or an inline that breaks 2 lines? Block that's across 2
           pages? No answer in the spec
  florian: We can go property by property as iank said. Having done
           that for height there's no interop
  astearns: Not that we break interop but that we break compat. There
            are likely sites that rely on Blink's behavior. Risk
            breaking them if we spec differently
  florian: But if it's engine specific should we also not change FF?
  Rossen: If they don't have bugs they're either not used for these
          presentations or they've coded to adapt. I want to underscore
          the point about compat vs interop. I'd be more concerned
          about compat at this point

  astearns: If concerned about compat and there isn't anything that we
            can spec as safe, perhaps we explicitly say
            getComputedStyle is not fragment aware, different engines
            return different and we don't spec what to do
  florian: Not terribly helpful
  astearns: It's not. But going through what to do with every layout
            property with interesting fragmentation when we can't spec
            something interop, is that a wild goose chase?
  Rossen: Sounds more academic than applicable. Do we have use cases
          for alignment? These properties have existed for quite some
          time so people work around it
  florian: Confused how it can be true simultaneously that this is
           sufficiently used that we can't change but unused that we
           don't have to answer. If people aren't using this spec
           simple or say undefined. If it is used would be good to have
           a known behavior for interop
  smfr: Might have legacy content on each browser relying on the
  Rossen: epub viewers are built against 1 engine and for these
          applications they have very specific code with very specific
          behavior for the engine. Whatever that engine does is what
          they'll get
  florian: Not so sure. Paginators are frequently cross-engine.
  iank: Specific example, a lot of people run chrome in headless to
        generate pdfs. A lot of people doing that

  iank: To my previous point, only properties we'd use layout dependent
        is margin, padding, width, height, and the insets
  florian: Also borders. Sizes don't change but box-decoration-break
           might or might not have
  florian: But yes, it's those
  iank: I wonder if we can go through these and pick what is
        reasonable. For example, for the edge type things, border
        padding margin and insets I'll agree picking first or last will
        be pretty compat. not huge burden on engines to sum on block
        and take max on inline
  iank: I think blink and wk do that already. Would be interested to
        hear for gecko
  florian: Not particularly hard. But in viviostyle there is a measure
           of lazy rendering for a many 1000 book and having a blocking
           call that forces you to layout isn't great. Maybe no way
  iank: I can come up with examples that will render incorrect due to
  florian: Yeah. For block maybe no way around. For inline maybe we can
           just do first?
  iank: Yeah. I'd like this consistent with client height. A bit of
        precedence with inline element fragmentation. Might be wrong

  chrishtr: No strong opinion, but maybe take this offline for specific
  chrishtr: There is #6588 on the agenda which we need for progress
  astearns: Okay, will go back to GH on this issue and get a list of
            properties we want to consider fully


Needs more details for offsetWidth and offsetHeight
  github: https://github.com/w3c/csswg-drafts/issues/6588

  chrishtr: Discussed Oct 6 and resolved that they should be computed
            out of principle css box
  chrishtr: If you have an inline split into multiple fragments with a
            child that's block should the balance of the block be
  chrishtr: No strong opinion in discussion. Weak opinion not to, but
            implementation difficulty should be a factor
  chrishtr: Engineers have been trying to simplify code and have found
            that including it would be simpler to impl and give same
            answer as getBoundingClientRect. Suggest include block box
            in the bounds
  astearns: Make sense.
  astearns: Proposal: When an inline box is split by a block box,
            offsetWidth and Height will include dimensions of block box
  astearns: Objections?

  RESOLVED: When an inline box is split by a block box, offsetWidth and
            offsetHeight will include dimensions of block box

CSS Contain

What happens to other @rules inside @container?
  github: https://github.com/w3c/csswg-drafts/issues/6827

  miriam: Dealt with a version of this problem before
  miriam: Containers don't have a global resolution. Specific to
          elements and contexts
  miriam: Need to know if allowed and what happens to have global
          @rules like property or @fontface inside @container
  miriam: On thread agreed for these rules we think @container should
          be treated as true for all cases like these to be consistent
          with previous decisions
  astearns: No difference in having @fontface inside or outside a
  miriam: Right
  astearns: Reasonable to me
  TabAtkins: Yep, agreed

  dbaron: At first glance seems surprising. Are there other things that
          work this way?
  astearns: Talked about layer order previously
  miriam: Yeah, layer order. I feel like also some name defining
          @rules, but that's this so maybe we didn't. I think there was
          previous art on this
  TabAtkins: Ultimately they're always true or false, we can't make
             them dependent on the query. The always true is
             consistent. But we could say it's always false if that's
             more reasonable.
  dbaron: Curious why it's not syntax error and drop. That was one of
          Rune's options
  astearns: Would you like more time to consider and consult?
  dbaron: If nobody else thinks it makes sense okay resolving. My
          intuition is if we don't know how to process it shouldn't be
  astearns: We can process fine. Slightly less surprising the rules
            don't disappear
  dbaron: Maybe. Okay
  astearns: We are at time. Prop: Property and fontface rules always
            work in an @container rule
  miriam: Prior art was for @layer where @layer has no effect on name
          defining rules
  astearns: Anyone want to chew on this more?

  RESOLVED: Property and fontface rules always work in an @container

  astearns: Thanks for calling in for the first meeting of the year.
            We'll talk for the hour next week and have a longer call
            later in the month
Received on Thursday, 6 January 2022 11:27:37 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:20 UTC