- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 22 Nov 2023 18:19:59 -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.
=========================================
CSS Snapshot
------------
- RESOLVED: Add View Transitions 1 to "fairly stable" in Snapshot
2023 (Issue #9577: Move CSS View Transitions to "fairly
stable" in CSS 2023)
- RESOLVED: Publish snapshot 2023 with css-view-transitions moving to
fairly stable and css-scroll-snap moving to rough
interoperability (Issue #9566: Finish up CSS Snapshot
2023)
- RESOLVED: Republish snapshot 2022 as Group Note (not Draft Note)
View Transitions
----------------
- RESOLVED: view-transition-name is discretely animatable (Issue
#9619: Is view-transition-name discretely animatable?)
- RESOLVED: :active-view-transition(*) has specificity of 1 class,
:active-view-transition(list) has specificity of 2
classes (Issue #9546: :active-view-transition()
specificity)
CSS Grid 3 & Masonry
--------------------
- RESOLVED: Accept some form of masonry slack property; exact
algorithm TBD; exact name TBD (Issue #9328: Reordering
threshold)
- Though it was clear how Masonry would handle <auto-repeat>
accepting intrinsic sizes, it was more uncertain if it could work
in Grid. Discussion will continue in issue #9321 (Allow
<auto-repeat> (i.e. repeat(auto-fill|auto-fit, ...)) to accept
intrinsic sizes) to understand further how it could be added to
Grid.
CSS Values
----------
- RESOLVED: Restore text simplifying out single-argument min/max
functions (Issue #9559: Simplification algorithm should
possibly return single child for min/max)
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2023Nov/0005.html
Present:
Rachel Andrew
Rossen Atanassov
Tab Atkins-Bittner
David Baron
Oriol Brufau
Keith Cirkel
Emilio Cobos Álvarez
Yehonatan Daniv
Elika Etemad
Robert Flack
Paul Grenier
Daniel Holbert
Brian Kardell
Jonathan Kew
Peter Linss
Noam Rosenthal
Khushal Sagar
Miriam Suzanne
Bramus Van Damme
Sebastian Zartner
Regrets:
Chris Harrelson
Chris Lilley
Lea Verou
Chair: Rossen
Scribe: noamr
Agenda Setting
==============
rossen: Do we want to change topics?
rossen: I added a topic at the zoom bottom
though Chris Harrelson asked to delay by a week
rossen: Both Alan and I received requests to discuss this week
rossen: If we have enough people we can discuss this week
rossen: if it can wait and we don't have enough people we can postpone
emilio: Would like to discuss them but can also wait a week if Chris
is interested
rossen: Thank you, appreciate the flexibility
rossen: will make sure they're first on agenda next week
rossen: Other changes?
rossen: Silence, take it as a no
F2F Scheduling
==============
rossen: About the f2f
dbaron: There was an email thread on the wg list
TabAtkins: Ideally it would be Feb 12,13,14, beginning of the week
rossen: We didn't have a resolution. can we have one or can it wait?
fantasai: Is there a possibility there wouldn't be space? should we
worry about this?
TabAtkins: Wait till I confirm the space, booking should be after.
Waiting for admin for spaces soon. certain about
confirmation next week
<khush> What's the tentative location?
<dbaron> I think tentative location was SF Bay Area
TabAtkins: Let's get it on record next week
rossen: ok, let's do this next week
rossen: Let's continue with agenda
<TabAtkins> oh yeah and locations has *not* been confirmed yet anyway
so booking flights is impossible ^_^
<TabAtkins> (aiming for mtv with seattle as secondary)
CSS Snapshot
============
rossen: 1st topic is finishing the CSS snapshot
rossen: Anything else we need to add?
Move CSS View Transitions to "fairly stable" in CSS 2023
--------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/9577
rossen: Chris said he's in favor of this
rossen: Anyone else that has opinions on this or objections
fantasai: I agree with that, it's fairly stable, level of issues
dropped to a low level, and we have an implementation so we
worked out all kinds of kinks
rossen: Objections to moving VT to fairly stable?
rossen: With no objections, calling this resolved
RESOLVED: Add View Transitions 1 to "fairly stable" in Snapshot 2023
Finish up CSS Snapshot 2023
---------------------------
github: https://github.com/w3c/csswg-drafts/issues/9566
rossen: SebastianZ, with the prev resolution to move
css-view-transitions-1 to fairly stable, what else is
remaining?
SebastianZ: This was the most obvious 1 that was missing. anything
else interoperable to add into the spec?
SebastianZ: I myself went through the specs and didn't find something
in the status, but perhaps missed one
rossen: I was going to put the question back to all of the group. Are
you working on any spec that can move to other state before
we close the snapshot?
rossen: Let's assume this is the only one. Chris Lilley was also
didn't have opinions on this. Didn't hear anything else
RESOLVED: Only change is the snapshot to record today is add
css-view-transitions-1 to fairly stable
rossen: Going back, css scroll snap? It was already in the spec,
Chris Lilley fixed
RESOLVED: Publish snapshot 2023 with css-view-transitions moving to
fairly stable and css-scroll-snap moving to rough
interoperability
SebastianZ: Not sure if this needs a resolution, but css 2022 is
still published as group draft note
<dbaron> https://www.w3.org/TR/css-2022/
RESOLVED: Republish snapshot 2022 as Group Note (not Draft Note)
rossen: We have both resolution now, that's all on the issue
SebastianZ: No other point
rossen: Let's jump into the view transitions topic
View Transitions
================
scribe: fantasai
Is view-transition-name discretely animatable?
----------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/9619
khush: Question was about view-transition-name, currently discretely
animatable
khush: but doesn't make much sense to be animatable
khush: feeds into pseudo-element DOM
khush: I would be OK making not animatable instead
flackr: We've made this mistake on a few properties in the past,
thought they shouldn't be animatable and then took compat
risk to make it animatable later
flackr: If no strong technical reason to make them discretely
animatable, would prefer to err on that side
khush: I don't have a strong opinion either way
khush: maybe we should wait for ntim
<astearns> +1 to discrete animation as a default to use unless we
have a good reason not to
noamr: There is a reason to make things discretely animatable for
things not animatable, because people use animation-delay in
various strange ways
noamr: e.g. "in 10s this property would change"
noamr: could be useful for view-transitions as well
Rossen: We could resolve to keep discretely animatable, and if Tim
has reasons to argue opposite, he can bring it back
scribe: TabAtkins
fantasai: What does it mean to change VT-name halfway thru an
animation?
noamr: For regular keyframe animations, at 50% view-transition-name
changes
noamr: view-transition animation itself doesn't change it
fantasai: So you're saying that view transition-name isn't animated
during a VT, but can be during a regular animation
fantasai: In which case the value of the property gets captured at
its current animated state if you trigger a VT during the
animation
noamr: Yes. And that could be, like, an animation-delay just to
timeout a change
noamr: people use that for timeouts sometimes
khush: It sounds like the reason we want it to be discrete animatable
isn't a VT issue, just CSS in general.
khush: Wanted to add was, keeping it discretely animatable has
nothing to do with view transitions
khush: but general CSS
khush: We could add a note to [missed]
<flackr> https://www.w3.org/TR/web-animations/#not-animatable
khush: Could we add a note to Animation telling spec authors to make
the property discrete unless there's a good reason?
flackr: The first note there explains when props *should* be excluded
from animation
Rossen: So conversation leads me to ask for resolution, to keep as
discretely animatable. Objections?
fantasai: I think given it doesn't affect VT animation it's probably
fine.
fantasai: We can go back to Tim and check with him
Rossen: Right, there's agreement on the call and if Tim feels
strongly we can bring it back up
RESOLVED: view-transition-name is discretely animatable
:active-view-transition() specificity
-------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/9546
vmpstr: With view-transition types we have a way to specify a type in
startViewTransition()
vmpstr: It enables :active-view-transition() on the root
vmpstr: Either takes an * or a list of comma-separated types
vmpstr: * matches any type, including none, if there's a VT running
vmpstr: list of names uses OR semantics
vmpstr: So, specificity of pseudoclass
vmpstr: Suggest we have (*) be 1 class specificity, (list) be 2
class
<khush> +1
<TabAtkins> Doesn't seem unreasonable since the list is class-like,
and it's valuable to have *some* specificity from the
* one
miriam: I find it somewhat confusing but I think it works
YehonatanDaniv: I was wondering why not use the same as :is()?
YehonatanDaniv: Same as its contents, so * would function as 0
vmpstr: The :active-view-transition(*) is still more specific than
not specifying anything at all, since it only matches when a
VT is active
vmpstr: So that's why I'm proposing 1 and 2, rather than 0 and 1
(Agreed.)
fantasai: I think this makes sense. If we end up with more complex
logical within :active-view-transition() we probably want
to expand the rule
fantasai: Like if you later can say "a view-transition with both foo
and bar" it should have 3 class specificity
vmpstr: Agreed
miriam: I wonder if a general way of stating that rule is that it's
"is-like" + the pseudoclass
TabAtkins: It's not really a selector - the class names aren't class
selectors, so you'd have to map it anyway. Same complexity
as just saying it.
fantasai: Probably not quite true, but as simple as it is now it's
fine to be manual
bramus: Right now authors could write :active-view-transition(foo)
:active-view-transition(bar) to match both with a higher
specificity
emilio: Isn't this an or rather than an and?
TabAtkins: Yes, the discussion was about possible future syntax.
Today's syntax is just a flat 1-class specificity
emilio: Can we just sort out that future stuff when we add it in the
future then?
TabAtkins: Yes
vmpstr: So proposal: :active-view-transition() specificity is 1 class
if it takes a *, 2 classes if it takes a list.
fantasai: Can it be empty?
vmpstr: Not valid syntax
fantasai: Should it be valid?
vmpstr: That's basically what * does, unsure what benefit it would
bring
fantasai: Just in general if there's a reasonable default behavior we
allow omitting
vmpstr: I think that might be a separate issue
fantasai: yeah
RESOLVED: :active-view-transition(*) has specificity of 1 class,
:active-view-transition(list) has specificity of 2 classes
CSS Grid 3 & Masonry
====================
Reordering threshold
--------------------
github: https://github.com/w3c/csswg-drafts/issues/9328
fantasai: In an earlier issue Ian suggested there should be some
control over high sensitive masonry is to exact height
differences
fantasai: Like if all your items are identical in size you'll lay out
your content in perfect rows, straight across
fantasai: But if it's different sizes, column 2 was a little bit
taller, you might skip from column 1 to column 3
fantasai: Ian suggested it might be useful to tweak the sensitivity
so it's not just "is the difference 0", but to allow some
amount of fudge factor
fantasai: So if the column 2 is only 10 px taller than column 1 and
3, you don't skip it, you place 1-2-3
fantasai: So do we want to add a control? Presumably takes a length
which is the fudge factor. And what do we call it?
<TabAtkins> +1 to adding it
<TabAtkins> unsure about name, don't like any of the suggestions :/
khush: Have you seen use-cases where this is needed?
fantasai: The case Ian pointed out is - when you jump, it's harder to
follow what's next. If you jump less often it's better to
navigate for the user
<fantasai> One issue with masonry style layouts is that things can
easily be visually out of order, e.g. if the current
tracks are [100px, 99px] the next masonry item would be
placed in the 2nd track, when the first would be more
natural. A potentially solution to this is some user
defined "threshold" to "place within the first track
within Xpx of the smallest track"
<fantasai> masonry-threshold: <length>
<fantasai> -- iank
TabAtkins: Use case is as described, when the mortar columns are
fairly ragged, it's fine to track across columns
TabAtkins: when there is some sort of order
TabAtkins: but when differences are very small, looks very strange to
skip over something
TabAtkins: if your column height differences are minimal, it looks
weird to have a gap
TabAtkins: better to have gap at the end of the row instead
TabAtkins: This is an ability that masonry libraries have; not sure
how common, but definitely some
<iank> One important note as well is the simple algorithm for this
doesn't work - there is a staircase case where the simple
algorithm doesn't work.
iank: [restates irc comment]
iank: where even if all the tracks are off by 1px it looks very
strange to select the first one
iank: So there needs to be a precise algorithm written that tests
against the cases
SebastianZ: So we're just talking about regarding the height of the
already placed content?
fantasai: Right
TabAtkins: I think we can resolve to add this ability. Should discuss
names, all the ones in the issue are more complex words
than I like to use in properties
<fantasai> masonry-slack?
<astearns> we should look to see what the masonry libraries use
TabAtkins: But I really like the masonry-slack fantasai just suggested
proposed resolution: Accept some form of masonry slack property;
exact algo TBD; exact name TBD
RESOLVED: Accept some form of masonry slack property; exact algorithm
TBD; exact name TBD
<TabAtkins> Agree with astearns we should do a quick survey to see if
libs have consistency in naming
Allow <auto-repeat> (i.e. repeat(auto-fill|auto-fit, ...)) to accept
intrinsic sizes
--------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/9321
fantasai: Ian suggested it might useful to be able to use auto-fill
with the intrinsic sizing keywords, particularly in Masonry
fantasai: Because, before you can stat placing items you need to know
the size of the tracks
fantasai: Currently the spec says that you resolve the sizes as if
all items were in that track
fantasai: So you can do an auto-repeat based on that size
fantasai: Can give you odd results if you have wildly differing
sizes, and all the thins happens to in one column
fantasai: But mostly you'll want this where sizes are similar to even
identical
fantasai: Grid could maybe also benefit from this
fantasai: There's cases where you want to have some number of items
in your autoplaced grid, but not hardcode the size of the
items into the track listing, you want the size to come
from the items themselves
fantasai: So doing something similar - take the size of the largest
grid item - could work
fantasai: So question is: is this something we're interested in
adding?
fantasai: We can add various restrictions as necessary. Like, maybe
only the intrinsic-auto-fill can be auto sized
fantasai: So you can have one repeat, it can have one track in it,
and it's the only intrinsic size in the axis
fantasai: More possibilities gets increasingly confusing
iank: I think this is one of the cases where it's potentially
confusing for authors in Grid
iank: But makes more sense in Masonry
iank: I typed out an example in the issue
iank: When you're determining the intrinsic size for your items, you
need to give them some constraints in the opposite axis
iank: Most noticeably, working out the intrinsic block size, you need
some inline size
iank: In Grid, since this is before placement, you don't know what
tracks they'll end up in, what size those tracks are, so you
have to give it *some* inline size
iank: And this'll differ wildly from the item's actual inline size
iank: So the intrinsic block size you're using for repetitions and
what it'll actually look like can be very very different
iank: This isn't a problem for Masonry, since the inline size between
these steps is stable, it doesn't change. Only a problem for
the Grid case
iank: So you'll end up with items where repetitions have a bunch of
free space where they shouldn't and we'll get bug reports about
Grid looking bad
oriol: Similar to what Ian is saying, I don't see a way to make this
work in Grid
oriol: Might make sense for Masonry but not seeing it for Grid
Rossen: Suggestions?
iank: The reason a separate display type might be useful is we make
things work great for Masonry even if they don't work for Grid
fantasai: If the track sizing in the other axis is all the same...
fantasai: So like in Grid if the other axis is all auto because you
haven't specified row heights
fantasai: You're auto filling the columns - however many will fit -
and the rows are auto height intrinsic grid tracks
fantasai: So one thing we could do is handle this by saying if the
track sizes in opposite axis are all the same size, then
autofill with an intrinsic size will take that size and use
it to calculate an intrinsic size for all items in the
grid, and repeat that for all tracks
fantasai: If there's more than one track size, like author is
alternating 500px and auto row heights, then the repetition
is just 1
fantasai: Functionally disabling the auto repeat, but it's predictable
iank: I don't think that works
iank: If the columns are auto, you still might place something in a
particular area that'll increase a particular column by a large
amount
iank: And the inline size you use for calculating the intrinsic block
size is again very different
fantasai: Elaborate?
fantasai: Rows are auto-fill, columns are all auto
iank: And you may place one item with a large minimum size in the
first column, so all the column will end up different sizes
iank: The inline size you use... you can't take that into account
when determining intrinsic block.
iank: So you'll end up with a bunch of free space
Rossen: Think we should go back to issue
CSS Values
==========
scribe: fantasai
Simplification algorithm should possibly return single child for min/max
------------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/9559
TabAtkins: Several years ago, we discussed simplifying calculation
trees
TabAtkins: we agreed to aggressively simplify, e.g. min() if same
units simplifies out
TabAtkins: as part of changes, I ended up removing the spec text
about min() or max() with single argument
TabAtkins: I'm not sure why I dropped that spec text, I suspect it
was an accident
TabAtkins: today all browsers do aggressively drop single-arg
min()/max()
TabAtkins: e.g. min(5px) + 10px becomes 15px
TabAtkins: Chrome recently also aligned on this behavior
TabAtkins: so I suggest we resolve on browser behavior, that
single-arg min/max functions can be dropped from calc tree
TabAtkins: even if the unit cannot yet be resolved
<dbaron> +1 to specifying what everyone does, seems like reasonable
behavior.
<dbaron> (I think sakhapov recently wrote some reasonably major
changes to calc() simplification in Chrome, to align with
the spec.)
<fantasai> +1 from me
RESOLVED: Restore text simplifying out single-arg min/max functions
Scheduling
==========
Rossen: astearns and I were discussing whether to add extra topic call
Rossen: or just a general session, since we have 50+ issues agenda+
<bkardell> sgtm to run a poll on the ml
fantasai: should we schedule and then decide the topic? only a few
weeks before holidays
Rossen: we'll poll the WG
Received on Wednesday, 22 November 2023 23:20:33 UTC