- From: Dael Jackson <daelcss@gmail.com>
- Date: Tue, 30 Aug 2022 19:32:13 -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.
=========================================
Shared Element Transitions
--------------------------
- RESOLVED: Add Shared Element Transitions as ED, with JakeA, khush,
and TabAtkins as editors (Issue #6464: Shared Element
Transitions)
Sizing
------
- RESOLVED: 0x0 is not special with regards to ResizeObserver or
contain-intrinsic-size (Issue #7539: How does 0x0 size
affect last remembered size?)
- RESOLVED: Replace ResizeObserver editors with Oriol and Emilio
- RESOLVED: At ResizeObserver time, forget an element's last
remembered size if it is currently out of the document
(Issue #7532: Should last remembered size be removed if
the element is removed from the document?)
- RESOLVED: "last remembered size" is tracked for the two axises
independently (in case of containment in one axis), and
can be invoked independently (with
contain-intrinsic-size:auto in one axis) (Issue #7529: Is
the last remembered size recorded if there is size
containment in a single axis?)
- RESOLVED: Clarify that setting contain-intrinsic-size to a size
overrides the content size, even if there is other sizing
info such as grid column widths (Issue #7520: Clarify
contain-intrinsic-size with multicolumn/grid)
- RESOLVED: contain-intrinsic-size size is used as the natural sizes
of replaced elements (but does not set the aspect ratio)
(Issue #7519: Clarify how contain-intrinsic-size affects
size containment algorithm)
- TabAtkins will also add some examples to the spec
- RESOLVED: If, when an element goes from not generating a principal
box to generating one, it does not have
contain-intrinsic-size:auto, forget any last remembered
size (Issue #7527: What happens with the last remembered
size if there is no principal box?)
- RESOLVED: If an element doesn't have a principal box, we do not
record a last remembered size (Issue #7527)
===== FULL MEETING MINUTES ======
Agenda: https://github.com/w3c/csswg-drafts/projects/30
Present:
Rachel Andrew, Google
Jake Archibald, Google
Rossen Atanassov, Microsoft
Tab Atkins, Google
David Baron, Google
Oriol Brufau, Igalia
Emilio Cobos Álvarez, Mozilla
Yehonatan Daniv, Wix.com
Elika J Etemad aka fantasai, Invited Expert
Robert Flack, Google
Simon Fraser, Apple
Daniel Holbert, Mozilla
Brian Kardell, Igalia
Jonathan Kew, Mozilla
Ian Kilpatrick, Google
Una Kravets, Google
Rune Lillesveen, Google
Chris Lilley, W3C
Vladimir Levin, Google
Francois REMY, Invited Expert
Florian Rivoal, Invited Expert
Cassondra Roberts, Adobe
Khushal Sagar, Google
Alan Stearns, Adobe
Miriam Suzanne, Invited Expert
Bramus Van Damme, Google
Lea Verou, Invited Expert
Scribe: fantasai
Rossen: welcome to Day 2
Shared Element Transitions
==========================
github: https://github.com/w3c/csswg-drafts/issues/6464
vmpstr: About Shared Element Transitions, a new set of APIs we're
working on for animations and transitions between pages
vmpstr: single page and hopefully multipage as well
vmpstr: Was presented in breakout session
vmpstr: since then worked on spec text and prototype in Chromium as
well
<vmpstr> https://tabatkins.github.io/specs/css-shared-element-transitions/
vmpstr: I sent this spec draft to the list awhile back
vmpstr: hoping that people interested would have read through the
draft
vmpstr: Ultimate goal for us is adopting this into the CSSWG
vmpstr: so we wanted to use this opportunity to surface issues people
may have
vmpstr: and of course we're happy to answer any questions
khush: Other goal that I'm hoping is, there are a few open issues in
the spec and things came up while prototyping
khush: and wanted to go over those as well
khush: hoping we can file issues within CSSWG and go from there
Rossen: We've had the overview in the past, there's also an open
aggregate for this feature, which we haven't gotten to
Rossen: Questions or comments or feedback to vlad and khushal?
Rossen: What do they need to move forward and adopt this as part of
the CSS charter?
Rossen: Do we need any additional overview, refresher of the APIs?
TabAtkins: Happy to discuss any concerns, but also if OK with making
ED can discuss later as well
fremy: I like the idea, just note that there is no images or diagram
or anything in the draft
fremy: so maybe in a future version, have a diagram of the different
pseudo elements
fremy: and what order they're in the page
fremy: It's in Ch4, but a diagram would be nice
fremy: not a blocking thing
<Rossen> https://github.com/WICG/shared-element-transitions/blob/main/explainer.md
Rossen: I posted also a link to the explainer, a bunch of really
well-illustrated examples there
fremy: Exactly what I was hoping for
Rossen: Anything else, fremy ?
fremy: Nope
<JakeA> Updated developer-facing article
https://developer.chrome.com/blog/shared-element-transitions-for-spas/
JakeA: I posted a link to the developer-facing content for this,
which includes a lot of videos and examples
JakeA: can put it in the spec if wanted
JakeA: I've never seen a video in a spec before!
TabAtkins: Of all this specs, this is probably the one that would
most benefit!
Rossen: Any objections to adopting this work?
fantasai: Are we adopting an ED, or are we also publishing FPWD
TabAtkins: Still have some tweaks to make, so happy to wait until we
get those down and then doing FPWD
fantasai: If you have planned edits, let's do ED now and FPWD later
then.
RESOLVED: Add Shared Element Transitions as ED, with JakeA, khush,
and TabAtkins as editors
Rossen: anything else on this topic?
<bramus> Nice!
<vmpstr> \o/
Sizing
======
Scribe: emilio
Scribe's scribe: fantasai
How does 0x0 size affect last remembered size?
----------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7539
oriol: Not sure if I should do a quick intro about
contain-intrinsic-size: auto
oriol: which is a feature that remembers the last size of an element
oriol: and then uses that instead of collapsing the contribution of
the contents
oriol: when you have size containment
oriol: This specific issue is about 0x0 size. The spec seems to
assume that using ResizeObserver is the way to track this size
oriol: since it mentions that the size is updated at ResizeObserver
time
oriol: when implementing this I found a problem when the size is 0x0
oriol: If you start observing an element with ResizeObserver and the
element doesn't have a 0x0 size then you get an observation
with the current size
oriol: but you don't get it without it
oriol: so the question is should we still store this size as the last
remembered size?
oriol: Seems like Chromium wasn't doing it
oriol: so I don't see a reason about why special-casing it
<dbaron> This sounds like a spec bug, and the spec should handle 0x0
sizes just like other sizes.
emilio: Now that you've explained this, this is only observable in
some cases, right?
emilio: if there's not stored size, you use 0x0
emilio: e.g. in one axis
oriol: when you have contain-intrinsic-size: auto you need to provide
a fallback value
oriol: so if you get the fallback you can detect it's not stored
TabAtkins: This appears to be a corner case falling from the
implementation details
TabAtkins: so I don't mind either way
dbaron: I think this is just a spec bug that was copied to the spec
because it was written based on impl
dbaron: I think 0x0 should be handled like any other size
TabAtkins: the spec doesn't special-case this
TabAtkins: so it's an impl bug
oriol: yeah, this is because the ResizeObserver inits its size to 0x0
TabAtkins: we only reuse the RO timing
dbaron: it might be a bug in ResizeObserver
flackr: Should we remember 0x0 only if the element was visible? This
is intended for content-visibility
oriol: There are some issues with storing the size
oriol: You need to be size-contained at the time, which
content-visibility provides in some cases
oriol: so if you lay out the content normally without
size-containment etc it gets saved
flackr: If the element has never been on screen we shouldn't be
remembering 0x0 for its size
flackr: we'd lay out 0x0 with content-visibility: hidden
oriol: If it has content-visibility from the beginning you don't
store the size
flackr: But content-visibility: auto changes dynamically when you
scroll
oriol: If you have content-visibility: auto initially outside of the
screen we won't store the last remembered size because it has
size containment, we'll store it once you enter the screen
flackr: So we won't save the size if it has size containment, so my
concern is addressed
flackr: ResizeObserver will still fire
oriol: Yeah, but you won't store the last remembered size
scribe: fantasai
scribe's scribe: emilio
emilio: I think I agree with dbaron, but it feels like a bug in
ResizeObserver
emilio: IntersectionObserver does fire an observation immediately,
regardless of whether on the screen
emilio: so it feels to me like a bug that ResizeObserver doesn't fire
on zero
<flackr> +1
emilio: and that would fix this by extension
emilio: so I suspect we just move this to the ResizeObserver spec
emilio: idk who's the editor of that?
emilio: but given the precedent of IntersectionObserver always firing
as well, it doesn't seem to me that this would be
objectionable
emilio: It seems the editors are no longer working on CSS specs
emilio: so we need new editors for this spec?
Rossen: Let's figure out what we want to fix and then figure out who
is going to do it
oriol: Proposed resolution would be that 0x0 size is not special, is
just like any other size
emilio: That's the current spec behavior
Rossen: That doesn't require any change to the spec, simply requires
implementations to fix their bugs
emilio: But then we need to file a ResizeObserver bug
Rossen: Yeah, but we're here to fix specs
Rossen: Seems we don't need a spec change, if the bugs are not filed,
please go and file them
Rossen: Anything else on this topic?
Rossen: Objections to resolving on 0x0 is not a special size?
RESOLVED: 0x0 is not special with regards to ResizeObserver or
contain-intrinsic-size
emilio: This means we need ResizeObserver spec changes
[discussion of possible editors]
<fantasai> +1 to oriol
RESOLVED: Replace ResizeObserver editors with Oriol and Emilio
Last remembered size when element is removed from the document
--------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7532
oriol: Spec says that when we store last remembered size, this
survives box destruction, e.g. if you add 'display: none', the
element will keep storing this last remembered size
oriol: My question here is if the element is removed from the tree
oriol: and then later re-inserted
oriol: will it still have its last remembered size from the previous
position in the tree?
oriol: Should we remove the last remembered size?
TabAtkins: I suggest whatever is easiest to implement
...
TabAtkins: Rossen made the point that moving the element is done by
removing the item ...
TabAtkins: but if you're e.g. re-ordering a list, you might want to
keep that info
<iank> yeah there are lots of cases for moving things around, and it
should keep the same last size.
TabAtkins: The common case for removing from document and
re-inserting is moving it around
TabAtkins: and the common case of that is re-ordering within a list
of similar items
TabAtkins: so my suggestion is to keep the last remembered size until
normal things remove it
<ydaniv> Is removing from layout tree much different from being
removed completely from the DOM?
emilio: You can move things around, given how specced right now
emilio: that means that if you move it, by the time you ??, it will
already have a box
emilio: When we fire ResizeObserver callback, if you move an element,
it will have a new box and a new position in the tree
emilio: Do we want to clear it if it's not in the document or doesn't
have a box, i.e. when you fire the ResizeObserver event
emilio: [missed]
emilio: Deciding at the time of ResizeObserver doesn't prevent the
moving case from working
TabAtkins: If you remove it from the tree, hold onto it a bit,
ResizeObserver fires, and then you don't have a remembered
size at that point
TabAtkins: when the ResizeObserver timing happens (well-defined), if
the element is outside the document, we clear the last
remember size
TabAtkins: because we forget the size in some cases at ResizeObserver
timing
Rossen: What do we do for animations?
TabAtkins: They're tied to the box
TabAtkins: but these are tied specifically to the element itself
TabAtkins: Is there an implementation concern?
emilio: No
TabAtkins: I could lean either way
Rossen: Oriol, do you have an opinion
oriol: No strong opinion, just wondering about it
oriol: I suppose we can leave it to not do anything special
oriol: Styles might change if you move it, or the old size might be
strange in the new position
oriol: but can also be fine
oriol: so no strong opinion
iank: The reason not to tie it to the box is that we have a lot of
features that will switch out of the box
iank: e.g. like when using CQ, it will be very common fro an element
to have potentially different boxes associated
ydaniv: contain-intrinsic-size is only interesting if you have
content-visibility and still out of view, right?
ydaniv: so by the time that the element is in view, it doesn't really
play any part, right?
oriol: It can play a part if you first lay out the element normally
and it can store its size, and then you add
content-visibility: hidden, then it can be in the screen and
keep its contents, and it will use its last remembered size
oriol: We resolved this last week
TabAtkins: That's the exact weirdo case this is designed for
Rossen: Ok, regardless if it's weird or not, we need to make it more
predictable
Rossen: If we specify that it fires, the previous size
Rossen: would there be any objections?
TabAtkins: I think I lean very slightly towards it forgetting its size
TabAtkins: if you're stashing away, not just doing a move
TabAtkins: it's much less clear that the new context you're putting
it into would be similar
TabAtkins: so I lean towards forgetting if it's out of document
Rossen: When you last checked this, did you check what
implementations did?
oriol: Chromium never seems to remove last remembered size
oriol: and in Gecko haven't landed implementation
flackr: For virtual scroller recycling element, I think we'd see this
happen, and you'd want to forget the size, because you're
changing the content before re-inserting
Rossen: So then the proposed resolution is that the element will
forget its last size
TabAtkins: at normal ResizeObserver timing
vmpstr: Then if removed and then re-added, then it's keeps its size
if it happened before the resize observer timing
TabAtkins: At ResizeObserver time, you also check if it is in the
document
TabAtkins: if not, forget the size
RESOLVED: At ResizeObserver time, forget an element's last remembered
size if it is currently out of the document
Recording last remembered size recorded given single-axis containment
---------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7529
oriol: We are only storing last remembered size if there's not size
containment
oriol: However, in newer specs of css-contain, we may have size
containment in a single axis
oriol: what happens?
oriol: Are we still storing both width and height of last remembered
size?
oriol: Do we not update last remembered size in the uncontained axis?
oriol: Should we check at least one of the axes has size containment
and then store both?
oriol: How should this work exactly?
TabAtkins: This is a very good question
Rossen: do you have a proposal, Oriol?
oriol: Maybe would feel more natural to me to do independently rather
than together
oriol: Right now Chromium stores together
oriol: I don't have a strong opinion
TabAtkins: I think I lean toward tracking them together, just because
say you have a set width and you have a contained block
size
TabAtkins: whatever height you want to remember, that depends on
your width
TabAtkins: if you end up with a different width, your height is not
going to be very meaningful
TabAtkins: It's weird to expect a different width also
TabAtkins: but I feel either record both or record neither
TabAtkins: and you need to have containment to get sizing to trigger
flackr: I was going to suggest the opposite
flackr: reason being that the only way that you have containment in
one axis by it being an explicit style, whereas containment
in both axes is because of content-visibility and being
off-screen
flackr: If the developer, while on screen, has containment in one axis
flackr: then it should store the last remembered size when it goes
off screen
Rossen: That's a compelling argument
TabAtkins: That seems reasonable
Rossen: Sounds like we're approaching a resolution
Rossen: Proposed resolution is that we'll keep them separate, and
store them separate
Rossen: Any objections?
RESOLVED: "last remembered size" is tracked for the two axises
independently (in case of containment in one axis), and can
be invoked independently (with contain-intrinsic-size:auto
in one axis)
<br end=??:20>
Clarify contain-intrinsic-size with multicolumn/grid
----------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7520
oriol: Spec defines contain-intrinsic-size as setting the intrinsic
inner size
oriol: then it says that this causes the box to size as if its
in-flow contents ...
oriol: but what exactly are its in-flow contents?
oriol: multicol container or grid container
oriol: In a multicol container, the size, it sets the width of the box
oriol: but if you have columns or tracks, the total width of the
column/container will be bigger than that
oriol: in grid it's the opposite,
oriol: but here, contain-intrinsic-size, was setting the content size
of the grid
oriol: ...
oriol: I don't think it's completely clear, and I want to have a
resolution on this
<iank> our multi-col intrinsic sizing isn't particularly good in this
respect.
TabAtkins: The Grid behavior is correct. Multicol is wrong
TabAtkins: We didn't think about multicol when writing this, but
thought about grid, and ignoring the grid stuff is the
intended behavior
TabAtkins: multicol should be fixed, and get a clarification in the
spec to make extra clear
oriol: If you specify contain-intrinsic-size: none and then in grid
it may become greater than zero
oriol: if you have e.g. fixed tracks
oriol: but if you specify contain-intrinsic-size: zero
oriol: then it will override grid template properties?
TabAtkins: Correct
TabAtkins: If not setting the size, you pretend no children, but grid
is still there
TabAtkins: but if set a size, you get that size
fantasai: What's the behavior with multicol?
TabAtkins: If you set contain-intrinsic-size to a length, you get
that size, not size of columns
fantasai: multicol columns are usually less fixed-size than fixed-size
grid columns anyway
Rossen: Is that the only clarification we need?
TabAtkins: This isn't a clarification for multicol specification,
just make clear that things such as multicol or grid don't
do anything special, size just gets overridden
Rossen: What's the proposed resolution?
TabAtkins: Clarify spec that layout systems that can have sizing
effects even with empty children don't matter,
contain-intrinsic-size overrides all of that and sets a
particular content size
RESOLVED: Clarify that setting contain-intrinsic-size to a size
overrides the content size, even if there is other sizing
info such as grid column widths
Clarify how contain-intrinsic-size affects size containment algorithm
---------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7519
oriol: There's a bunch of sentences in the spec, mostly editorial,
but the interaction of how the algo in containment spec is
altered to take contain-intrinsic-size into account
oriol: Mostly editorial, might not worth it to discuss now, just one
thing I wanted to discuss is
oriol: What about replaced elements?
oriol: The contain spec says that when you have a replaced element
with size containment, it behaves as if it had no natural
aspect ratio
oriol: and the natural size was zero
oriol: what happens if you have contain-intrinsic-size?
oriol: What Chromium does is that the replaced element still doesn't
have a natural aspect ratio
oriol: but the natural width and height are the ones specified in
contain-intrinsic-size
oriol: Does this make sense, or do we want some other behavior?
TabAtkins: Having used natural width/height take from
contain-intrinsic-size makes sense
TabAtkins: You asked, why do first layout if going to relayout
TabAtkins: Answer is, we want to make sure that under normal
circumstances, width calculates before height
TabAtkins: depending on contents, can have different effects
TabAtkins: once have width, then calculate height
oriol: So can we have an example of these cases in the spec?
ACTION: TabAtkins add an example
Rossen: Does that mean we don't need to change anything?
TabAtkins: Oriol's second example, needs fixing in the spec
fantasai: We want to clarify that it doesn't set the aspect-ratio
right?
Proposed: contain-intrinsic-size size is used as the natural sizes of
replaced elements (but does not set the aspect ratio)
<iank> some SVGs have this behaviour.
TabAtkins: Yeah
fantasai: I wanna suggest that if the aspect-ratio...
TabAtkins: We wanna say that it doesn't have an intrinsic
aspect-ratio, the property can affect
fantasai: Wonder if there's utility in being able to set the
aspect-ratio from those sizes
fantasai: guess it has to be opt-in, we don't know if the element is
supposed to have an aspect-ratio
fantasai: we might want to have that ability
<iank> if you want to opt-in to an aspect-ratio you can just set the
aspect-ratio as well?
fantasai: Yeah, you can do that explicitly, but it'd be easier to
have it computed from contain-intrinsic-size
fantasai: That's something to think about but can be addressed later
Rossen: Objections?
RESOLVED: contain-intrinsic-size size is used as the natural sizes of
replaced elements (but does not set the aspect ratio)
Last remembered size if there is no principal box
-------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7527
oriol: In a note, when the element gets display:none, then the last
remembered size is supposed to be preserved
oriol: If the element doesn't have 0x0, and the box is destroyed when
you apply 'display:none', then the last remember size will be
zero
oriol: if contain-intrinsic-size is auto, then need to remember this
last size
oriol: so we override the last size with 0x0
oriol: and then I guess we should add the condition that the element
at that point is not generating a principal box, shouldn't
record the size
TabAtkins: Correct, if it doesn't have a principal box shouldn't
record the size
TabAtkins: agree we should fix that
oriol: If there's no box, shouldn't we be able to remove this last
remembered size?
oriol: we resolved that if it's removed from the tree, we clear the
size
oriol: I guess if it doesn't have a box, the size doesn't change, but
my understanding is even if the size doesn't change, if you
remove contain-intrinsic-size: auto you remove last remembered
size
TabAtkins: Lacking a principal box shouldn't remove the remembered
size
TabAtkins: as long as you still have contain-intrinsic-size: auto
oriol: Consider a case where we have a box, but let's say that we
have contain-intrinsic-size: auto and we remember the size
oriol: and then we remove contain-intrinsic-size: auto
oriol: but box size doesn't change
oriol: Should we remove the last remembered size?
TabAtkins: Yes
TabAtkins: This is not tied to ResizeObserver, it's tied to
ResizeObserver timing
oriol: If you lose contain-intrinsic-size: auto, but this doesn't
trigger a size change, then we still remove the last
remembered size
fantasai: Okay
oriol: In this case, we wouldn't get an observation because the size
didn't change
oriol: but if we can remove the size when contain-intrinsic-size:
auto is lost, what if we first add display:none
oriol: and then remove contain-intrinsic-size: auto
oriol: by consistency, we need to remove the last remembered size as
well
oriol: but most browsers don't recompute style during 'display: none'
TabAtkins: So that's an implementation difficulty with matching the
spec
fantasai: Suppose if it's display: none you can flip things on and off
fantasai: and when you remove 'display: none', you check if
contain-intrinsic-size:auto is there and either clear the
last remembered size or not?
emilio: But you need to do that not at ResizeObserver time, but as
soon as you get a box that is not contain-intrinsic-size:auto
emilio: so you go display:none, at ResizeObserver time we don't know
what to do because don't have a box
emilio: if when you come back, you need to check
contain-intrinsic-size:auto
TabAtkins: that seems fine to me
emilio: It's weird to update this in different places
TabAtkins: I also think it's weird to do that, but it's apparently
problematic to do it while display is none
TabAtkins: So we check for contain-intrinsic-size:auto when the
element begins generating a principal box again
TabAtkins: if it doesn't have contain-intrinsic-size:auto at that
point, forget its last remembered size
emilio: yeah, ok
TabAtkins: If you're doing anything weird switching
contain-intrinsic-size while you're display:none it's your
fault
emilio: Consider Container Queries, might flip things depending on
container
emilio: if you're already compute Container Queries, you may need to
create a box for a size that isn't your final one
emilio: you may clear the remembered size,
emilio: ...
TabAtkins: Why would you clear it at that point
emilio: Imagine without CQ matching, you don't have
contain-intrinsic-size:auto
emilio: and once you know that you have a container of a given size,
the box gets contain-intrinsic-size:auto
TabAtkins: Easiest solution is to put contain-intrinsic-size:auto
less conditionally
emilio: Yes, I agree, but its a sketchy case
emilio: because it depends on how precisely you implement queries
TabAtkins: I think it's okay
TabAtkins: It seems ok for it to be less certain
TabAtkins: There's an easy solution: don't make it conditional in
your styles
TabAtkins: So proposed resolution is that we add new condition to
forget last remembered size
TabAtkins: which is if an element goes from not generating a
principal box to generating one, we check cis and if it's
not auto we forget the size
oriol: and for storing the size the element should have a box
Rossen: any objections to first one?
RESOLVED: If, when an element goes from not generating a principal
box to generating one, it does not have
contain-intrinsic-size:auto, forget any last remembered size
TabAtkins: If an element doesn't have a principal box, we do not
record a principal size
RESOLVED: If an element doesn't have a principal box, we do not
record a last remembered size
Rossen: Anything else on this issue?
oriol: Nope
Received on Tuesday, 30 August 2022 23:32:55 UTC