W3C home > Mailing lists > Public > www-style@w3.org > July 2018

[CSSWG] Minutes Sydney F2F 2018-07-05 Part I: ResizeObserver, CSS Contain, CSS Grid [css-contain] [css-grid]

From: Dael Jackson <daelcss@gmail.com>
Date: Tue, 24 Jul 2018 19:51:10 -0400
Message-ID: <CADhPm3uin-jNGRSbyuUg_pLQ2Vs-pjFjrCZt2pJmXsz29YrAtw@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.


  - RESOLVED: Greg Whitworth will be an editor of resize observer
  - RESOLVED: the spec becomes inducted into CSS.
  - RESOLVED: ResizeObserver must handle fragmented boxes. (WICG
              Issue #54)
  - RESOLVED: ResizeObserver must handle observing changes to border
              box and changes to content box (which could change even
if the border box doesn't) (WICG Issue #54)

CSS Contain

  - RESOLVED: No change [to how specified column/row sizes on grid
              containers should contribute to contain:size], add a
              note. (Issue #2804)
  - RESOLVED: Contain is not animatable. (Issue #2737)
  - RESOLVED: will-change is not animatable. (Issue #2737)

CSS Grid

  - RESOLVED: The margins/borders/padding of the subgrid plus the items
              in the first column that contains items are attached
              together to create a fake item which spans those columns
              in order to reserve space for the subgrid‘s
              margins/borders/padding. (Issue #2592)
  - RESOLVED: Keep the rule in the spec which treats subgrid as an
              empty item which spans all of its spanned tracks (in
              combination with the previous resolution). (Issue #2592)


Agenda: https://wiki.csswg.org/planning/sydney-2018#schedule

  Rachel Andrew, Invited Expert
  Rossen Atanassov, Microsoft
  Tab Atkins, Google
  L. David Baron, Mozilla
  Brian Birtles, Mozilla
  Tantek Çelik, Mozilla
  Dave Cramer, Hachette Livre
  Emil A Eklund, Google
  Elika J Etemad, Invited Expert
  Jihye Hong, LGE
  Koji Ishii, Google
  Dean Jackson, Apple
  Ian Kilpatrick, Google
  Chris Lilley, W3C
  Peter Linss, Invited Expert
  Myles C. Maxfield, Apple
  Cameron McCormack, Mozilla
  Xidorn Quan, Mozilla
  Francois REMY, Microsoft
  Florian Rivoal, Invited Expert
  Hiroshi Sakakibara, BPS
  Alan Stearns, Adobe
  Shane Stephens, Google
  Lea Verou, Invited Expert
  Philip Walton, Google
  Eric Willigers, Google

Scribe: myles


Move from WICG

  <astearns> https://wicg.github.io/ResizeObserver/
  frremy: I don’t know if there is an issue for the first topic, but
          the first one is we would like to see the spec move from
          the WICG to a WG
  frremy: It seems it’s already implemented and shipped in Chrome.
          It would be a good idea to move it here.
  iank: If we want to keep Aleks as an editor, I spoke with him before
        this meeting, and it’s okay, but he won’t attend the calls.
        It would be a similar thing with scrolling stuff and things
        like that.

  Rossen: Any other opnions?
  Rossen: Any objections?
  tantek: Who is the editor?
  iank: Aleks Totic
  Rossen: Who wants to help Aleks?
  frremy: Greg can do it.
  Rossen: No objection? Resolved.

  RESOLVED: Greg Whitworth will be an editor of resize observer AND
            the spec becomes inducted into CSS

The bounding rectangle of the resize observer
  github: https://github.com/WICG/ResizeObserver/issues/54#issuecomment-398139676

  frremy: Greg tried to make a prototype using ResizeObserver, and
          he found that the rectangle that’s being used for the
          resize observer is not the same rect as is used everywhere
          else. Everywhere else in CSS, we use the border box, but
          resize observer uses a different rectangle. That was
          confusing because it wasn’t clear at the beginning what
          percentages refer to
  frremy: The issue was identified by dbaron
  frremy: Greg wants to bring more attention to it.
          Proposal: Make the rectangle used in resize observer equal
          to the border box

  iank: We thought about reporting the border box size, but we found
        problems quickly - people would immediately try to change the
        width or height of the same element, and things like this,
        and it led to immediately resize observer loop in many cases.
        The whole purpose of resize observer is to change your
        children in response to changing your own size, so we use the
        content rect idea. Was Greg trying to poly element queries?
  frremy: If you get a rectangle that’s not the border box, you have
          to use the CSSOM to do it, etc.
  philipwalton: In my experience, it’s different. The API required me
                to use a container element in every situation that I
                wanted to use it. This made me use 2x the number of
                elements than I naturally wanted to use.
  iank: This also lets you avoid writing an element query that causes
        an infinite loop
  philipwalton: But I already got into infinite loop. My example:
                In a small rect, there is padding, which would change
                as the box increases, which changes the content size
                but not the border box size.

  plinss: I have an issue that the API only has one rect. You don’t
          take into account that elements fragment. This annoys me
          because it is yet another APIs that doesn’t respect that
          we have a layout model.

  frremy: Is there a restriction on what kinds of elements can work
          with ResizeObserver?
  iank: Yes. ResizeObserver doesn’t work on inline elements
  plinss: Or fragmented elements
  iank: Yep
  frremy: Most of the use cases I’ve seen are when you create
          components that won’t fragment.
  Rossen: But peter’s problem is still relevant
  plinss: Sometimes authors don’t expect fragmentation.
  Rossen: Can we open a separate issue about fragmentation?
  Rossen: Let’s go back to the current issue
  plinss: But this is related. If we updated the API to work with
          fragmentation, it would work better. You can report all
          the rectangles instead just one.
  iank: The one thing with this API is that all the values get
        snapshotted before the observations get dispatched.
  iank: We can add more things, but be aware that there is additional
        work for the engine
  iank: We can add arguments to the observer
  plinss: Sure

  frremy: The content rect and the border box, there is simple math
          to go from one to the other. The issue is the math is simple,
          but getting the values from JS is complex. You need to use
          getComputedStyle(), parse the string, etc. The browsers can
          use an additional property that can be used, and it can be
          computed on demand.
  iank: But it would flush a layout, which is bad. If you have multiple
        observers attached, and in the resize observer you do a bunch
        of style manipulations, and when the second observer queries
        for these values. We want to avoid having the second one get
        the new values because that requires recompiling style.
  iank: One design is to report the content size, but also report the
        border scroll bar padding insets as well. This will give a
        little nudge to developers.

Scribe: fantasai

  philipwalton: I'm not entirely convinced that we should be
                recommending developers care about the content size
  philipwalton: Primary use case is I have some component, and it's
                taking up all the available space in the containing
  philipwalton: Any time containing box changes, component will
                change, and
  philipwalton: I think that's the use case most ppl are talking about
  iank: Use cases that we were solving for, in addition, you really
        wanted to know the content size
  iank: If you follow the content size recommendation, it's very hard
        to get into the loop-exceeded error case

  dbaron: It seems like which of the boxes is more likely to be stable
          is function of whether size is intrinsic or extrinsic
  dbaron: If size is coming from content, then inner box is most
          stable; if size is coming from outside, then outer box is
          most stable

  Rossen: The current model is to continue with content box and add
          additional insets for padding/border?

  philipwalton: Two things to consider. What is my border box size?
                Am I getting callbacks when border box changes?
  philipwalton: I wanted callbacks only when border box changes
  philipwalton: If I only get notice for content box, can calculate
                it by caching, wouldn't be ideal
  philipwalton: But there were other cases where content box changes
                but border box doesn't, and then I get into infinite
  frremy: Another proposal would be to have a flag that says which box
          you care about
  * fantasai thinks that makes the most sense

  Rossen: Do we agree that API should reflect fragmentation?
  iank: That's a separate flag
  Rossen: What do you mean by flag?
  Rossen: You either get more than one rect or not. There's no flag
  Rossen: This is a pure addition to the current API
  Rossen: You may get more than one rectangle in case of fragmentation
  iank: You'd need more than one property ...
  iank: You could overload to say it accepts an array
  frremy: That would be a breaking change for every existing impl
  myles: If you make it return an array even when only one rect, then
         that's breaking change
  myles: But if you only return an array if more than one, then it
         won't break it
  frremy: APIs that return either an object or an array of an object
          are very confusing. These types are not the same.
  iank: Chrome is shipping

  florian: If there are 2 separate methods, one that returns an array
           and one that returns a single item, what does the single
           one return in case of fragmentation?
  Rossen: Bounding rect
  frremy: But that doesn't make sense for content box
  fantasai: Sure it does
  Rossen: Just use content boxes instead of border boxes
  frremy: I think proposal is get a flag that returns different things
  frremy: Ask for border box, or content box
  florian: Flags for do you want the bounding box, fragment array,
           first fragment, whatever?

  myles: ...
  iank: Only gets called when that content changes, or goes from
        appears and disappears
  myles: So you can have a situation when border box changes but you
         never get called, which is kindof defeating the purpose,
  myles: Flag wouldn't just change what gets returned, but also when
         callback gets called

  Rossen: Feedback from room is pretty clear
  Rossen: We need to have affordances for fragmentation
  Rossen: And for border box vs content box
  frremy: I think we agree with that, but we don't want to resolve on
          exact method
  Rossen: Would the observer be modified if the border box is not
          changing but content box is changing ?
  Rossen: And vice versa?
  iank: Currently we ...
  Rossen: When you add these
  iank: Yes
  iank: Today you should get ...
  iank: a little bit of padding
  iank: Content rect also reports top left of padding, in case you
        need abspos.....

  RESOLVED: ResizeObserver must handle fragmented boxes
  RESOLVED: ResizeObserver must handle observing changes to border box
            and changes to content box (which could change even if the
            border box doesn't)

CSS Contain

fixed grid column/row should contribute to contain:size
  github: https://github.com/w3c/csswg-drafts/issues/2804

  florian: When you apply size containment, we first lay out the
           element as if it's empty
  florian: And then put content into it
  florian: You're expected to give it a size
  florian: Question: for a grid container, which has rows and columns
           of fixed size
  florian: Even if element was empty, it would have a non-zero size
  florian: That's not how it's implemented atm
  florian: Currently assumed to have zero size, even if 6 100px columns
  florian: We have same similar issue with multicol
  florian: Spec currently say that empty columns and grid rows should
           help auto-sized size-contained element not be zero

  florian: But #1 chrome isn't doing that and #2 fixing in inline
           direction, but in block direction wouldn't be easy
  florian: Because no codepath to get vertical intrinsic size without
           doing layout
  TabAtkins: I don't care a ton, if really problematic, but in general
             the idea is to "lay out as if empty" and for a grid, that
             means we make it the height of the fixed-height rows
  florian: If we remove it nothing is destroyed, just maybe a bit
  ericwilligers: Isn't purpose of contain that author provides the
  florian: Author gave us the info, though 6 100px columns plus a gap,
           simple math the author could do, by we could also do
  TabAtkins: min-height is handled, why not sum of row heights
  florian: On Chrome side, Igalia would be fixing it. They would do it,
           but want to make sure we want it.
  heycam: In the original filed issue, Morgan suggested that it should
          work. So I think that would be Mozilla's position
  florian: I can add a note to the spec, to make sure it's not

  RESOLVED: No change, add a note.

Contain may not want to be animatable
  github: https://github.com/w3c/csswg-drafts/issues/2737

  birtles: Since then I spoke to someone working on optimizations that
           key off contain
  birtles: He agreed that unless there's a compelling use case to make
           contain animatable, safest to make it not animatable for now
  TabAtkins: I'm fine with that
  florian: Currently discrete, want to change to none
  fantasai: +1 from me
  dbaron: Does this match display?
  florian: Yeah, that's the point

  RESOLVED: Contain is not animatable

  ericwilligers: How about will-change?
  TabAtkins: Animating will-change is probably wrong.
  fantasai: It could impact your internal structures, so probably good
            to make not animatable
  birtles: Spec says that transform animations cause a stacking context
           during the entire delay phase of the animation; if you apply
           that to will-change as well
  birtles: If your transition has will-change in it, then stacking
           contexts might change...[missed]
  [birtles also mentioned the use case of setting 'will-change' a
      second before the animation actually starts doing things]
  shane: I agree with your argument
  birtles: We might be able to fix that layer, but for now seems better
           to make it not animatable for now

  RESOLVED: will-change is not animatable

CSS Display

  [DoC is a bit out of date, at
https://drafts.csswg.org/css-display-3/issues-wd-2017 ]
  [Afaict just the one issue is open]

CSS Grid

subgrid border/padding/margin
  github: https://github.com/w3c/csswg-drafts/issues/2592
  scribe: myles

  fantasai: This is about handling margins/borders/padding
            of the subgrid itself
  fantasai: The previous rule we had didn’t work if your subgrid
            had some empty columns and things. We wanted to fix it.
            2 solutions, it's about how strictly you tie the BPM
            to the outermost column when the columns are missing
            on the edges.

  TabAtkins: Our current approach: the sub grid and its items are
             laid out in the parent grid independently but we take
             the sub grids margins/borders/padding and apply the
             sum of their widths as magical extra margin on the
             appropriate edges of sub grid items that are in the
             first or last tracks
  TabAtkins: So that they position themselves naturally as if they
             were inside the subgrid
  fantasai: That also takes into account the subgrid itself.

  fantasai: The problem is when there is no item on the side,
            we cannot attach the extra BPM to an item so that
            it takes up space.
  fantasai: Then everything collapses away.
  fantasai: There are two approaches we could take to fix this:
            1) Strictly account for the margins and borders and
               padding in the track of at subgrid’s edge so even
               if the track is empty then we have a fake item
               that has the margins/borders/padding of the subgrid
               attached to it.
  fantasai: It reserves space for the margins/borders/padding and
            requires the subgrid’s margins/borders/padding to be
            accounted for in this specific column
  fantasai: 2) Make sure the combination of tracks from the last
               track with an item in it up to the edge track has
               enough space for the margins/borders/padding of
               the subgrid

  fantasai: Let’s say the subgrid has a really thick border.
            You could do *draws picture*. But in the other approach
            we would have to bump out the column to make it wider
            to fit the margins/borders/padding. And then this track
            would be fully empty and we’ve got our item here
  fantasai: The question: Do we want to use the tracks other than
            the last track to accommodate the margins/padding/borders
            or do we want to force the margins/borders/padding to be
            accounted for on the outermost track?
    The green represents the subgrid's margin/border/padding.
    3-span subgrid, outer tracks are auto.
    The leftmost track of the subgrid is sized to fit the
    subgrid-external item in it. Once the subgrid's margin/padding --
    which is wider than that item -- is considered, however, we have
    to decide whether it is allowed to intrude into the next track (
    which happens to be empty) or if it must be accounted for in the
    leftmost track, thus increasing its size.

  Rossen: We discussed internally. Our idea: the one where
          margins/borders/padding of the subgrid is accounted for
          in addition to whatever the items are in the first and
          last columns of the span of the subgrid. In other words,
          the subgrid acts as an item itself that spans all of the
          other items and the only thing that contributes is its
  fantasai: That was the original model, and it wasn't enough
            because if you treat it as an empty thing which spans
            all of them, then the margins/borders/padding...
            like let’s say we have 2 items, the margins/borders/padding
            could be handled, to be treated as a spanning item,
            so we could have margins/padding/borders here and here,
            and we don’t have enough space
  Rossen: When I said spanning, that was poorly chosen. I meant
          like a grid item spanning.
  fantasai: We are treating margins/padding/borders as an item.
            The spec said that margins/borders/padding was an item
            wherever it ended up, but that doesn’t work if there
            are empty columns.
  fantasai: Two alternatives: 1) Treat the margins/borders/padding
            as being a grid item in the very last column only, or
            treat it as a grid item in all of the empty columns up
            until the last item
  florian: In most use cases, you don’t have thick margins/borders/
           padding, so most of the time the two will be the same
  florian: But some time it might be and then solution 2 is nicer
           but more complicated
  fantasai: It’s not more difficult, just different.

  frremy: Option 1 is not a good option because if the first one has
          as size of 5px and the border is 1px, you don’t want the
          track to change the size of the grid overall.
  frremy: I implemented just like Rossen said
  fantasai: If it’s a fixed size, you overflow, whatever, that’s your
  frremy: But in the example, you still want the remaining 10px
          you can’t fit in the first one to fit
  frremy: So I did exactly what Rossen mentioned, the grid was doing
          a layout itself with the layout of the inner item.
  frremy: In think you never end up in the case where the column is
          too small
  fantasai: The question we need to resolve is whether margins/borders/
            padding can intrude into a column that is not the last
            column it spans
  Rossen: Agree

  Rossen: What do people think?
  TabAtkins: *head nod*
  Rossen: Proposal: The sub grid will afford for its margins/borders/
          padding by contributing its margins/borders/padding to
          either the last column if it happens to be auto, or any
          other auto column of the main grid.
  fantasai: That’s way more complicated. Because then you can say,
            let’s say all the columns are auto, then this subgrid
            could fit within, if we allow it to intrude into this
            column which is empty in the subgrid, then the margins/
            borders/padding could be accommodated without changing the
            size of the column. But if we did what you said, then the
            column would have to be pushed out.
  Rossen: Right
  Rossen: This is slightly more complex.
  fantasai: The proposal in the issue is the margins/borders/padding
            of the subgrid has to be accommodated in the subgrid after
            the item it appears in
  Rossen: This is the first option, right?
  fantasai: yes
  frremy: This means you account for the margins/borders/padding
          independently on the four sides
  fantasai: Yes

  Rossen: Minimally account for the margins/borders/padding by making
          sure that the combination of tracks from the last track with
          an item in it to the edge of the subgrid has enough space to
          accommodate the subgrid's margins/borders/padding
  Rossen: That is a worthy resolution, but this is the proposed
  florian: Clarification, what if there are multiple empty tracks, and
           all of them are auto, and the sum is too small, which do you
  fantasai: You attach it to the last item.
  frremy: In the case where all the columns except the last one are
          fixed size .... so you do each side and the total
  fantasai: So you have a subgrid in the middle, and the subgrid is
            however wide and this item is in here and we have a lot
            of columns. When we try to do all the sizing, the subgrid
            is going to contribute its items for sizing. This one
            does not get margins/borders/padding attached because
            it’s not on the edge. But then we need to account for
            subgrid’s margins/borders/padding, so we take this last
            item, and we attach to its edge the margins/borders/padding
            of this subgrid item and treat this resulting hypothetical
            item as an item which spans from its original column to the
            edge of the subgrid
  frremy: So we will still do a big one with all of the subrgrid
  frremy: because if all the columns before are fixed size, you still
          may want to increase the middle column
  fantasai: But this guy can’t move, This item can’t leak into this
            column. So this column has to accommodate the item and
            the subgrid’s margins/borders/padding.

  fantasai: *draws on whiteboard*
  frremy: *draws on whiteboard*
  fantasai: The left side margins/borders/padding can’t be accommodated
            here, and it will end up overflowing.
  frremy: The way I wrote it, would be this would be there.
  fantasai: The content edge of the subgrid cannot be further to the
            right of the margin edge of the item.
  frremy: But if you have 0 items, you have different behavior than
          if you have 1 item
  fantasai: But that’s the point. The item has to say in the column
            in which its assigned. It can’t move
  frremy: I would prefer it overflows the subgrid
  frremy: The subgrid fits, but the item overflows.
  frremy: I would do left side right side up side down side
  fantasai: I think that’s weird
  frremy: But it’s better because it’s consistent
  frremy: Most cases will do the same thing, it’s fine. Your track
          will not change size when you add an item.
  fantasai: I see your argument, but I still think it’s super weird
  Rossen: But the case you’re describing is weird
  fantasai: frremy: *repeats the arguments*
  fantasai: Okay fine
  fantasai: We’ll figure it out

  Rossen: Let’s capture this in a resolution
  fantasai: The case we’re talking about is when all the tracks of the
            subgrid from the edge of the subgrid all the way through
            and including the first track with an item are fixed size,
            and a track on the other side of the item is auto sized,
            then if the margins/borders/padding of the subgrid is too
            big to fit within the fixed set of tracks, then it will
            cause an increase in the size of the auto tracks anywhere
            on the other side, and will thus paint underneath the item
            and into that auto track rather than being attached to the
            outside of the item and overflowing to the left
  florian: So if that doesn’t fit there, but it fits there, you go
           underneath, but you don’t increase the size. But if you have
           to go beyond, then you increase the size to fit it there
  fantasai: That seems okay.
  Rossen: This is more or less what I was suggesting
  frremy: If you have a border you want the border not to be included
          in the column of the item. The border should be outside.
  fantasai: That’s great, let’s resolve
  fantasai: We need 2 resolutions.

  fantasai: Proposed resolution: The margins/borders/padding of the
            subgrid plus the items in the first column that contains
            items are attached together to create a fake item which
            spans those columns in order to reserve space for the
            subgrid‘s margins/borders/padding.
  Rossen: Did anyone follow that proposed resolution? Any objections?
  <florian> +1
  fantasai: Proposed resolution: The margins/borders/padding of the
            subgrid plus the items in the first column that contains
            items are attached together to create a fake item which
            spans those columns in order to reserve space for the
            subgrid‘s margins/borders/padding.

  RESOLVED: The margins/borders/padding of the subgrid plus the items
            in the first column that contains items are attached
            together to create a fake item which spans those columns
            in order to reserve space for the subgrid‘s

  fantasai: In addition, to accommodate the situations where the
            columns of the above item are all fixed, we do a
            calculation which allows that margins/borders/padding
            to bleed through the first column with all the items
            in it and potentially expand an auto column on the other
  frremy: Proposal: Keep what’s in the spec and add the previous
          resolution. Don’t replace what’s in the spec.
  fantasai: Cool

  fantasai: Resolution: Keep the rule in the spec which treats
            subgrid as an empty item which spans all of its spanned
  fantasai: Resolution: Keep the rule in the spec which treats subgrid
            as an empty item which spans all of its spanned tracks,
            in addition
  Rossen: Any objections?

  RESOLVED: Keep the rule in the spec which treats subgrid as an
            empty item which spans all of its spanned tracks, in
            addition to the above-resolved calculation
Received on Tuesday, 24 July 2018 23:52:25 UTC

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