- From: Dael Jackson <daelcss@gmail.com>
- Date: Fri, 8 Mar 2024 11:38:32 -0500
- 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.
=========================================
+++Anchor Positioning Breakout+++
Fixing the animation problem (Issue #9598)
------------------------------------------
- RESOLVED: Specify how styles that are conditionally dependent on
layout get recomputed
- RESOLVED: We will use the same sort of recomputed values for
animations on anchor & anchor-size functions
- RESOLVED: Accept that inset area changes the containing block
- RESOLVED: Defer magic position animations until level 2
Can we clarify the `inset-area` syntax? It can be confusing to read
and reason about (Issue #9862)
-------------------------------------------------------------------
- RESOLVED: Switching center-* keywords to span-* and all to span-all
Should size/layout containment also contain anchor names? (Issue #9349)
-----------------------------------------------------------------------
- RESOLVED: Layout containment contains anchor names and size
containment/paint containment do not
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2024Mar/0004.html
Present:
Tab Atkins
Kevin Babbitt
David Baron
Stephen Chenney
Keith Cirkel
Emilio Cobos Álvarez
Yehonatan Daniv
Elika Etemad
Robert Flack
Chris Harrelson
Anders Hartvoll Ruud
Daniel Holbert
Vladimir Levin
Rune Lillesveen
Khushal Sagar
Alan Stearns
Miriam Suzanne
Sebastian Zartner
Chair: astearns
Scribe: keithamus
Anchor Positioning
==================
Fixing the animation problem
----------------------------
github: https://github.com/w3c/csswg-drafts/issues/9598
TabAtkins: This is two distinct issues. I had an issue in the works
to post, but didn't get it finished before the end of the
day.
TabAtkins: Presently, when we define container queries we implied how
anything effected by the query worked but it's not
specified.
TabAtkins: At the least chrome and webkit act similarly - so there's
a throughline.
TabAtkins: The existence of container queries is that computed values
depend on layout
TabAtkins: They must be computed. If a container query matches,
changes the value, and the child has a transition on the
property it needs to fire the transition
TabAtkins: This is a computed value change. We can't know this until
layout is already happening and has reached the container.
TabAtkins: So we need to somehow figure out what the values were and
patch them in.
TabAtkins: This needs to be specified.
TabAtkins: The rough description is what I just described; part way
through layout when we interleave style and layout, and
some point (which we'll specify) you realize the computed
values need to change as the result of layout, we compute
them, teat them as computed values - figure out
transitions, inheritance, etc - then continue along as if
they were always those values
TabAtkins: this is also how we make anchoring work well
TabAtkins: With the interleaving - does that sound reasonable to
everyone? Chrome already does this. WebKit is similar but
its not as scoped, they do more work but the end result is
the same
TabAtkins: I do not know what Firefox does. How it handles these.
emilio: We do something very similar to WebKit here.
TabAtkins: Implementation details determine exactly what happens, but
does this description work?
emilio: For webkit and gecko (may have some issues with transitions).
Is sort of what you describe but it's not... you update the
page layout, then recompute the styles for things that
change. I'm not sure specifying it that way... like the
interleaving blink has...
emilio: If you do the extra work of if something changes then
recompute it... I mean it generally sounds the right
direction but I'd like to have a read of it before.
TabAtkins: Yes I'm interested in if this is the right direction
emilio: The difference between blink and webkit/gecko, AFAIK, style
the page as if no container queries match, then do layout,
then for things where container queries change, recompute
style, then loop until you get to a stable state. Blink does
something more subtle.
futhark: In optimal cases we can pause layout and style the subtree,
then continue. In several cases we do also need to do
multiple passes. Layout depends on auto widths for eg we may
not correctly detect this then have something more similar
to gecko/webkit
iank: Not exactly the same...
iank: webkit/gecko are failing tests for behavioral difference. Some
subtle differences, because they're revisiting prior states.
astearns: Are tests written down based on spec or impl?
iank: Written in spec.
<TabAtkins> (there is no spec to be followed right now)
astearns: Observability... is this a design decision for how we visit
this? Recomputation being observable?
chrishtr: Right. Not observable.
chrishtr: Difference in blink and other two engines, it's a bit more
optimized to avoid recomputing.
iank: It's quite a bit faster for degenerate cases, and bugs in other
engines. Theoretically could be fixed.
chrishtr: Just a matter of quality of impl difference?
emilio: Main difference is how to prevent cycles, things depending on
siblings, ancestors, scrollbars, and so on
iank: Not cyclical but previous states.
astearns: Do we want a resolution? Computed values getting recomputed?
PROPOSED RESOLUTION: Specify how styles that are conditionally
dependent on layout get recomputed
RESOLVED: Specify how styles that are conditionally dependent on
layout get recomputed
TabAtkins: Next up. Anchor and anchor size functions should be
dependent on this concept.
TabAtkins: Right now... the anchor function needs to turn into a
length, we're not sure exactly when, but at some point it
needs to turn into a length to position your element. You
need to layout your anchor first then figure out what the
length is. It should be transitionable.
TabAtkins: If your anchor moves, you should be able to smoothly
transition things. If the element you're referring to,
e.g. changing anchor name values, you should smoothly
transition to them.
TabAtkins: So this is dependent on that too.
TabAtkins: Larger bit on animation too, but the interleaving is
important
emilio: Other than animation why do we need it to turn into a length?
TabAtkins: It is for animation
TabAtkins: For all other purposes it's fine
emilio: It feels unfortunate that for all other cases it needs to do
the extra work to compute
emilio: Making it a computed value requires some amount of extra
work. Unfortunate to require this. If we need it to be
computed, then it makes sense, but ordering & dependencies
get very tricky.
TabAtkins: It's a more complex relationship than container queries.
At the moment it means we don't do as-smart trimming for
interleaving because the relationship is more complex.
astearns: If we want these things to animate then we have to do
something? These things animate discretely... we don't want
that. Stuffing these changes into computed values, because
that's how animations work, but I suppose we could say
computed values that depend on layout use used values
instead? That seems worse
TabAtkins: I don't know if that seems worse. We're doing all this for
the purpose of animations. If there's a simpler solution
I'm happy to explore it.
iank: Can't use used values... they're at the wrong phase for
animations. To do that would be a big and complicated lift.
astearns: We're kind of doing that, not used but recomputed which are
closer to computed.
iank: I don't think it's comparable.
chrishtr: Second what iank says. emilio is right in difficulty of
interleaving but the coherence and overall complexity is
less than creating a new way of doing animations. This is
just scoped to doing the interleaving, already had to be
done for container queries, animations just fall out of
that. Confirmed in prototype in blink. Clean solution.
dbaron: The other scary thing is used values - we don't fully
formally defined them vs earlier stages
PROPOSED RESOLUTION: We will use the same sort of recomputed values
for animations on anchor & anchor-size functions
emilio: Do we need to define what they resolve to when the anchor is
not there?
TabAtkins: Already in the spec. It's the fallback value, which is
zero if not specified.
emilio: If your anchor has been laid out... I guess I'm wary of the
outcomes that happen when you incrementally do this. An
anchor function...
emilio: I think container queries have the same issues but this can
be sorted in the spec.
emilio: When you have a style change and the anchor has been laid out
before. That can be dealt with the same way as container
queries. Probably fine.
TabAtkins: Curious about exactly the case. We can discuss in the
issue if you'd like
astearns: Is there a need to specify how animation from anchor size
from initial to actual recomputed value? Or does that fall
out
TabAtkins: Initial value?
astearns: If anchor isn't there it falls back to initial value.
Something changes such that there is an anchor - is it
possible to animate from that to a place in layout?
TabAtkins: That behavior should fall out
RESOLVED: We will use the same sort of recomputed values for
animations on anchor & anchor-size functions
TabAtkins: One final bit. Do we want to defer fancy animation stuff?
emilio proposed that there are enough holes in the idea of
position animation animating the rectangle idea I
discussed in the f2f. We want to spend more time thinking
about it? I'm okay with this based on above resolutions.
Most cases will animate reasonably.
<chrishtr> +1 to deferring to level 2
TabAtkins: Edge cases should be safe to upgrade to via some kind of
opt in.
TabAtkins: I propose we kick animation idea to level 2 and work on it
later.
<fantasai> https://github.com/w3c/csswg-drafts/issues/9598#issuecomment-1836854109
fantasai: I don't mind if we want to push animatability questions to
level 2, but there was a number of follow up changes we
were planning to make to inset area, alignment, and other
things listed, I don't want to defer. As long as making
those changes depend on animation, I'd like us to figure
out animation
TabAtkins: What might we change on inset area?
fantasai: Containing block vs only causing auto values to compute
TabAtkins: Already in the spec
fantasai: When? That was in this issue?
TabAtkins: It's been in for a while
TabAtkins: Previously we had inset area work by adjusting auto values
of inset properties, causing inset properties to match up.
This would allow you to animate between inset areas, to
some extent. The Apple proposal instead proposed the inset
area changed the containing block, which I pushed back on
as it was less animatable.
TabAtkins: It's a better behavior to do the container block change
and solve animations some other way. If we're deferring
the animations stuff to level 2 it means we're potentially
regressing inset area animations. I'm okay with that... if
we set inset area back to how... resolves, we don't have a
good path to a better future world.
TabAtkins: I'm okay with it being less animatable now since we have
an idea of how we're going to fix in the future.
PROPOSED RESOLUTION: Accept that inset area changes the containing
block
RESOLVED: Accept that inset area changes the containing block
fantasai: That was my main concern, if we need more time and nothing
is blocking then that's fine
flackr: We won't be able to automatically enable these animations
right?
TabAtkins: Current proposal is a position-animation property to
trigger the good behavior.
TabAtkins: Cannot do it by default as it'd be incompatible with
today's behavior
flackr: Can change it so certain position types are animatable and
others aren't?
TabAtkins: Yes, this is an argument to defer it so it isn't just
focused on anchor
flackr: I just want to make sure the upgrade path isn't too difficult
astearns: What will be animatable in level 1 vs 2?
TabAtkins: Level 1- properties animating as normal to the extent of
positioning insets, e.g. top and left. but if you switch
from top to using bottom that won't smoothly interpolate.
TabAtkins: Or if you change inset area, or self alignment from align
self to justify self. Properties will animate it won;t be
discrete, but it wont be smooth
flackr: Usually authors will rely on transitions so there'd be no
animation, change from auto to non auto would be discrete
astearns: Any concerns with level 1?
PROPOSED RESOLUTION: Defer magic position animations until level 2
RESOLVED: Defer magic position animations until level 2
astearns: Next Clarifying inset area syntax.
Can we clarify the `inset-area` syntax? It can be confusing to read
and reason about
-------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/9862
TabAtkins: Changing inset area syntax was discussed at f2f. People
didn't like keywords. fantasai and I are weakly in favor
of switching to span-left or span-start to indicate center
and the other direction
<fantasai> used to be `bottom / center left`
<TabAtkins> `bottom center-left`
TabAtkins: Right now if you wanted to express <select>, it fills the
center and right
<emilio> Select element behavior is actually different across
platforms :')
TabAtkins: Proposal is more like a background syntax, we use center-*
properties to indicate 2 column or 2 row.l
<TabAtkins> `bottom center` vs `bottom-center`
<fantasai> maybe we need keywords for platform behaviors...
TabAtkins: These were two extremely different areas being selected
<TabAtkins> `bottom span-left`
TabAtkins: So all center-* words are now span-*
TabAtkins: bottom row, span from center to left columns.
TabAtkins: in terms of number-pad in a 3x3 grid, cells 1 and 2
TabAtkins: Unless anyone has a great opinion, I suggest we go with
these as a different suggestion. Center being unclear,
space or dash when saying out loud, and still is
reasonably readable
astearns: I agree this is an improvement
dbaron: It seems less clear to me in the syntax that it's occupying
two grid spaces.
TabAtkins: It's spanning, so by definition it covers multiple spaces
<TabAtkins> also, for example, `span-bottom span-left` covers 4 cells
(4512 on numpad), and can't be written with compasses
keithamus: At Github we have an implementation that uses compass
directions
<fantasai> https://github.com/w3c/csswg-drafts/issues/9862#issuecomment-1924919417
fantasai: For background position we have very analogous syntax. We
can't use compass directions because we have several
different coordinate systems to worry about. Start-x,
start-y, x and y, and block-start, inline-start, etc. The
syntax... there is a lot of keywords.
fantasai: This is a bunch of stuff that can be expressed in
background position
dbaron: What's the current syntax for spanning all 3?
TabAtkins: 'all'
TabAtkins: I'd be comfortable switching to span-all.
astearns: Are you uncomfortable with this dbaron?
<miriam> +1 span-all and span-(direction)
dbaron: I'm okay, I just would prefer something clearer
fantasai: Can keep the issue open, but I'd like to resolve on
something so we can put a stake in the ground and publish a
spec
PROPOSED RESOLUTION: switching center-* keywords to span-* and all to
span-all
RESOLVED: switching center-* keywords to span-* and all to span-all
Should size/layout containment also contain anchor names?
---------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/9349
TabAtkins: Already in spec that style containment triggers
containment of anchor names
TabAtkins: Should other containments have this? Layout containment
should for the same reason that it censors baselines. If
it didn't you'd have to do layout in the subtree.
TabAtkins: Defeats point of containment
TabAtkins: Size containment should depend on children size and layout
children etc. No guarantees are made about being able to
defer work on layout containment
TabAtkins: Size containment should not scope anchor names
TabAtkins: We use size containment as a cycle breaker a lot.
TabAtkins: Scoping it means you wouldn't be able to use container
queries and anchor names on the same page.
TabAtkins: Paint containment doesn't for the same reason
emilio: I guess scoping would work both inside and outside right?
TabAtkins: No
emilio: So some kind of named scoping? I don't see how they change
the constraints?
emilio: If a name bleeds inside a layout contained thing...
emilio: Does layout containment also scope counter names and so on?
TabAtkins: No and it shouldn't. You don't need to do layout for
counter names, just box tree.
emilio: I was just confused about what point and where in the
dependency tree
miriam: Container queries add layout containment as well. Even if we
restrict on layout containment we still have problems on how
these two interact.
miriam: You cant use anchoring across different containers
futhark: You can't anchor something inside the size container
outside, or vice versa
TabAtkins: Regardless if we allowed names to leak out of layout
containment it defeats the point of layout containment.
TabAtkins: I think it's still a requirement that layout containment
scopes the values
miriam: Should we open a new issue to resolve how these two interact?
astearns: A developer need to use these across boundaries trumps the
need for good optimizations
chrishtr: Resolve this then raise new issue?
astearns: Yes resolve this issue and then work out how it interacts,
revisit it if it turns out there's a need to anchor across
boundaries
astearns: Did futhark's remarks change your position TabAtkins?
TabAtkins: Same. It only matters for style queries
futhark: No it's also generated compute from... layout on outside
TabAtkins: That's not in the spec right now as far as I can tell
futhark: Yes, container type size also applies layout, size,
containment
futhark: This is not a problem specific to layout containment, also
style containment...
TabAtkins: Okay. Let's discuss that in the new issue
PROPOSED RESOLUTION: Layout containment contains anchor names
PROPOSED RESOLUTION: Layout containment contains anchor names and
size containment/paint containment do not
RESOLVED: Layout containment contains anchor names and size
containment/paint containment do not
TabAtkins: I have an anchor breakout session in the w3 breakout
sessions to resolve the remaining issues. Provisional time
slot for now.
astearns: We can use that session for a wider audience hopefully
fantasai: Those breakouts are for across w3. So if we want to resolve
issues on our own, we should schedule on our own, but
discuss stuff with the broader community in the breakout
TabAtkins: I thought it was the same as TPAC Wednesday.
astearns: We'll figure out some extra meeting times.
Received on Friday, 8 March 2024 16:39:05 UTC