- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 31 May 2023 19:08:48 -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.
=========================================
View Transitions
----------------
- Next week the group will take up issue 8878 (Move CSS View
Transitions Level 1 to CR) for resolution. In advance of that,
khush will handle the remaining issues and fantasai will do a
review of the whole spec.
CSS Color
---------
- The group did not want to change the resolution in issue #7948
(What if legacy colors *also* interpolated in Oklab by
default?). Instead, they will have one of the browsers ship it
in a beta channel to validate it does not cause breakage.
- RESOLVED: Colors don't add; add a note asking for use cases and a
warning specifying we might change in the future (Issue
#8576: Addition of `<color>` is way underspecified)
- RESOLVED: Accept the changes [changes:
https://github.com/w3c/csswg-drafts/issues/8564#issuecomment-1489397432
]
(Issue #8564: Serialization of percentages in
color-mix())
CSS Grid
---------
- There was not consensus issue #7661 (Application of
grid-positioning properties to static position of grid children
is inconsistent) and there was interest in getting more author
input to guide the solution.
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2023May/0024.html
Present:
Rachel Andrew
Rossen Atanassov
Tab Atkins
David Baron
Oriol Brufau
Emilio Cobos Álvarez
Yehonatan Daniv
Elika Etemad
Daniel Holbert
Robert Flack
Paul Grenier
Brad Kemper
David Leininger
Vladimir Levin
Chris Lilley
Peter Linss
Alison Maher
Eric Meyer
François Remy
Florian Rivoal
Khushal Sagar
Fernando Serboncini
Miriam Suzanne
Lea Verou
Sebastian Zartner
Regrets:
Chris Harrelson
Jonathan Kew
Bramus Van Damme
Chair: Rossen
Scribe: emeyer
View Transitions
================
Move CSS View Transitions Level 1 to CR
---------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8878
<vmpstr> https://drafts.csswg.org/css-view-transitions-1/#changes
khush: Latest published specification has changes from all the issues
<khush> https://www.w3.org/TR/css-view-transitions-1/
<khush> https://www.w3.org/TR/css-view-transitions-1/#changes
khush: I think the spec is ready to go for CR, with a couple of
horizontal reviews pending
khush: There are new features we want to take up in the next
version, especially cross-document navigation
<fremy> @kush, there is a typo in the Changes section
(documentElememt > documentElement)
Rossen: What's the timeline for the horizontal reviews?
<Zakim> chris, you wanted to comment on I18n review status
chris: I think we can say we've dealt with questions and can move
forward
<chris> https://github.com/w3c/csswg-drafts/issues/8230
fantasai: There are several issues inline in the spec, and we should
address them
fantasai: I can also do an i18n review
fantasai: For view-transition-group, the user stylesheet is top left
and I think maybe it should be block-start inline-start
<fantasai> https://www.w3.org/TR/css-view-transitions-1/#::view-transition-group
khush: The idea is that we're positioning using transforms, which
don't care about logical coordinates
fantasai: Generally we try to close out all issues, but I don't
think you have a lot
khush: Everything with the label …transitions-2, those don't count
fantasai: I think the top left versus block/inline is the only thing
outstanding
khush: Is it okay for us to resolve that once the positioning
question is resolved, we can go to CR?
Rossen: I don't see why we can't come back next week once the last
question is resolved
khush: I'm good with that
fantasai: Are the inline issues in the spec things we can unblock?
khush: Things in the index are for better cross-referencing
khush: None of them are functional changes
Rossen: The question is, how many of those can be tackled before
published? Once it's CR, people will start referring to it,
so we'd like it to be more presentable
khush: I'll address those
fantasai: If you need something else published, let me and Tab know
Rossen: I think that's all we can do for today
<fantasai> ACTION: fantasai to do a full review of view transitions
spec
* RRSAgent records action 1
CSS Color
=========
What if legacy colors *also* interpolated in Oklab by default?
--------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7948
chris: We resolved but we got some pushback on github; people
thought we were too hasty and they were worried about
backward compatibility
chris: The current issue is, are we sticking with our original
resolution, are we backpedaling on it, will there be an
origin trial?
lea: My recollection is we didn't just resolve to use okLAB
everywhere, we resolved to explore the potential implications
Rossen: I would be surprised if people are pushing back on us being
more careful
<fantasai> the resolution definitely wasn't worded that way...
fserb: I don't think this was well captured on the issue; that
wasn't my understanding
fserb: Is this too much for an origin trial? It feels like it has
the potential to break sites in weird ways
fserb: There's not firm ground here
fserb: It felt a little bit too much, even for an origin trial,
because there are expectations of what colors look like
Rossen: Origin trials are the best way we have to test safely
Rossen: Anything we introduce can have the effect of changing things
in ways authors don't expect
Rossen: If this is an extension of an existing features, there are
different risks that can be taken
Rossen: But anything introduced generally needs an origin trials to
make sure we don't upset expectations
Rossen: This doesn't seem too heavy in terms of trial
dbaron: I don't think this is the sort of thing origin trials are
good at
dbaron: Trials are good for things like APIs
dbaron: This is making a change that might be a compatibility
problem that might break sites
dbaron: There is the concept of a reverse origin trial, but I think
that's useful when we're more strongly committed to making
breaking change but might need a bumpy rollout
dbaron: I didn't get the sense we were that committed to it
<lea> wouldn't deploying the change on beta/canary channels address
this?
<fantasai> +1 lea
<fserb> +1 to what dbaron said
emilio: I agree with dbaron
emilio: In general, an origin trial seems do-able, but I was going
to ask if this has to be an origin trial as we know them
lea: Would deploying on beta or canary channels address this?
lea: In my experience, when authors do gradients, they have
expectations about the color stops, not what's between the stops
lea: Also, how does a reverse origin trial work?
iank: Generally it's when we're making a known breaking change, and
we want time to roll it out
iank: An origin can opt out while they work to fix their site
iank: Generally only used when we really really want to do
something, as they can drag on for quarters or years
fserb: I agree authors usually don't want a particular value outside
stops, but the gradients are different enough that even the
stops can look odd
fserb: Colors could get darker or lighter than expected
fantasai: I support Lea's too points: the best way is to roll out
through beta channels and collected feedback, and also
that changing interpolation isn't nearly as bad as
changing stops
fantasai: Authors who really care about the interpolation tend to
add color stops to force them
<lea> +1 fantasai
<chris> I agree that if a specific matching color is relied on,
there will be a color stop there
fantasai: We have to consider cases where this will make things
better, not just those where things will be worse
fantasai: We expect this change to make the web better overall
Rossen: Is there anything we need to do about the previous
resolution?
chris: Do we stick the previous resolution in the spec, or put it in
with caveats?
lea: In theory, fserb's point about breakage is possible if not
likely, but we should explore that
lea: It sounds to me like we have consensus that we should do this,
but perhaps we should make the resolution more explicit that we
want to explore this
Rossen: I agree with you there
fantasai: If we're not going to do this, then we can't put it in the
specification, so we need an implementor to say they're
willing to do it
Rossen: Any implementor interest?
<lea> How could implementors be interested in testing this if we
have no idea *how* to test? They cannot commit to an unknown
amount of work
emilio: It should be relatively easy to prototype and test out
<lea> Op, I guess I was wrong :)
<fantasai> Release it in beta, and see what happens
<fantasai> If there aren't lots of bugs reported, then we should be
fine to release more broadly
fserb: I'd like to see a way to measure the impact of this
fserb: How would we extrapolate from beta to stable?
fserb: Not against this on principle
lea: Another testing channel could be to tack it onto a flag that a
lot of developers already have enabled e.g. experimental web
platform features flag
<fantasai> +1
Rossen: There was some implementor interest, and how we implement
testing is really their call
Rossen: With that said, it sounds like the text that goes into the
spec is the previous resolution
chris: Okay, thanks
Rossen: So, no change here
Addition of `<color>` is way underspecified
-------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8576
chris: The original text about adding color was from the sRGB days
and it assumes consistent color spaces
chris: It turns out nothing actually depends on this
chris: We could say colors don't add, or we pick something good
since there's no backwards compatibility issue
chris: I propose the latter
chris: so I have everything I need to add to the spec
<dbaron> (you're sure smil animation doesn't depend on this?)
TabAtkins: I'm unclear when it would be useful to do an additive
animation to a color, I suspect we should just go the
simplest route and say colors don't add
chris: That is simple and easy, yeah
TabAtkins: Additive transforms make more sense, but colors seem a
lot more integrated and meaningful
<fserb> +1 to tabatkins
flackr: I commented on another issues that adding colors should be
treated as composition of that color
flackr: This to me feels like the thing you're trying to express
when adding a color to another color
<TabAtkins> composition certainly makes more sense than component
addition
<TabAtkins> though *which* composition is always a question
flackr: I think that interpretation solves the color-space question
flackr: Because it goes to the color space of whatever you're
compositing onto
<TabAtkins> I think the Web Anim use of the word "composited" is
unrelated to the "composition" that flackr just mentioned
<fantasai> https://www.w3.org/TR/web-animations-1/#effect-composition
<fantasai> enum CompositeOperation { "replace", "add",
"accumulate" };
fantasai: The addition of values is defined in web animations and
there's a composite operation that lets you change how
you're doing it
<fantasai> https://www.w3.org/TR/web-animations-1/#the-compositeoperation-enumeration
fantasai: That's where this whole definition came from
fantasai: It seems like replacement is not what's intended
fantasai: I don't know that defining this as replacement is what we
want, long-term
chris: What was described as compositing on top of is interpolation,
which is defined a sentence earlier
chris: So in one case, we point off to the interpolation definition,
and the other case, we say you can't do it
TabAtkins: Rob is describing compositing, not interpolating
<fantasai> TabAtkins, yes, but follow that link
<fantasai> It's switching between replace/add/accumulate
<TabAtkins> fantasai, yes, that's still not what flackr is talking
about
<fantasai> no, it's not
chris: The only difference is the color space you do the compositing
in, but it's still interpolation
flackr: You do get weird interpolations with opacities involved
<fantasai> I'm saying, that's what's defining that replacement and
addition should be different
<TabAtkins> they're different *if* you define an addition operation.
if you don't, they're the same
<fantasai> There was an assertion that the definition of addition
isn't used
<fantasai> and it is, in WA1
<TabAtkins> it's not used *in practice*, chris said
fserb: I think we should step back and focus on the first question
fserb: My feeling is that even if we don't have a use case right
now, we should lean toward not adding
fserb: Just in case we find reasons to do it in the future
chris: I tend to agree that if we don't have a use case, we
shouldn't spec it
chris: I don't think a lot of thought went into this bit of the spec
because it didn't get exercised
<lea> agreed that not adding is easier to extend in the future vs
some random addition algorithm
fantasai: Are you saying there's no use case, or that there's no way
for the definition to get used in CSS?
chris: That there's no use case
flackr: I do think there are use cases, like modifying underlying
color by some amount as with transforms
flackr: I think the risk of not doing something now is that it could
become a breaking change in the future
flackr: I think if we assume they don't add, then the result is you
get the second color, as it replaces the first
chris: I believe that's correct
Rossen: So this is really a what-if, there's no use case
Rossen: So what do we do?
Rossen: We can remove it from the spec until someone comes up with a
use case
Rossen: We could leave it as is
flackr: I'm very much against the current behavior
chris: Same here
lea: Agreed
<TabAtkins> it wasn't underspecified at the time, fwiw - back when
it was written colors were specified as sRGB
<TabAtkins> clearly not something we want to do now
Rossen: What if we bring all of it back to the whiteboard, and maybe
find some use cases in the meantime?
Rossen: How does that sound?
<fserb> I'm good with this too
chris: So we're effectively resolved they don't add now, and can
change it later
TabAtkins: Plus add a note saying we'd like use cases
fantasai: And that we might change it in the future
Rossen: Objections to the note and warning?
plinss: I'm a little concerned about not doing things when we don't
have use cases
plinss: What's the justification for not doing it?
plinss: Authors might come up with cool stuff once a possibility is
out there
TabAtkins: There's a lot of ways of defining addition, and without
use cases, it's an arbitrary choice
<flackr> add rgb(0, 0, 0, 0.1) /* darken */
TabAtkins: If we decide that for now we don't add at all, authors
can still get what they want by doing their own blending
TabAtkins: We don't have an obvious behavior to bless here
<fantasai> +1
fserb: There are a lot of axes you can change colors on, none of
which are “add"
Rossen: I didn't hear objections, and peter's concern seems addressed
<TabAtkins> flackr: reasonable to argue for the "just composite it"
in the issue, if you do think we should do that
RESOLVED: Colors don't add; add a note asking for use cases and a
warning specifying we might change in the future
Serialization of percentages in color-mix()
-------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8564
chris: In the time since adding this to the agenda, emilio proposed
edits, I made them, they've stood without objection for a
couple of months, can we resolve to accept them?
<TabAtkins> +1 to the edits
<fserb> +1 to the edits
Rossen: I assume people have looked at the edits
<florian> seems fine
Rossen: Any objections?
fserb: Chris, in an older question, do you normalize, or not?
chris: You do not normalize in that case
RESOLVED: accept the changes
<chris> \0/
CSS Grid
========
Application of grid-positioning properties to static position of grid
children is inconsistent
---------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7661
TabAtkins: We discussed a few weeks ago and took it back to the issue
TabAtkins: Question is, how to we calculate the static position of
absolutely positioned children of grid containers?
TabAtkins: Option 1: keep spec as-is, where we apply grid properties
to find a staticpos containing block only if the parent
is the abspos containing block
TabAtkins: Option 2: Simplify in this case and use the content box
of the parent
<fantasai> Option 3: apply grid properties to find staticpos
containing block always (when the parent is a grid)
fantasai: I opened this originally because the spec as is, is not a
behavior we have anywhere else
fantasai: If you have a static position, that's your position
regardless
fantasai: Between the other two behaviors, we can use the content
box edge like in flexbox, or use grid positioning to
contain the static position containing block
fantasai: I think the second options is more powerful and closer to
the intent of static positioning
fantasai: I think we should honor the grid positioning properties
fantasai: Ian did raise that the spec uses padding box as a parent,
which is weird and unusual
fantasai: Regardless of what we do, we should use the content box
and not the padding box
iank: The way the spec is phrased, it gets invoked when auto is in
play
TabAtkins: My main objection here is grid positioning properties are
semantically a unit, giving a position in 2D
TabAtkins: If we go with options 1 or 3, you can be invoking
grid-row to figure a position, but grid-column in a
different grid
TabAtkins: It no longer becomes a simple 2D, it's not semantically
coherent
TabAtkins: I don't think there's a reasonable way to resolve this
TabAtkins: I think static positioning should ignore grid properties
and be simpler
<Rossen> +1 to static pos being as simple as possible
TabAtkins: Anchor positioning is the better solution here anyway; I
don't think there's a strong use case for static
positioning of grid pieces in a works where anchor
positioning exists
TabAtkins: I think we should simplify the model and call it a day
fantasai: I don't think we can resolve today; what I'd like to get
is author feedback here
fantasai: Also, I do think we can resolve on using the content edge
rather than padding edge, since I think we all agree on
that
iank: This is somewhat blocking our subgrid implementation, so we'd
like to resolve this soon
iank: Don't want this to drag out for months
Rossen: We'll start with this next week
Rossen: Hopefully we can get a resolution next week
Received on Wednesday, 31 May 2023 23:09:24 UTC