- From: Dael Jackson <daelcss@gmail.com>
- Date: Tue, 24 Jul 2018 19:51:10 -0400
- To: www-style@w3.org
=========================================
These are the official CSSWG minutes.
Unless you're correcting the minutes,
Please respond by starting a new thread
with an appropriate subject line.
=========================================
ResizeObserver
--------------
- 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)
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/sydney-2018#schedule
Present:
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
ResizeObserver
==============
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
block
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
loop
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,
right?
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
inconvenient
ericwilligers: Isn't purpose of contain that author provides the
size?
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
forgotten
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?
Whiteboard:
https://lists.w3.org/Archives/Public/www-archive/2018Jul/att-0004/IMG_2716.JPG
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
margins/borders/padding
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
fault
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
resolution
florian: Clarification, what if there are multiple empty tracks, and
all of them are auto, and the sum is too small, which do you
grow?
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*
https://lists.w3.org/Archives/Public/www-archive/2018Jul/att-0005/IMG_2717.JPG
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
margins/borders/padding.
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
side
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
tracks
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?
<silence>
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