- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 13 Oct 2021 18:58:33 -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.
=========================================
CSS Color
---------
- RESOLVED: Define gamut-mapping using OKLCH and OKdeltaE (Issue
#6642: Add OKLab, OKLCH)
- RESOLVED: For non-legacy color formats, use OKLAB for interpolation
by default (instead of CIE LAB) (Issue #6642)
- RESOLVED: Add syntax to represent OKLAB and OKLCH colors (Issue
#6642)
- RESOLVED: Add oklab() and oklch() (Issue #6642)
- RESOLVED: Add these as keywords to color-mix() (Issue #6642)
- RESOLVED: Add these to color adjustment functions also (Issue #6642)
Scheduling
----------
- RESOLVED: CSSWG meeting scheduled for 8am Pacific next Wednesday,
first item issue #6520
Flexbox
-------
- RESOLVED: No substantive change to spec, but clarify the text to
avoid confusion (Issue #6693: Content size suggestion of
large flex items)
Contain 3
---------
- RESOLVED: Defer state queries to L2 (Issue #6402: Define a syntax
for state-based container queries)
CSS Values 4
------------
- RESOLVED: Add root-relative variants of *all* the font-relative
units, named r* (Issue #6034: Adding new relative units
RCH and REX)
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2021Oct/0006.html
Present:
Adam Argyle
Rossen Atanassov
Tab Atkins
Oriol Brufau
Emilio Cobos Álvarez
Elika Etemad
Simon Fraser
Megan Gardner
David Grogan
Brad Kemper
Jonathan Kew
Chris Lilley
Ting-Yu Lin
Peter Linss
Alison Maher
Morgan Reschenberg
Florian Rivoal
Dominik Röttsches
Miriam Suzanne
Lea Verou
Regrets:
Rachel Andrew
Chris Harrelson
Scribe: fantasai
Scribe's scribe: florian
astearns: 2 conflicting requests on item 2: to get to it today and to
not get to it today, so will wait for drott to ask what to
do
CSS Color
=========
Add OKLab, OKLCH
----------------
github: https://github.com/w3c/csswg-drafts/issues/6642
Chris: I gave a presentation on this, and documented my reasoning in
depth
Chris: My first request is, in the gamut-mapping section, we use
OKLCH instead of CIELCH
Chris: And we use OK delta E instead of CIE delta E
Chris: Because much less computational complexity
Chris: And also much better results in blue/purple region
Chris: I otherwise can't produce a good result that I like
Chris: I posted some results in the last few comments
Chris: You'll need to use ??? because it uses display-3
florian: I watched presentation, you made a compelling case
florian: The only worry is it's new, and some things maybe need to be
discovered
florian: But overall seems compelling, including this first point
Chris: My thoughts also, which is why I put so much effort into it
Chris: It's also been implemented in various libraries for JS,
Python, etc. by now, so have more confidence now
lea: I had similar concerns as Florian, but given explanation that we
primarily want to use it for gamma-mapping, it's OK
lea: If authors actually want to use the oklab() or oklch() functions
instead of the established lab() and lch() ones, I suppose they
have a reason, so I see nothing wrong with it either
lea: So see no problem for having this
astearns: Is it implemented in any OSes?
chris: To my knowledge, no, only in color libraries
chris: but it is extremely trivial
astearns: So you don't expect objections from implementers?
chris: I do not
astearns: Anyone with gamut-mapping opinions?
astearns: proposed resolution is to use OKLCH and OKLIE for
gamut-mapping
RESOLVED: Define gamut-mapping using OKLCH and OKLCH
chris: In the interpolation section, currently say that legacy
formats interpolate in sRGB and newer formats interpolate by
default in CIE LAB
chris: would like to change that to OKLAB by default, because it will
give better results
florian: I support this
<TabAtkins> +1 from me
<lea> No objection
* fantasai defers to chris
smfr: If gradient uses legacy color at one end and non-legacy at the
other end
<TabAtkins> "legacy" is anything defined in Color 3
lea: fancy new algorithm
smfr: spec should say that
lea: it does
astearns: any other comments?
RESOLVED: For non-legacy color formats, use OKLAB for interpolation
by default (instead of CIE LAB)
chris: This gives us internal ability, but users can't use it
chris: So suggest to add oklab() and oklch() functions
chris: keeping existing lab() and lch() functions as-is, since people
are used to it
chris: So question is, should we add this, and also, what syntax?
astearns: If we're using interpolation, don't we need to add syntax
for it anyway?
<fantasai> to represent colors in the middle of interpolation, e.g.
<lea> +1, if the browser implements it, it makes sense to expose it
to authors too
florian: It does make sense to add it
florian: Only other possibility would be to use color()
chris: color() only takes rectangular forms, not polar form, and
polar form is more useful here
florian: I support the suggestion, just want to understand
alternatives
florian: If we add directly as a function, options are lab() and
oklab(), or cielab() and lab()
florian: Given current tools report (unprefixed) lab as CIE LAB,
Chris's suggestion seems to make sense to me
astearns: Anyone with concerns adding this at all?
<fantasai> +1 to add
<argyle> +1 to adding
astearns: Proposed resolution is to expose these by some syntax
astearns: Any objections?
smfr: So if you specify lab() colors, they'll interpret in oklab()?
Is that OK?
chris: They would unless you ask them to interpolate a different
color space
lea: We did discuss having two colors interpolate in their shared
space, if any
lea: but that doesn't work well for RGB formats, because the
interpolate badly in RGB
chris: In general you should see very similar results
astearns: Any other concerns to adding?
RESOLVED: Add syntax to represent OKLAB and OKLCH colors
astearns: OK, so next question is, do we like the oklab() and oklch()
proposed syntax?
[silence]
<TabAtkins> Sufficiently okay with this. ^_^
RESOLVED: Add oklab() and oklch()
chris: Do we add to color-mix()?
lea: That should be automatic
RESOLVED: Add these as keywords to color-mix()
chris: We have a color adjustment syntax, should be able to do that
with OKLAB and OKLCH as well
astearns: proposed to add these to relative color syntax
RESOLVED: Add these to color adjustment functions also
astearns: fwiw, I would consider the last two reasonable to do under
editor's discretion
Fonts & Nesting
===============
@supports inside @font-face
---------------------------
astearns: Asked to defer because of illness, but also asked to
unblock shipping
astearns: I think that means we need to defer this three weeks (since
i18n and a11y next)
chris: Does it make sense to have another one-off meeting on fonts?
fantasai: What about taking the hour before the CSSWG meeting
fantasai: next week
RESOLVED: CSSWG meeting scheduled for 8am Pacific next Wednesday,
first item issue #6520
Flexbox
=======
Content size suggestion of large flex items
-------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6693
<dgrogan> https://jsfiddle.net/dgrogan/ug9rsf2a/
dgrogan: We recently rewrote some sizing code. Blink and Gecko agree,
but counter to spec
dgrogan: If you have an image item that is stretched in the cross
axis, do you reflect that stretched size through aspect
ratio for min-content sizing
dgrogan: neither engine does so, but spec seems to say to do so
dgrogan: Currently just arguing over what the spec says
dholbert: I think it makes sense. It also applies to grid
dholbert: Whatever sizing ends up, make sure to be similar between
flexbox and grid
dgrogan: Not familiar with grid, but iirc grid uses different minimum
calculation
dgrogan: so outcome is maybe not the same
iank: Talked about a very similar case in grid last month
iank: Basically, there's a bunch of testcases in grid that test this,
looking at one axis looking at other for min-size
<TabAtkins> Yes, cross sizing shoudl transfer to main axis. Unless
there's a wrinkle I'm missing, I agree with a 50px
height, maintaining the aspect ratio.
<astearns> +1 to maintaining the aspect ratio
fantasai: From what I recall, the intention of the spec is that the
size would transfer
fantasai: If you imagine a large image in a short row flex container,
you wouldn't want its natural width to be the minimum,
you'd want the width reduced in proportion to how the
height is reduced by the cross size
fantasai: if you don't do that, you're going to end up distorting the
aspec ratio
dgrogan: I think we agree that's the behavior we want, though engines
don't have it today
dgrogan: This was a long confusing thread on interpreting the spec,
would be good to make it clearer
fantasai: I think that's something Tab and I would have to figure out
offline :)
<TabAtkins> yup, don't want to commit to a particular way to write it
until i have time to think about it ^_^
astearns: if anyone has any suggestions?
TYLin: Note that transfer size and ? are ???
TYLin: and ?? affects content-size suggestion
<TYLin> I think the transfer size suggestion and content size
suggestion can be merged into one concept, and explicit
saying that stretched cross-size should be used in content
size suggestion.
astearns: Is the resolution for this issue no change to spec other
than clarification?
dgrogan: I think that's accurate
iank: Blink will make this change and update the testcases that are
wrong
<dgrogan> +1 to TYLin, I think this resolution effectively makes
transfer size suggestion redundant
RESOLVED: No substantive change to spec, but clarify the text to
avoid confusion
Contain 3
=========
Define a syntax for state-based container queries
-------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6402
miriam: Resolved recently on style-based queries
miriam: This is about being able to query some state of the container
such as being in-view or being stuck (while position:
sticky), etc.
miriam: There's also been some discussion of doing this through
pseudo classes
miriam: but unlikely we can query the element itself and change its
styles
miriam: fantasai and I were thinking to defer this to the next level
<TabAtkins> +1 to deferring while we figure this out
astearns: Any comments/concerns?
<TabAtkins> nope, fine with the rest
Rossen: What are we losing in L1 if this wasn't well-defined?
miriam: We would be leaving this functionality out entirely. Can't
query these aspects of container state
Rossen: What type of scenarios would be broken or impossible?
miriam: I don't think this was an expected feature, so doubt anyone
will miss this
miriam: but things it might add are e.g.
miriam: header that change size when it becomes sticky
miriam: being able to make changes to its stuck state, or maybe
trigger animations when it comes into view -- but work
happening on that in other places
miriam: Those of the main use cases we've thought through so far
fantasai: The reason I wanted to defer wasn't that we weren't sure
fantasai: but that a lot of these have complicated interactions
fantasai: In the sticky case for example, if we have a way to select
when something is stuck
fantasai: then it changes not only that size, but the layout of the
page too
fantasai: Finding a way to prevent that isn't the way it's working
right now
fantasai: These are important use cases to work on, but the answers
are very complicated
fantasai: so I don't think it makes sense to deal with them in the
same level as other things that are much more solid
<miriam> +1
Rossen: Unsure about cost-benefit tradeoff here
Rossen: don't want to be broken by default
fantasai: This isn't undefining anything, this is just deciding not
to add a feature
fantasai: not going to break anything
astearns: My thought is that if we are defining all of the things
that this feature would depend on without thinking about
the implications of this feature, we might paint ourselves
into a corner
astearns: Only reason to keep in L1 is to make sure L1 is defined
compatibly
astearns: but I'm not concerned about that dead-end
Rossen: That's my concern also, so want to keep it in L1 so it nags us
<TabAtkins> I'm sorry, but I am still utterly confused by what Rossen
is referring to by "breakage". This is a proposal for
brand new functionality; deferring it, by definition,
can't break anything. (The use-case just remains unsolved
for now, but it's been in that state for years already
with no progress.)
<argyle> related https://github.com/w3c/csswg-drafts/issues/5979
argyle: It's a nice to have
argyle: and also introduces a lot of very complex problems to solve
argyle: Shared a GH issue of how to get around the looping issue for
:stuck , e.g.
argyle: It's complicated
argyle: but things folks want to do are in L1 already
argyle: There are nice queries like overscroll or whatever, that we
could have, and maybe we could allude to the possibility of
doing that
argyle: Maybe we could do one or two, not all of them
argyle: punt additional use cases and additional state queries to L2
argyle: I'm excited about the ideas, but ok to defer
astearns: I just want us to keep this thing in mind and not block off
development
astearns: I think it's fine to defer to L2, anyone object?
RESOLVED: Defer state queries to L2
<Rossen> call dropped... not object but like to have the note added
CSS Values 4
============
scribe: TabAtkins
scribe's scribe: fantasai
Adding new relative units RCH and REX
-------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6034#issuecomment-925972959
fantasai: Request for rch, representing the root ch size, and rex for
root ex size
fantasai: I think adding rch totally makes sense, and adding ric as
analog for ic
fantasai: don't quite see the use-case for rex, tho it's simple to
implement
fantasai: So my suggestion is just to add rch and ric for now
fantasai: And see if there's a need
fantasai: but jfkthame suggested we just do the full set of
font-relative units
TabAtkins: I agree with jfkthame, having half or more available and
some not seems bad for authors
TabAtkins: if adding more than one, add all of them
fantasai: So proposed resolution is to add r* variants of all the
font-relative units
Rossen: Adding stuff is easy, removing is very difficult
Rossen: I'm not hearing strong use-cases
Rossen: We can always add later
Rossen: Would be better to have a hygiene of use-cases we are solving
as we expose more
Rossen: Otherwise later we scratch our heads over something that's
not quite baked
Rossen: So unless we have strong use-cases, let's just add things the
ones we know about now
astearns: So are you suggesting only adding rch?
Rossen: Only rch and rex, yes
astearns: I'm only seeing a use-case in the issue for rch
fantasai: and ric
fantasai: I don't particularly see a strong use-case for rex
fantasai: But whether we add it now or later, we'll have to reserve
that name, because we'll want all the units, if they ever
get a root-relative variant, to follow the same pattern
fantasai: So in terms of what it allows for our APIs in the future,
the name is reserved anyway; we're not limiting ourselves
either way
TabAtkins: Normally I'm 100% behind what Rossen just said, and
expressed strongly for other proposals
TabAtkins: but the issue is that there is more than one competing
concern here
TabAtkins: and author confusion over what's allowed or not is a
significant issue here
TabAtkins: If only one rem, that's easy to remember. If all units,
that's easy to remember
TabAtkins: If just some arbitrary subset is allowed, then that is
confusing
TabAtkins: If there was a significant implementation complexity, or
even a moderate one, then I'd be sympathetic
TabAtkins: but after adding one root font relative unit, adding more
is very cheap
TabAtkins: So adding all of them is what makes the most sense for
authors, from usability perspective
<smfr> agree with TabAtkins
Rossen: That's a compelling point
Rossen: I did factor what you said in, in the way it was originally
proposed
Rossen: So I'm less concerned now
astearns: So proposed resolution is to add all the root-relative
font-relative units?
<argyle> +1
astearns: Concerns? Objections?
RESOLVED: Add root-relative variants of *all* the font-relative
units, named r*
Received on Wednesday, 13 October 2021 23:00:12 UTC