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

[CSSWG] Minutes Telecon 2022-11-02 [css-align] [css-multicol] [css-grid-2] [css-flexbox] [css-contain] [css-view-transitions]

From: Dael Jackson <daelcss@gmail.com>
Date: Thu, 3 Nov 2022 18:54:19 -0400
Message-ID: <CADhPm3uEcpMfjC8GfAkxwY6gBc+COAfZ5SRb29vw0iGhgt-mVA@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.


  - The next long-form meeting will be November 30th starting a few
      hours before the normal meeting time.

CSS Align & Multicol

  - RESOLVED: We define the first baseline as the highest baseline in
              all the columns and spanners of the multicol (Issue
              #7856: First baseline of a multicol)
  - Text will be added to make sure we define that relpos doesn't
      affect baseline alignment

CSS Grid

  - RESOLVED: Change the spec to simplify this sizing and figure out
              what tests we need (Issue #7465: How to properly
              accommodate margin/border/padding of a subgrid with no
              item on the edges)

CSS Align

  - RESOLVED: Take the changes listed in
              (Issue #7612: *-items properties might need to resolve
              directions early)
  - RESOLVED: Use the writing mode of the parent's formatting context
              for staticpos (Issue #7599: align-self / justify-self on
              abspos elements isn't back compatible?)
  - RESOLVED: Align justify axis of non staticpos use writing mode of
              their containing block (Issue #7599)

CSS Flexbox

  - The recommendation for issue #3052 (Investigate applying
      align-content to single-line flex containers) is to close no
      change based on use counter data from Chromium. Before resolving
      to close fantasai will verify that accepting the proposal would
      cause a different to a sample of the sites found in the use

CSS Contain

  - RESOLVED: Add a SHOULD requirement for considering the filter
              effect extent and interaction with UA margin (Issue
              #7711: filter effects and "relevant to the user")

View Transitions

  - RESOLVED: Accept the proposed resolutions for items 1, 2, 3, 5, & 6
             (Issue #7960: CSS selector keywords)
      - Property used on DOM elements to tag them for independent
          animations: view-transition-name.
      - The pseudo-element which directly originates from the root
          element and is the ancestor for all container elements:
      - The pseudo-element which animates the size and position for
          tagged elements: html::view-transition-group(*)
      - The pseudo-element which displays snapshot from the old DOM
          element: html::view-transition-old(*)
      - The pseudo-element which displays snapshot from the new DOM
          element: html::view-transition-new(*)


Agenda: https://lists.w3.org/Archives/Public/www-style/2022Nov/0000.html

  David Baron
  Elika Etemad
  Simon Fraser
  Daniel Holbert
  Dael Jackson
  Ian Kilpatrick
  Vladimir Levin
  Alan Stearns
  Miriam Suzanne
  Eric Willigers
  Matt Woodrow

  Yehonatan Daniv
  Jonathan Kew
  Bramus Van Damme
  Lea Verou
  Sebastian Zartner

Chair: astearns

Scribe: dael


  astearns: On fantasai rec we're going to skip items 5 & 7. Any other
  astearns: chris reminded us that our charter is up for a vote
  astearns: Please ask your AC rep to go vote. We need some engagement
            there to keep the lights on
  astearns: Please everyone on the call or reading the minutes go bug
            your rep

  astearns: Second thing is another long form meeting Nov 30. A couple
            extra hours before the regular time.
  <@fantasai> ->
  astearns: I'll set up a calendar invite and we'll get a meet link soon

CSS Align & Multicol

First baseline of a multicol
  github: https://github.com/w3c/csswg-drafts/issues/7856

  iank: Basically currently the spec says to take the first baseline
        from the first column
  iank: This has a couple of poor side effects
  iank: Came up while Morton reviewed new last baseline behavior
  iank: What can happen now is that if there is no content that
        produces a baseline in the first column it has no first
        baseline but might have last from another column
  iank: Two potential solutions. First is mirror last baseline and take
        highest of all content
  iank: Second is take the first baseline of the first non-empty thing.
        First thing that produces a baseline

  astearns: And we are taking the lowest baseline for last baseline
            because it's often the case the first column has a much
            lower baseline
  iank: Correct. Not always, quite common for it to come from later
  astearns: For symmetry taking highest baseline seems like might be
            better. No strong opinion
  dholbert: I was going to say roughly same. Like simplicity of first
            that exists but asymmetry unfortunate
  iank: Pros and cons. First baseline if you're trying to align it will
        roughly give you always first line on first column. Highest if
        you switch to smaller font size in another column that would be
        first highest. So pros and cons. Happy with either
  dholbert: Do we generally have symmetry between first and last
            determined in other layout modes?
  iank: We broadly have symmetry.
  iank: Ignoring some convoluted table case. But wouldn't be an issue
        to break here. We found this because writing last baseline
        logic, noticed the asymmetry and went that's weird

  astearns: In terms of what effect you want to have, presumably you're
            trying to align some other element with first baseline.
            First column will often be taller in a heading. If we take
            first baseline of column with a baseline the thing outside
            will align with the title. If we take highest it will align
            with first body text. I can see either being useful
  fantasai: I think you described what is the most likely scenarios
  fantasai: We have an issue open on selecting which element you want
            to take baseline on. If we went highest and you wanted
            first you would be able to request that. That might be a
            reason to take highest
  iank: Fine with that
  <@miriam> I like that approach
  astearns: And that way we get symmetry.
  fantasai: We haven't worked out how this interacts with splitting
            element but can define to work

  astearns: Proposal: We define the first baseline as the highest
            baseline in all the columns and spanners of the multicol
  astearns: Objections?

  dholbert: This is symmetrically defined with last baseline. Does that
            take relpos into account?
  iank: It does not. Out of flow it does not and baselines are
  dholbert: No objection. Just wanted to check
  astearns: Good to check we're defining as in-flow
  iank: Probably don't have language but all engines are same

  RESOLVED: We define the first baseline as the highest baseline in all
            the columns and spanners of the multicol

  ACTION: fantasai to make sure we define that relpos doesn't affect
          baseline alignment

CSS Grid 2

How to properly accommodate margin/border/padding of a subgrid with
    no item on the edges
  github: https://github.com/w3c/csswg-drafts/issues/7465#issuecomment-1265913276

  astearns: Can you take fantasai?
  fantasai: Yep. For subgrids layout we have a bunch of rules for
            laying out stuff within a subgrid as part of parent
  fantasai: We figure out which columns and rows items in subgrid
            assigned to and layout as if in parent
  fantasai: Difference is how we handle margins and padding. Figure out
            total amount of margin padding border for items at edge of
            subgrid and add as magic margin to inflate auto-sized
  fantasai: When you layout in grid takes into account extra margin and
            padding I should stay away from
  fantasai: In order to do that accurately we have a bunch of rules to
            insert hypothetical items at edge of subgrid to make sure
            even if it's empty it's sized
  fantasai: Spec rules and browser impl are different. We had a complex
            rule to insert item with span of one then with span of two
            and however many we need to cover the spans and make sure
            there's enough space
  fantasai: Problem is that it creates a bunch of space and when you
            put items down ones in second column don't have magic
            margin. Doesn't work out to match up in that way
  fantasai: Browsers don't do complex spanning. Only put items in first
            and last track. If you have fixed width 20px first track
            and second is auto and subgrid has 40px of padding the
            padding crosses into second track and items don't know
            about it.
  fantasai: If we wanted to figure that out it's quite complicated to
            figure out the margin you want to add. None of the browsers
            are doing it and not sure it's necessary to do the complex
  fantasai: Question for WG is do we simplify spec down to only look at
            first and last or investigate what we can do to try and
            make it work for inner tracks?
  fantasai: Our suggestion is simplify down and see what happens, but
            open for questions and comments

  astearns: Test cases we removed because missing spec text. Would
            those become valid?
  fantasai: Don't know. I think whatever we do we'll want the test
            cases but maybe different references

  iank: I support removing hypothetical item concept. I believe MS
        folks studied this and super hard to get correct
  mattwoodrow: Also support simplifying it. I spent a bit of time
               trying to figure out how to impl and very complex when
               you nest grids
  fantasai: Will still need some margin padding added, it's just not
            leaked to multiple tracks

  astearns: Is there interop in browsers? Or are we coming up with
            something that might need bug fixes?
  iank: From what I've seen broadly speaking subgrid is lightly tested
        in some areas so wouldn't shock if there are subtle differences
        between browsers
  fantasai: Either way should make sure have enough tests. Might be
            some bug fixes but closer to interop on simplified version
  astearns: Proposal: Change the spec to simplify this sizing and
            figure out what tests we need
  astearns: Objections?

  RESOLVED: Change the spec to simplify this sizing and figure out what
            tests we need

CSS Align

*-items properties might need to resolve directions early
  github: https://github.com/w3c/csswg-drafts/issues/7612#issuecomment-1230963091

  fantasai: There was an issue raised against how we interpret various
            items on abspos
  fantasai: Alignment spec says when you abspos a box with specific
            offsets alignment prop apply in inset rectangle.
  fantasai: You can stretch, center, left align in inset box.
  fantasai: None is impl yet, but that was the direction
  fantasai: What we were saying is when you abspos the box you're in a
            formatting context that's not your parent's that you're out
            of flow from
  fantasai: Spec that align items property of parent don't effect your
            alignment as an abspos
  fantasai: Problem we ran into is when staticpos there's existing
            behavior where alignment prop do effect your position
  fantasai: Seems like we're at the summary we linked to
  <@fantasai> https://github.com/w3c/csswg-drafts/issues/7612#issuecomment-1230963091
  fantasai: If you are abspos and not staticpos the align- and
            justify-self properties align you in inset box. If you're
            static they align you in staticpos rectangle
  fantasai: If you're align or justify-self is auto and you're not
            staticpos you ignore parent. If you are staticpos we look
            at -items of your parent and use alignment based on that
  fantasai: [reads out comment]
  fantasai: That's my understanding of where we're at. Bringing to WG
            to ask for review and decide if that makes sense

  iank: One thing good to clarify is what writing mode does
        align-self:start operate in when insets are set?
  fantasai: I think that's the next issue
  iank: This is just about staticpos rectangle?
  fantasai: That's the focus
  iank: Proposal is staticpos rect operates in writing mode direction
        of parent?
  fantasai: Yeah. I think it would need to for flex stuff follow parent
            formatting context
  iank: Okay. So if it's staticpos it's within the writing mode of the
        parent. I think that's probably fine.

  iank: Side note- do we have an open issue for when staticpos
        rectangle is fragmented?
  fantasai: I don't believe we do I think fragment like whatever it's
            derived from
  iank: There's complexities I can add to an issue

  astearns: What we're talking about would apply to current grid and
            flex children but the rest is waiting on impl for other
            formatting context?
  iank: As far as I understand this is broadly status quo for grid and
  fantasai: I believe so. Might be clarifying for grid but this is for
  astearns: As much as I followed it seems good to me
  astearns: Other comments?

  astearns: Shall we resolve on taking the changes in
  astearns: Objections?

  RESOLVED: Take the changes listed in

align-self / justify-self on abspos elements isn't back compatible?
  github: https://github.com/w3c/csswg-drafts/issues/7599

  fantasai: This is how do we resolve the axis it operates in. When
            staticpos we use axis as defined by the formatting context,
            the parent formatting context
  fantasai: I think we can resolve on that and then address what to do
            for non-staticpos
  astearns: Proposal: Use the writing mode of the parent's formatting
            context for staticpos
  astearns: Sounds like that's what we need for web compat?
  iank: I don't have data but I would wager people are relying on this
        working as is
  astearns: Objections?

  RESOLVED: Use the writing mode of the parent's formatting context for

  fantasai: Follow-up for non staticpos. Spec says for abspos you
            resolve justify and align based on containing block's
            writing mode. Rather than checking parent. Reason is
            pulling from deeper context and trying to layout with other
            things should use same reference axis
  fantasai: That's why we defined it that way. Is that fine or do
            something different?
  iank: Broadly fine. For clarification if you've got a line item on
        containing block does that effect out of flow element?
  fantasai: If out of flow is not staticpos it does not look at align
            items on anything
  iank: Makes sense
  iank: The quirk that falls out is align-self:center if you're
        staticpos in one axis and not in the other axis it will effect
        both axis
  fantasai: Yeah. I think it's a little weird but anything else is
            weirder in more common cases
  iank: Yeah, fine with that.
  fantasai: Align justify axis of non staticpos use writing mode of
            their containing block

  RESOLVED: Align justify axis of non staticpos use writing mode of
            their containing block

  iank: Clarification- when doing this you need to say staticpos in a
        particular axis
  fantasai: Yeah

CSS Flexbox

Investigate applying align-content to single-line flex containers
  Proposed Resolution: close this as Rejected due to web compat
  github: https://github.com/w3c/csswg-drafts/issues/3052#issuecomment-1226112918

  astearns: Proposed resoution is no
  fantasai: When flex was released we defined align content only
            applies to multiline. Aligns the flex lines. Could apply to
            single line in which case you could top align a bunch of
            flex items and then center align the line
  fantasai: Seems there are enough web pages expecting it to not have
            an effect that we could not change based on chrome data. We
            think we can't fix this and should add to list of mistakes

  iank: I looked last week quickly at use counter. It will over-count
        potentially. But it's high enough that there are sites that
        will rely on this so I'm fine. Could do a sample of sites but
        it's fine
  astearns: If you're worried about over-counting by an order of
  iank: Even if it is it's a large number of sites
  fantasai: Yeah. I think it's unfortunate but we may have to live with
            it. Curious to know what's being over-counted and if
            use-counter could tweak
  iank: Not easily. Would have to run the scenario where not stretching
        items to container which is not easy. That's how I thin it's
        over-counting. Would need to layout twice.

  iank: I think way forward to investigate is look at sites and see
        which flexboxes have this and if they would change
  fantasai: Is there a way to get a sample of the list?
  iank: Go to the issue on the chrome status page. Below the graph
        there will be a list of urls that triggered the counter
  fantasai: I'd be down to check the first 20 or something and see
  astearns: If you want to do that it would be great. Would you like to
            keep issue open until you do it? Or resolve?
  fantasai: Sure, I'll need something to track.
  fantasai: So just load these pages and look at it?
  iank: Yeah, so it will be...it's by origin. What I find when doing
        this is if you hit the home page and have some JS to query
        elements more or less the home page will have it.
  <iank> https://www.chromestatus.com/metrics/feature/timeline/popularity/4057
  fantasai: If I find most of these don't hit a change we can revisit.
            If not I'll close out
  astearns: Okay, leaving this as is

  ACTION fantasai look at effect this
         would have on actual websites

CSS Contain

filter effects and "relevant to the user"
  github: https://github.com/w3c/csswg-drafts/issues/7711

  florian: Discussed similar for contain 1. Filter effects can be
           non-local. Like blur can draw from broader area to render
           what you want. Kind of defeats containment a bit. Was
           limited enough it was fine.
  florian: Similar issue on content-visibility:auto
  florian: Effects of content-visibility:auto change depending on if
           it's relevant to user. And one of the ways is if it's on
  florian: Spec has provision to not be considered if it's close to
           onscreen by a margin. Not clear how it's defined, but text
           anticipates it's a fixed size
  florian: For filter-effects there is no bound for how far reaching it
           might be. Very large is unusual but not impossible.
           Depending on how big the UA margin and filter effect are it
           might have a slightly offscreen element have an effect on
           the filter.
  florian: Probably negligible effect, but tiny is not none.
  florian: Suggest a small alert to spec that not only is the element
           relevant when it's close to onscreen but also that rendering
           it is necessary to do filter effects
  florian: It's probably a small error but need to decide if have small
           error or complete correct

  astearns: Long range filter effect will blink into existence once
            small threshold is hit?
  florian: Let's say you have bright red thing offscreen in
           content-visibility:auto and a blur. Without the change the
           element could come close enough that it should bleed red but
           doesn't impact filter. But instead it doesn't render until
           it gets close enough and then it blinks into sight

  dbaron: I wanted to say I think even if it may or may not be impl
          this way I think the spec should describe them additively.
          content-visibility being in range of the screen is you want
          it ready in case it scrolls on. I think better to describe
          additively but allow flexibility
  florian: Makes sense.
  dbaron: By additive if what you're trying to say is if scroll within
          50% of screen, but you want it to be if you're in 50% or
          relevant to some filter pixels onscreen...

  vmpstr: A little concerned about impl efficiency for this. In order
          to know about content under a stack of pixels will effect on
          screen doesn't seem trivial
  vmpstr: To run that on every scroll would be potentially slow. A
          little concerned about spec being strict on this
  dbaron: I don't think it should be strict. But I think most impl have
          this sort of code because needed for invalidation. But code
          can be conservative and make approximations
  vmpstr: Typically done in graphics stack. This would then cause us to
          go back to style when we detect it and decide you need to be
          rendered. I don't think at the time when intersectionObserver
          determines intersection I don't think we have good
          information about filter effects
  dbaron: That's certainly believable. I know Gecko code better then
          chromium though have forgotten some
  florian: When we resolved for containment we said it was easy enough
           to track. If we could allow something to spec to allow the
           correct and encourage. Maybe require is nice.
  florian: That said, number of cases where it's user important will be
           rare. Maybe okay to sacrifice accuracy
  dbaron: I think reasonable for should
  vmpstr: Agree with that

  astearns: Only concern I have is testing if it's a should
  florian: Hard to test regardless because not only is it a should
           there's UA defined fixed-size margin. How far offscreen you
           should be is hard

  astearns: Proposal: Add a SHOULD requirement for considering the
            filter effect extent and interaction with UA margin

  dbaron: One comment on testing. SVG filters has things easier to see
          than blur, but I don't think there are css versions
  iank: But can reference svg filters. But I think they'll make it more
  <@dbaron> (displacement map)
  florian: Interestingly that makes it more relevant. If it's just blur
           you don't get much color but displacement moving pixels you
           would see it
  astearns: Any concerns?

  RESOLVED: Add a SHOULD requirement for considering the filter effect
            extent and interaction with UA margin

View Transitions

CSS selector keywords
  github: https://github.com/w3c/csswg-drafts/issues/7960

  fantasai: This is about naming various pseudo elements for view
            transitions. Proposal for almost all in the issue. Could
            probably resolve all except 4
  astearns: Proposal is take proposals for items 1, 2, 3, 5, 6 in the
  astearns: Objections on those names?

  RESOLVED: Accept the proposed resolutions for items 1, 2, 3, 5, & 6

  fantasai: Item 4. view-transition-group we just accepted gives a
            grouping mechanism with a hierarchy. In item 4 it's a leaf
            with one or two images
  fantasai: It exists because need isolation for blending. Item 4 is to
            name that almost leaf grouping. List of names is the
            proposed ones
  fantasai: Names fall into two sets. Ones that include image, ones
            that have grouping word, and ones with both
  astearns: And this will not be used as much as rest?
  fantasai: Yes

  PaulG: Confirming these are pseudo element images snapshotted and
         will not hit ax tree or carry content?
  fantasai: Right
  PaulG: Thank you

  astearns: We're at time. We'll come back to the issue for the one
            remaining thing
  astearns: Thanks everybody for calling in. We'll talk next week
Received on Thursday, 3 November 2022 22:54:58 UTC

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