- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 10 May 2023 18:55:26 -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.
=========================================
Upcoming F2F
------------
- RESOLVED: Tue-Fri July 18-21, Apple location in California
CSS Contain
-----------
- RESOLVED: Proceed with ResizeObserver solution in HTML spec (Issue
#8542: content-visibility: auto visibility check timing
needs details)
CSS UI
------
- RESOLVED: Add a new property (provisionally "form-sizing: normal |
contents") that turns off the "half-replaced" sizing of
form controls and makes them content-based like normal
elements (Issue #7542: Allow <textarea> to be sized by
contents)
View Transitions
----------------
- RESOLVED: Extend view transitions to cover cross-document
same-origin navigations (Issue #8804: Support
ViewTransitions for same-origin cross-document
navigation)
CSS Color
---------
- RESOLVED: Make color-mix() and RCS using rgb, hsl and hwb return
round-trippable, unbounded results in color(srgb ...)
(Issue #8444: Allow out-of-gamut HSL/HWB colors
(previously "Move gamut mapping to a future spec"))
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2023May/0011.html
Present:
Rossen Atanassov
Adam Argyle
Tab Atkins
David Baron
Oriol Brufau
Emilio Cobos Álvarez
Yehonatan Daniv
Elika Etemad
Robert Flack
Daniel Holbert
Brad Kemper
Jonathan Kew
Ian Kilpatrick
David Leininger
Chris Lilley
Peter Linss
Florian Rivoal
Khushal Sagar
Miriam Suzanne
Bramus Van Damme
Lea Verou
Regrets:
Rachel Andrew
Chair: Rossen
Scribe: bramus
Upcoming F2F
============
rossen: Mail on private list with f2f details
<dbaron> https://lists.w3.org/Archives/Member/w3c-css-wg/2023AprJun/0076.html
fantasai: Need to resolve on date and location
fantasai: Best option tue-fri at Apple location in SV
<dbaron> so Tue-Fri July 18-21
<khush> Does mon-thurs work?
<khush> Same week
rossen: Is going to be only f2f besides tpac, so want to add some
extra time for talks
rossen: Questions to hosts about masking protocol, food, etc. –
conversation must happen.
chris: and disability
<fantasai> Likely sunnyvale
<fantasai> possibly cupertino
khushal: Is mo-thu also an option?
rossen: It was a less desired option.
rossen: Let's resolve on this, so ppl can book flights
rossen: I will work with tess and miles to get all the other details
rossen: Thanks to fantasai for hard work behind the scenes
RESOLVED: Tue-Fri July 18-21, Apple location in California
CSS Contain
===========
content-visibility: auto visibility check timing needs details
--------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8542
emilio: General proposed idea of merging with resize observer makes
sense
emilio: sounds like a good plan
emilio: Needs to be done in the HTML spec instead of CSS I think
rossen: Ok
rossen: Not hearing any objections from google side
rossen: Proposed resolution to proceed with ResizeObserver solution
in HTML spec
emilio: HTML spec would have to reference contain spec but dont
think extra work in css specs is needed
rossen: Objections?
RESOLVED: Proceed with ResizeObserver solution in HTML spec
CSS UI
======
Allow <textarea> to be sized by contents
----------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7542
tabatkins: Had discussion about ability to autosize … we landed on
few possible options
tabatkins: One is we do simply define that min-content and related
keywords when used on … will flex the content size as if
they were normal elements
TabAtkins: Option 2 is to add new keywords that mean that, so
current behavior would not change
TabAtkins: Option 3 is we add a new property that toggles these
elements into behaving like elements filled with their
content.
TabAtkins: I believe that option 1 is a no go. These existing
keywords are used quite widely and would be incompatible
in practice
TabAtkins: Real concern is new keyword on sizing props or with a
separate property toggle
TabAtkins: I believe that fantasai prefers keyword based, and iank
prefers option 3
TabAtkins: There are a number of places in the sizing algos that
invoke min-content behavior implicitly
TabAtkins: e.g. textarea width 100% in table
TabAtkins: This means that there are lot of cases that would
implicitly trigger the older non-content aware behavior
if we gave authors access to these keywords
TabAtkins: If we have a way to say 'act like a normal element' it
would be fine.
TabAtkins: iank's experiment turned out to confirm this, and its a
trivial implementation, and its predictable
TabAtkins: 'just act like a normal element' switch seems like to be
the right way
TabAtkins: other ways would be hard to predict
TabAtkins: Would like to move into direction of a form-sizing
property
lea: Do we know option 1 is not feasible with facts or are we just
worried?
TabAtkins: I have not looked at the data, but am virtually certain
that it'll break things
TabAtkins: min-content is used fairly regularly, and might also be
used on inputs and could thus break the page
iank: Other concern is typically inputs are used heavily in
enterprise usecases, and we sort of have an analysis blind
spot, can't entirely rely on http archive data
lea: If compat is not an issue, is then option 1 better for authors?
lea: Maybe we should explore if these concerns are founded? or add
UA css?
lea: Just thinking out loud
TabAtkins: Option 1 and 2 are pretty bad on how often we invoke
intrinsic layout algos
emilio: I agree that going for the toggle seems like the most
straightforward
emilio: To what extent do we want to create this toggle? only
intrinsic sizing? replacing-ness? would they respect display?
emilio: toggle seems most reasonable but would like more details
on it
emilio: I guess that can be figured out
iank: Toggle would only trigger normal intrinsic sizing behavior, so
auto would not be semi-magic anymore
iank: Would change compressibility (?)
emilio: Seems easier to implement and reason about
<lea> would all three approaches also work for adjusting <input>
width by its contents?
<emilio> lea: yes (afaict)
oriol: 4th option? would not require any new value
oriol: Reminds me of what happens when adding size containment with
contain-intrinsic-size
oriol: UA CSS? authors could override
oriol: seems like less compat issues
iank: Does not work because some elements are a fixed length, but
others are not (depending on UA)
iank: Some are content based with an implicit minimum
<bradk> Is this just for text-entry controls, or for buttons, etc
too? Presumably not for iframes?
Rossen: Looks like we are circling around toggle option
emilio: Maybe we can also use this prop to remove min line height of
normal
emilio: Can be discussed at other time
emilio: Its needed for compat
iank: We will likely get an implementation up, and then work through
the inputs one by one
iank: Should look at line height thing indeed
Rossen: Let's try to resolve
<bradk> +1 for toggle
fantasai: I have doubts
fantasai: Trying to understand all the compat impact
fantasai: Ok with resolving, but unsure about the direction we are
about to take
Rossen: My understanding was you were proponent for option 3
TabAtkins: Nope, other way around
iank: Using auto sizing breaks option 1 and 2 very easily
iank: eg inputs in table
iank: Lot of magic needed for 1 and 2
Rossen: Lets make progress here, can always revert
<TabAtkins> proposed resolution: add a new property (provisionally
"form-sizing: normal | auto") that turns off the
"half-replaced" sizing of form controls and makes them
content-based like normal elements
<Rossen> add a new property that toggles these elements into
behaving like elements filled with their content.
Rossen: Not hearing objections
RESOLVED: Add a new property (provisionally "form-sizing: normal |
contents") that turns off the "half-replaced" sizing of
form controls and makes them content-based like normal
elements
View Transitions
================
Support ViewTransitions for same-origin cross-document navigation
-----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8804
khush: Goal of issue is to start working on cross-document support
for View Transitions
khush: Want to walk everyone to overall approach, to later turn in
more concrete spec test
khush: Lot of details need to be sorted out
khush: Issue contains links to sub issues
khush: Also want to start an L2 of the spec for this feature, as its
a fairly big thing
Rossen: Makes sense, can we timebox to 5 minutes?
Rossen: I don't want to deep dive in all subissues
khush: I'll try
khush: ** goes over issue **
khush: That's it
khush: Looking for feedback and resolution on L2
Rossen: Do you have tag review?
khush: Yes, for same-document API. Don't have explicit tag review
for MPA, but want to get rough outline first and then present
tag review
Rossen: Please start tag review ASAP. This is going to have a lot of
discussion
Rossen: Lots of security/privacy concerns will most likely arise
Rossen: You don't need an ED, only an explainer
khush: We are not targeting for cross-origin navs. explainer will
make that explicit
Rossen: Any reasons not to continue this proposed outline?
<TabAtkins> Lot of details to nail down, but I'm very happy with the
initial work.
Rossen: This is only a beginning
Rossen: Any objections to cover cross-doc same-orig navs?
Proposed resolution: Extend view transitions to cover cross-doc
same-orig navigations
RESOLVED: Extend view transitions to cover cross-document
same-origin navigations
Rossen: Maybe in L1, though?
khush: ** asks details on L1/L2 distinction and CR process **
fantasai: ** spills the details **
khush: thanks
Allow out-of-gamut HSL/HWB colors (previously "Move gamut mapping
to a future spec")
-----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8444
<Rossen> https://github.com/w3c/csswg-drafts/issues/8444#issuecomment-1518663196
chris: For round tripping we will allow …. that is not up for
discussion but it does not work.
chris: Can we relax that?
chris: Proposal is that instead we return color[srgb] which allows
the round tripping
chris: It is a breaking change in WPT though
chris: Did not hear any negative feedback so far
Rossen: Opinions other than
https://github.com/w3c/csswg-drafts/issues/8444#issuecomment-1518663196?
iank: Not sure anyone from google has seen this
chris: It is a google proposal
iank: Ah, missed that
emilio: It seems reasonable, but concerned about color-mix but that
has shipped in Safari and is implemented in Chrome
<argyle> shipped, test it here https://color-mix.style
emilio: For color-mix result depends on the colors being legacy ones
or not?
emilio: Maybe we can do "if the colors are relative"?
emilio: We return legacy rbg if you mix legacy rbg
chris: Problem is if you mix in HSL and get OOG color, it does
clamping
emilio: But only happens if you mix legacy colors in HSL?
chris: I believe so, yes
emilio: I guess not clamping would be … if we can get away with
returning color() it might be OK
chris: We have to say what happens in the spec
emilio: No strong opinions as long as its consistent
Rossen: The more we prolong this, it will get worse
Rossen: Any objections to chris's proposal?
emilio: Only in hsl?
chris: rgb, hsl, and hwb
chris: Inputs to mix in HSL can be anything
chris: If you mix in hsl, output needs to be hsl, and wil serialize
as rgb
emilio: I thought we serialize as a color fn
<TabAtkins> I think you've gotten pretty confused Emilio - `color-mix
(hsl ...)` currently will resolve to an HSL color
(serialized with `hsl()`).
<emilio> TabAtkins: oh, I thought we didn't serialize those as
hsl(...) at all
<TabAtkins> once they're resolved to a definite color they gotta be
serialized as *something*
<chris> yeah and they get serialized as legacy rgb(r,g,b)
<emilio> ISTR at the point I wrote the gecko issue I wrote it so
that we serialize in color(srgb...)
<emilio> But that changed apparently, ok
Rossen: Let's move on
Rossen: proposed resolution: make color-mix() and RCS using rgb, hsl
and hwb return round-trippable, unbounded results in
color(srgb ...)
RESOLVED: Make color-mix() and RCS using rgb, hsl and hwb return
round-trippable, unbounded results in color(srgb ...)
Rossen: Might consider Scroll-driven breakout
Rossen: Otherwise can start with scroll-animations next week
Received on Wednesday, 10 May 2023 22:55:58 UTC