- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 26 Feb 2025 19:36:56 -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 Values
----------
- RESOLVED: Accept the general approach, change map naming to scale
for now, iterate on syntax later (Issue #6245:
Interpolate values between breakpoints)
CSS2 & CSS Tables
-----------------
- The group reviewed the proposed solution for issue #11408 (Do
collapsed tracks also shrink the table wrapper box or only the
table grid box?). The proposal made sense and was in the right
direction, but there was a request to think more about handling
wrapper and grid box sizes to see if there was a more expected
outcome that could be achieved. Discussion will continue on
github.
- RESOLVED: Overflow applies to the wrapper box (Issue #10881: Does
`overflow` apply to table-wrapper or table-grid?
css-tables contradicts CSSWG resolution)
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2025Feb/0019.html
Present:
Rachel Andrew
Rossen Atanassov
Tab Atkins-Bittner
Kevin Babbitt
Oriol Brufau
Stephen Chenney
Keith Cirkel
Emilio Cobos Álvarez
Elika Etemad
Robert Flack
Chris Harrelson
Daniel Holbert
Jonathan Kew
Roman Komarov
Alison Maher
Cassondra Roberts
Gaurav Singh Faujdar
Miriam Suzanne
Josh Tumath
Bramus Van Damme
Lea Verou
Samuel Weinig
Scribe: bramus
Agenda
======
Rossen: Any changes to the agenda?
Rossen: Gonna skip the first issue
Rossen: The reading flow one. got request to skip because some people
not ready
Rossen: One was removed, the other one will be skipped
Rossen: Any other changes?
astearns: Future agenda things
<astearns> https://github.com/w3c/csswg-drafts/issues/11775
astearns: next week starting off with overall issue from ChrisL about
font privacy
astearns: people from Brave will be joining
astearns: talking about how are going to solve font fingerprinting
astearns: have a good problem about the problems for privacy and lack
of access for local fonts and bunch of different issues
about possible solutions but have not gotten people
volunteering to work on implementing and trying out these
astearns: would like to get to this next week: some commitment to
working on these things to get past the formal objection
<astearns> https://github.com/orgs/w3c/projects/113/views/1
astearns: second thing is we have this project (link^) that has a
number of issues in flight for scope
astearns: and scope is part of this years interop, so we should
probably finish up
astearns: especially the items in the in the progress section
astearns: most likely will have a breakout session
chrishtr: Want to come back to the agenda
chrishtr: who requested to remove the reading flow issues?
Rossen: a member, doesn't matter
TabAtkins: we were discussing these already last week, weird that it
gets pushed out
Rossen: we respect the request of any member of the wg if they want
to move because they need more time
TabAtkins: bizarre that this is secret
Rossen: if the person wanted to request this publicly then they would
have done so
TabAtkins: in general, we are not comfortable with things getting
pushed away for secret reasons
astearns: the reason is not secret, they needed more time
TabAtkins: but nobody knows who it was, which is bizarre
Rossen: this has happened before
astearns: one thing we can do to make this better to post to the
private list about it
astearns: instead of sharing it on top of the meeting
TabAtkins: yes, please
<rachelandrew> +1 to that suggestion
chrishtr: that’d be great, thank you.
CSS Values
==========
Interpolate values between breakpoints
--------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6245
TabAtkins: Elika and I were looking over this and there is a generic
request to interpolate values based on some other progress
value
TabAtkins: can be done by hand with calc, but does not work for all
values
TabAtkins: or there are complex ways to interpolate
TabAtkins: seems like a reasonable thing, that if you can do a
transition, you can get the value for it too
TabAtkins: upon review of the use-case, what we were trying in the
spec was not good enough
TabAtkins: currently not implemented, so can start over
TabAtkins: new proposal
<fantasai> Writeup is at
https://github.com/w3c/csswg-drafts/issues/6245#issuecomment-2661545284
TabAtkins: two notions of interpolation
TabAtkins: 1. mixing of two values
TabAtkins: 2. interpolate values in series, more like linear() for
timing or gradients
TabAtkins: both are nearly identical, but when you reach 3 values
they differ a lot
TabAtkins: can model either with the other, but frustrating and weird
TabAtkins: prop to introduce mix and map
TabAtkins: mix = ...
TabAtkins: syntax proposal in the issue
TabAtkins: thoughts, ideas, ...?
<weinig> are the existing spec'd functions the progress() functions?
<fantasai> weinig: https://drafts.csswg.org/css-values-5/
<lea> https://github.com/w3c/csswg-drafts/issues/6245#issuecomment-2685663483
lea: posted my thoughts on this link here
lea: when I started writing that I was not too crazy about
introducing more functions
lea: wanted to overload the existing mixing functions
lea: but while writing my feedback it would make sens to have a new
function (if it has a good name)
lea: maps typically help you transform 1 value into another
lea: (example)
lea: several requests had to add mapping to css
lea: even though something like calc-map() or whatever-map() it
overloads the concept and now mapping is 2 diff things
lea: also confusing to be using an established concept in a
different way
lea: interpolate is long and technical
lea: brainstormed a bit (see table in comment)
lea: leaning towards the name scale which gives a nice color-scale
lea: and calc-scale
lea: not ideal for images
lea: also huge +1 for solving this use case
lea: is major in design systems and tokens
lea: so yeah
TabAtkins: not attached to the name, we chose map because interpolate
was bad for your reasons and its also short like mix
<fantasai> +1
TabAtkins: scale seems appropriate
TabAtkins: having a whole family of related functions the worry
<fantasai> We weren't particular about the name, just needed one.
<astearns> a little worried about our existing scale property
weinig: which of the css-values=5 functions is this replacing?
TabAtkins: the mix functions, not the progress ones which are inputs
to these
weinig: got it
weinig: other suggestion: blend
weinig: because that is often the result
weinig: problem with scale is that we already have scale()
TabAtkins: only objection to blend is that it is a close synonym
to mix
<lea> +1 to TabAtkins . Also `blend` sounds related to blend modes
TabAtkins: the better we can help authors remember which is which
is good
lea: +1
lea: and also bend sound related to blending modes
TabAtkins: Probably can't avoid some semantic overlap
Rossen: Sounds like we are converging?
fantasai: yes, want to go over what it is
fantasai: the function takes a bunch of top level params and what the
progress is within the scale and a list of stops similar to
linear-gradient(0 with an interpolation option between the
stops (easing function for example)
fantasai: and then the top level options are a source for the
progress, also giving you an option of transforming that
source through an easing function, and an option saying
each step gets its own easing
fantasai: that is the top level
fantasai: and then the stops have a syntax where it is `stop: value`
and you interpolate between the stops
<fantasai> color: color-map(media-progress(width, 0px, 2000px),
<fantasai> 0%: red,
<fantasai> 100%: blue);
<fantasai> color: color-map(media(width),
<fantasai> 0px: red,
<fantasai> 2000px: blue);
fantasai: also introducing new functions
fantasai: percentages, pull the value out directly
fantasai: pull out the start and end values, package them up together
and put m in a variable
fantasai: so the progress functions are worth keeping for that reason
fantasai: Questions?
lea: don't quite understand by vs each
lea: its a good design goal to be compatible with gradients
lea: it could even b ea design goal that everything in side
color-scale is a valid gradient
lea: good for release and debugging
lea: the syntax with colons of positions and values. not sure the
reduction with the rest of CSS is warranted by the usability adv
lea: seems small
lea: breaking compat is a good thing if it gives you a significant
advantage, not sure that is the case here
lea: suggestion to stick to existing syntax
lea: we would need to make it mandatory that the stop position comes
after the value in the calc version, as otherwise there would be
disambiguation problems
lea: where you can percentages
<TabAtkins> animating-timing-function vs animation-easing
fantasai: Difference between by and each is whether you are applying
easing between two stops or to the entity of the progress
value. Animations have this distinction. Can ease the
entire timeline or in between keyframes.
fantasai: have the ability to put easing between any two stops, or
the whole thing upfront
fantasai: that is the difference
fantasai: about the colon in the stop syntax: that is because of the
parsing ambiguity
fantasai: can't know the return value upfront
fantasai: other option is to align with if() and use semicolons
fantasai: not sure though
TabAtkins: there are certain value types make it ambiguous to read or
actually ambiguous
TabAtkins: e.g. calcs() sometimes hard to read
TabAtkins: not obvious to a human sometimes
TabAtkins: more problematic is the generic map() that can do entire
property values
TabAtkins: no way to know where the value ends
TabAtkins: so have to either put the percentages in a distinguished
place (like now) or only require 1
TabAtkins: would not allow us to do 1 or 2 stops
TabAtkins: because those functions have parsing difficulties if you
try to mix things in, we decided to carry that through the
whole family of functions
TabAtkins: making most of map functions look similar to mix functions
but then some not, looks worse
<TabAtkins> 1 + 2px +3px
lea: agree that consistency with each other is more important than
consistency with the rest of CSS
lea: not sure about the color … hard to read or disambiguation issue?
lea: for the generic no amount of syntax would work other than
putting it first
fantasai: (missed) progress values. can have a stripe
lea: is the generic function actually happening? remember we had one
for mix but then had to drop it
TabAtkins: multiway interpolation is trickier but if its just for map
you are only interpolating two values at a time – we
already know how to do that
lea: this wont solve issue with generic, but at least for others we
could introduce an at-keyword
lea: like red at 50%
lea: very readable
TabAtkins: but unfortunately does not extend
TabAtkins: not the best, happy to discuss precise syntax more
TabAtkins: looking for objections about the general approach
<fantasai> thought lea meant red @ 50%
<lea> fantasai: no, I meant `at 50%`
<fantasai> @ 50% might be kinda nice though :)
<fantasai> It avoids any parsing issues since @ is not otherwise valid
Rossen: so now are gonna stick with the map?
TabAtkins: let's switch over to scale and continue discussing
lea: do we have a proposed resolution? take on work?
TabAtkins: yes: accept the approach we have outlined in the issue
changing the map naming for scale and continue iterating
on the design in the spec
<lea> PROPOSED RESOLUTION: Accept the general approach, change map
naming to scale for now, iterate on syntax later
Rossen: sounds reasonable
weinig: will the keyframes part remain as well?
TabAtkins: that is the plan, but also up for discussion
weinig: I think you should keep them
fantasai: Questions for syntax were about the separator keywords by
vs each and the name of the function
<lea> Huge +1000 to solving this problem, this is huge. Some doubts
about each (do we have use cases for it?) but we can sort out
later
lea: +1, like I said in IRC
lea: its low level, but lack of being able to do this keeps cropping
up all the time
fantasai: yes, need to thank Scott for filing this and following up
on it
Rossen: Objections?
Rossen: none, so we are resolved.
RESOLVED: Accept the general approach, change map naming to scale for
now, iterate on syntax later
CSS2 & CSS Tables
=================
Do collapsed tracks also shrink the table wrapper box or only the
table grid box?
-----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/11408
oriol: first you layout the table without collapse, and then remove
the collapsed tracks
oriol: this is about collapsing of rows and cols
oriol: typically it is the parent formatting context that decides the
size of a box, but here it is like the table and this can
confuse the parent FC
oriol: was investigating what browsers do
oriol: only checked gecko and blink
<oriol> https://github.com/w3c/csswg-drafts/issues/11408#issuecomment-2563995794
oriol: there is a table in this comment I linked to
oriol: some shrink or do not shrink
oriol: ?? they don't collapse which I think is right. would otherwise
be bad if table is inside an inline-block
oriol: when actually deciding final size of the table there are
differences
oriol: gecko has wrapper table box and ?? box, and blink only has
single box.
oriol: in the inline axis gecko does not shrink the table wrapper
box, only the table grid box
oriol: this has nice properties like avoiding conflicts with PFC
oriol: some slightly surprising things like centering with auto
margins it only centers the wrapper so could be off center
oriol: blink has a single box and tries to shrink “both” things
oriol: but it does not shrink in a flex row because it could conflict
with flex sizing algo I think
oriol: what does it mean if the table is suddenly shrinking?
oriol: does not shrink for tables that have flex items in a row or if
the table is abspos
oriol: otherwise it behaves a if table wrapper shrinks
oriol: for table grid gecko ??? it shrinks except for flex rows and
abspos boxes
oriol: things that are more interesting in the block axis: both try
to shrink as much as possible
oriol: but in flex columns no browsers shrinks the intrinsic block
contributions
oriol: for final size of the table wrapper blocks gecko ???, blink
does not shrink the wrapper but does shrink the grid
oriol: not sure what is going on.
oriol: I like gecko’s inline-axis behavior
oriol: not sure about the block
oriol: like that a box can decide to if inline size conflicts with
PFC it can shrink
oriol: there are several things to discuss here
iank: 1 thing I dislike is that when we set a height 100px on a table
it will shrink both ??? seems like a ?? on the wrapper box side
iank: if we end up with resolution that keeps the wrapper box at
100px that would be good
iank: some complexity … if all ?? size up to the inner grid box
iank: not sure what to do there
fantasai: for the margin case I wonder we could probably compensate
for that by either having the auto margins also do
something to the table grid box or just saying authors can
use the alignment properties to align both boxes
iank: oriol, can you say why you don't like affecting the intrinsic
contributions?
<oriol> https://github.com/w3c/csswg-drafts/issues/11408#issuecomment-2653101446
oriol: see this link
oriol: if you have a table that is inside an inline-block and the
table has 2 cols, one of which is collapsed, and each column
has a cell with min-content size of 50 and max content of 100
oriol: if you don't take collapsed tracks into account the ?? of the
table is 200px
oriol: if we decided to change this, it could be 200 but removing 1
col, so 100px
oriol: problem is that when we lay out table for real, we only have
100px of available space to give both cols
oriol: so each would be 50px instead of 100px
oriol: what will happen is that we end up with 1 col of 50px and its
not the ideal size
iank: makes sense
iank: making intrinsic block contributions match inline contributions
would be the right way to go there for consistency
iank: and we likely are not constrained too much because webkit does
not have this feature yet
iank: might need to think a bit more about the wrapper and grid box
sizes
iank: the way that they work could be funky
Rossen: Oriol, where do you want to take this?
Rossen: the issue or try for a resolution?
oriol: if Ian wants to think more about it, we can bring back to the
issue
oriol: this even belongs to CSS2, so a bit weird that we have this
oriol: but can bring back to the issue
iank: if you (oriol) write down possible solutions, that would be
helpful
iank: what you think is the best
iank: I can also propose something
Rossen: So let’s take it back to the issue
Rossen: perhaps we can have a proposed resolution by the next time
Does `overflow` apply to table-wrapper or table-grid? css-tables
contradicts CSSWG resolution
----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10881
oriol: this is conflict regarding what box overflow applies to
oriol: spec says that by default properties that you set on a table
element apply to the grid not the wrapper
oriol: and then for overflow it originally was not defined in CSS2
but then it was added in an errata that the overflow applies
to the box not the wrapper
oriol: that was a resolution but only part of it got in CSS2
oriol: but then in CSS3 that became the opposite
oriol: so we should decide if it applies to the box or the wrapper
oriol: elika is of the opinion that is more useful on the grid
oriol: I tested if you use contain: paint it applies to the wrapper
oriol: so would be Ok to apply to the grid
oriol: reason tables-3 says it applies to the wrapper it is because
of overflow oriol: which that applies to the wrapper
oriol: so need to decide if it applies to the grid, affects transform
styles of the grid or the wrapper, should it apply to the same
box?
oriol: not that familiar with transforms
Rossen: Comments?
dholbert: we got a bug filed on this a while back in firefox
dholbert: spec maybe aligns with what gecko is doing
dholbert: I did file bugs in chromium and webkit, but don't know the
progress of those
dholbert: this is about the overflow applying
dholbert: IIRC the spec says wrapper
iank: preference to apply to the wrapper making all of the ?? and
transform style props to apply to the wrapper
iank: like clip and clip-path
iank: just for consistency
iank: suspect it is like...debatable which is most useful
iank: if someone wants to clip in the wrapper, then we allow clipping
on the section elements which make that possible
iank: so I would like to keep everything on the wrapper
emilio: main difference here is whether caption and so on get clipped
emilio: as an author I expect the ?? behavior that what scrolls
decides the content of the table
emilio: otherwise bottom captions become useless in scrollable tables
emilio: would be odd to push ??? to the bottom of the scrollable table
iank: you can't scroll right?
oriol: values other than visible or hidden
iank: overflow: scroll on a table does not do anything right now
iank: like overflow hidden is treated as clip
iank: so therefore preference to keep everything on the wrapper
emilio: other thing we could do is apply to both, but could have
observable difference
emilio: in that case no strong preference though
emilio: the caption thing still applies though right?
emilio: I guess not, because you clip outside of the captions vs
inside
iank: yes
<iank> I don't think we'll be able to make scrolling work from a
compat point of view.
fantasai: same thought as emilio: if we could make it scrollable
obvious thing would be to scroll the table itself.
bramus: people want that, along with sticky headers
fantasai: if we want to do that eventually, would taking a decision
to do it on the wrapper cause a problem?
iank: tables and overflow:scroll have been around for long enough
iank: they cant really be made scrollable because of style constraints
iank: if you set `height` it does not add … intrinsic block sizes
override that
fantasai: in that case we'd need a new table-layout algorithm to make
that work
iank: not an easy path to make tables scrollable
iank: substantial rework to how they work
iank: what was your point about sticky headers?
iank: we have sticky top rows, but sticky cols is a different problem
Rossen: we are at time
Rossen: not sure we can resolve right now, I think?
Rossen: table scrolling will take up more time
Rossen: seems like an interop nightmare
iank: don't think we need to make tables scrollable int he near term
iank: could back ourselves in a corner
iank: if we ever make them scrollable, then we can change things
iank: sticking on the wrapper
fantasai: as you note, we'd need an opt into a different algorithm,
so we could use that as a switch for overflow as well
iank: putting it on the wrapper does not paint us into a corner
Rossen: So can we decide on that?
iank: if no-one objects, then yes
PROPOSED RESOLUTION: overflow applies to the wrapper box
RESOLVED: overflow applies to the wrapper box
Received on Thursday, 27 February 2025 00:37:28 UTC