- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 8 Feb 2023 19:45:41 -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.
=========================================
View Transitions
----------------
- RESOLVED: Remove contain:layout requirement for view-transition to
work (Issue #8139: Clarify rendering constraints for
elements participating in a transition)
- RESOLVED: A non-none view-transition-name acts similar to a non-1
opacity (stacking context, grouping element, backdrop
root) (Issue #8139)
CSS Anchor Layout
-----------------
- RESOLVED: Publish FPWD of anchor-position; Tab will send that
request
CSS Snapshot 2023
-----------------
- RESOLVED: Add Relative Color Syntax from CSS Color 5 to Safe to
Release pre-CR Exceptions (Issue #7883: Start on CSS
Snapshot 2023)
- RESOLVED: Add conditional-4 and cascade-5 to the rough-interop
list (Issue #7883)
- RESOLVED: Publish 2023 Snapshot (after resolutions edited) (Issue
#7883)
- RESOLVED: Chris Lilley is added to Snapshot editor list (Issue
#7883)
- RESOLVED: Add scroll-snap-1 to rough-interop list (Issue #7883)
CSS Color
---------
- RESOLVED: Accept Chris's edits:
https://github.com/w3c/csswg-drafts/issues/7870#issuecomment-1410589234
(Issue #7870: Serialization of named colors)
- RESOLVED: non-RCS rgb() and hsl() can mix numbers/%s when using
the modern syntax (space and slash, not comma) (Issue
#7900: gba()` is legacy so does not support `none`.
Right?)
- The group reviewed the options for what color-contrast would
composite the background against (Issue #7358: color-contrast()
should take transparency into account) but did not have clear
agreement on the best approach before running out of time.
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2023Feb/0004.html
Present:
Rachel Andrew
Jake Archibald
Adam Argyle
Tab Atkins
Oriol Brufau
Emilio Cobos Álvarez
Yehonatan Daniv
Elika Etemad
Robert Flack
Simon Fraser
Mason Freed
Daniel Holbert
Brad Kemper
Jonathan Kew
Chris Lilley
Alison Maher
Eric Meyer
Florian Rivoal
Cassondra Roberts
Khushal Sagar
Alan Stearns
Miriam Suzanne
Bramus Van Damme
Lea Verou
Sebastian Zartner
Regrets:
Chris Harrelson
Jennifer Strickland
Chair: astearns
Scribes: TabAtkins, fantasai
Agenda Setting
==============
astearns: We still have tons of things on the agenda, so they'll
likely be an extra meeting next week
astearns: Open to suggestions on topics
astearns: Think they work best when the extra meeting is a single
topic people can choose to join for
astearns: So I'll have a proposal soon
astearns: We've talked about a f2f sometime in March, but not sure
if the hosts are actually going to come thru
astearns: waiting on a response from one, we'll see if it happens
astearns: So we should probably talk about a further f2f in april/may
astearns: Changes to the agenda?
View Transitions
================
Clarify rendering constraints for elements participating in
a transition
-----------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8139
JakeA: I linked to an overview
JakeA: Trying to roll two resolutions into one, very related
JakeA: When we first did an experimental impl, we required paint
containment on anything that was gonna be a view transition
group
JakeA: we improved our impl and no longer needed that
JakeA: We're still asking for contain:layout to make it a containing
block, though
JakeA: This is a bad dev exp
JakeA: The transition fails, dunno what's going on, have to look in
devtools for it
JakeA: We've heard from devs they hit the same issues
JakeA: So first proposed resolution is we remove the contain:layout
requirement, and instead we auto-apply those containments to
elements with a view-transition name
JakeA: This is similar to how opacity triggers a stacking
context, etc
florian: So when you turn things on, you're not modifying 'contain'
computed value, but turning them on *as if* contain was set
appropriately?
JakeA: Yeah, doing same as opacity
florian: sounds reasonable
florian: I think content-visibility also turns on some containment
without messing with computed value
<miriam> `container-type` does the same
<dbaron> Agree that it should be consistent with
content-visibility... which I think this is.
<TabAtkins> +1
<argyle> +1
fantasai: Are you planning to auto-apply layout containment?
JakeA: That's the second part of the issue
PROPOSED RESOLUTION: Remove contain:layout requirement from view
transitions
TabAtkins: This is an incomplete resolution - we're just changing it
from "author must specify" to "we automatically add
containment"
RESOLVED: Remove contain:layout requirement for view-transition
to work
JakeA: So adding view-transition makes the element a generate a
stacking context, be a grouping property (forces flat
preserve-3d), and be a backdrop root Same as opacity.
JakeA: Should it also become a containing block?
JakeA: So what should happen to elements inside the transitioning
element that use a containing block outside? We've seen
examples of fixpos.
JakeA: If the behavior is that we capture the texture as-is (the
fixpos is contained in that capture) and we do a transition
where the element moves without the fixpos moving with it
JakeA: it can look odd - the fixpos is now in a different relative
position, but the texture hasn't been updated
JakeA: There's a video in the issue if my description is confusing
JakeA: We considered forcing a containing block to prevent that
effect
JakeA: That requires the dev to move the fixpos out of the captured
element
JakeA: Also considered more complex to exclude the fixpos from the
capture
JakeA: Instead capturing it with their containing block
JakeA: Our conclusion is that forcing a CB requires the author to
change their DOM, which seems bad, and we have real-world
cases that hit this
JakeA: We also want to keep a simple rule that an element with a
view-transition captures the element and its descendants. Not
capturing fixposes breaks that.
JakeA: If we don't fix this though, we get animations that the
author clearly didn't intend
JakeA: The easiest fix seems to be to give the fixpos a
view-transition name, so it view-transitions on its own
JakeA: So our proposal is that view-transitions *do not* force a
containing block
<fantasai> summary comment is
https://github.com/w3c/csswg-drafts/issues/8139#issuecomment-1422602510
btw
emilio: What's the plan for animating transform on the image?
emilio: That seems like it adds complications vs creating a fixpos CB
JakeA: If animating a transform on the old or new view, you're
moving the texture around as a group - you can see it in the
video in the issue
emilio: You need to define the bounds that somehow encloses the
abspos and fixpos, otherwise what you're animating is not...
I think it introduces complications
JakeA: The demo I posted in the issue, I created that by having an
abspos that starts outside the border of the VT element. We
don't do paint containment anymore, so that's fine. You
already have to calculate the size and positions from the VT
elements, even I there's ink overflow (shadows, filters, or
things like positioned descendants)
emilio: So the transform box is the element, and everything that
escapes is just overflow.
emilio: So if you set transform-origin, what are those percentages
relative to?
JakeA: If you're setting transform-origin on the ::view-* pseudos,
it's relative to the border box of that element.
JakeA: We allow replaced content to overflow (ink overflow).
emilio: Right, but ink overflow here includes abspos element that
used to overflow the transitioning element
JakeA: That's true today, right?
emilio: The box relationship is different when you have fixpos
inside a transform vs not
emilio: So it might be weird if it takes the same transform origin
emilio: But maybe it's okay for the transition.
khush: Impl-wise, we use a very similar path to opacity.
khush: Say the element has to be painted atomically. For elements
that overflow you find out where they are relative to the VT
element, and just use object-overflow. The layout overflow of
the element becomes ink overflow of the transition pseudo.
emilio: Okay that answers my question
JakeA: So proposed resolution is view-transition does not create a
containing block for the element
astearns: Proposed resolution is that view-transition makes the
element a stacking context, a grouping element, and a
backdrop root
smfr: This applies at all times, not just while the transition is
running, right?
JakeA: Yes, we think that's more consistent.
smfr: I think a note in the spec about the fixpos behavior would be
useful.
TabAtkins: Are these effects different from contain:layout?
JakeA: Yes, layout containment causes a CB as well.
flackr: I have a concern that this can make it easy for devs to make
large captured elements, but there's another issue about
that and shouldn't block this
flackr: Also this is different from transform, and I just wanted to
make sure there weren't transform-relevant reasons to make
it similar, but khushal's response answers that
astearns: Objections?
RESOLVED: A non-none view-transition-name acts similar to a non-1
opacity (stacking context, grouping element, backdrop root)
CSS Anchor Layout
=================
TabAtkins: Discussed spec in the past, group is interested
TabAtkins: CSS Anchor spec is about letting an element declare
itself an anchor and positioning elements can position
relative to that anchor
TabAtkins: some restrictions on DOM relationships to ensure
non-circular layout dependencies
TabAtkins: so that anchor is laid out fully before figuring out
positioned stuff
TabAtkins: that's about it
TabAtkins: spec has some bugs to fix, especially in the way we
calculate overflow
TabAtkins: nothing that should be a blocker
TabAtkins: FPWD is appropriate
chris: I see some red flags
chris: needs an introduction
chris: security considerations says none, but should say none have
been reported
chris: there's an issue open about examples being wrong compared to
grammar
chris: issue 7628
<dbaron> https://github.com/w3c/csswg-drafts/issues/7628
TabAtkins: That should have been fixed
chris: If we do resolve on this, who's going to request FPWD?
TabAtkins: I will request it and get Elika's help
smfr: Concerned about possible confusion between the HTML anchor
element and CSS anchor positioning
<dbaron> smfr: OK with the name "Anchor Positioning" but concerned
about the shortname
TabAtkins: The anchor stuff in HTML is designed to work with this
TabAtkins: thus using the same name is kind of intentional here
smfr: Are we going to use css-anchor as the shortname?
TabAtkins: That's my current preference
smfr: Yeah, I'm talking about the <a> element
TabAtkins: Ah. This is intended to hook to the anchor attribute in
popovers
smfr: This perfectly illustrates the possibility for confusion
TabAtkins: This feels like an historical concern, but I'm happy to
address it in the introduction
<smfr> title of the MDN <a> document: “<a>: The Anchor element”
fantasai: I think fpwd sounds great. hope we're taking this as
publishing and collecting feedback
fantasai: +1 to FPWD; I hope we're taking this as publishing and
collecting feedback rather than intent to ship
fantasai: hopefully not an I2S immediately
fantasai: So as long as publishing is to broaden review and
feedback, rather than Google deciding it's reading to ship
because there's an official published spec, I'm happy with
this
<dbaron> are folks ok with css-anchor-position-1 ?
smfr: I think the word “anchor” on its own is positioning
astearns: So “anchor-position” as the shortname?
smfr: Yes.
<fantasai> https://www.w3.org/TR/css-position-3/
<fantasai> "CSS Positioned Layout Module Level 3"
<TabAtkins> anchor-position, for consistency
RESOLVED: Publish FPWD of anchor-position; Tab will send that request
Snapshot 2023
=============
Start on CSS Snapshot 2023
--------------------------
github: https://github.com/w3c/csswg-drafts/issues/7883
<chris> For scribe convenience I listed some proposed resolutions
here https://github.com/w3c/csswg-drafts/issues/7883#issuecomment-1421679627
SebastianZ: I wanted to discuss which specs are ready to go into the
snapshot for this year
SebastianZ: I had some suggestions like color-adjust and
conditional-4 and cascade-5
SebastianZ: Chris mentioned RCS of color-5
SebastianZ: So maybe these? Maybe there are others?
astearns: Moving those to which list?
SebastianZ: into the Snapshot 2023
astearns: So first move RCS to "cleared to ship"
chris: We resolved that it was ok to ship, but didn't take the
resolution to add it to that section
astearns: Objections?
RESOLVED: add Relative Color Syntax from CSS Color 5 to Safe to
Release pre-CR Exceptions
astearns: Second is to take conditional-4 and cascade-5 to
rough-interop list
astearns: Anyone need to discuss?
astearns: Objections?
RESOLVED: Add conditional-4 and cascade-5 to the rough-interop list
SebastianZ: color-adjust-1
chris: It's already in the list
SebastianZ: Anything else?
TabAtkins: No idea off the top of my head
chris: I started looking into the Interop 2022 results to find
things that were in there, but didn't get to finish
astearns: I suggest we take the resolutions and just do the first
publication of the 2023 snapshot
chris: I see some editors on this spec and they're busy - I am too
but less than them. I propose adding myself as an editor
<fantasai> +1 to adding chris!
<TabAtkins> +1
<fantasai> thanks!!
astearns: Objections to publishing first version of CSS 2023 with
these resolutions?
RESOLVED: Publish 2023 Snapshot (after resolutions edited)
RESOLVED: Chris Lilley is added to Snapshot editor list
SebastianZ: scroll-snap-1 was in Interop 2022, seems pretty good
SebastianZ: It's also in 2023 but already has a high score
astearns: So proposed resolution is to add scroll-snap-1 to
rough-interop list
RESOLVED Add scroll-snap-1 to rough-interop list
CSS Color
=========
Serialization of named colors
-----------------------------
github: https://github.com/w3c/csswg-drafts/issues/7870
<chris> We got rough consensus in the issue, I made the edits, just
looking for confirmation
https://github.com/w3c/csswg-drafts/issues/7870#issuecomment-1410589234
chris: I think I understood the consensus and made the edits
chris: Looking for a thumbs up or mistakes
TabAtkins: I can review this asap
TabAtkins: but we can resolve now
astearns: so proposed resolution is to adopt the changes added in
response to this issue
RESOLVED: Accept Chris's edits
gba()` is legacy so does not support `none`. Right?
-----------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7900
chris: We have an old syntax which has commas for everything
chris: And a new which is space and slash
chris: We've added a bunch to that new syntax, like RCS
chris: But it used to be that everything had to be a % or everything
a number, that's from CSS1
chris: In RCS you can mix them tho
chris: My proposal is that the modern syntax, only, allows mixing %s
and numbers.
chris: Also the modern syntax can use 'none'. I'd also like to keep
that restricted to the modern syntax.
chris: We have very good interop on what's currently specified
chris: People have argued that for clarity we should extend the
capabilities to all syntaxes, but I think it's a bad idea -
we have very solid interop as-is.
<TabAtkins> I'm totally fine with this.
chris: So proposed resolution is we backport mixing number/% to the
modern syntax of non-RCS rgb() and hsl()
<argyle> +1
astearns: Questions?
astearns: I assume this is okay with the issue commenters?
chris: There's one in the thread who had several suggestions but no
strong opinion. Other than that, agreement in the thread.
RESOLVED: non-RCS rgb() and hsl() can mix numbers/%s when using the
modern syntax (space and slash, not comma)
color-contrast() should take transparency into account
------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7358
lea: We've discussed before. Right now contrast-color() ignores
transparency entirely, pretends the colors are opaque.
lea: This can produce wildly wrong results.
lea: A color with a very low alpha but otherwise has a good
contrast, the algo can choose that over an opaque color that
would *actually* contrast better
lea: Previously we resolved that you composite a semi-transparent fg
against the bg, but we didn't resolve on what to composite the
bg against
lea: There are three options
lea: (1) the opaque version of the fg
lea: (2) opaque white or black, whichever is better
lea: (3) canvas color
lea: (4) Color picked by UA to minimize the contrast (per contrast
algo specified).
lea: So we have to resolve on the color and we'll have a complete
algo
lea: Whatever heuristic we pick it might be wrong, so it might also
be useful in a later version to add a color-over() that
specifies the compositing...
TabAtkins: Weak preference for canvas color
chris: Me too, seems canvas color is a good default, takes light/
dark mode into account
fantasai: Seems like it could be wronger than fg
chris: fg is gonna be the worst possible
fantasai: color could be in a subtree with a different color than
canvas
fantasai: fg is not always worst possible, depends on the composited
background
dbaron: I think it's possible to come up with an algorithm for
"worst possible color" but not sure it's any of these
argyle: I'm reminded of accent color - we compute it against canvas
color
argyle: I think it would be nice to have a fallback mechanism where
it falls back to canvas if there's not an html or body color
argyle: So it could crawl up and try to find a solid color,
otherwise use the UA canvas
fantasai: I don't think we can look for the actual bg - frequently
you're rendering over an image
fantasai: and we want to do this locally without having to do layout
or crawl the tree
fantasai: so I think we need an answer locally based on information
on the element itself
<argyle> I just used color-contrast() on the bg in this demo
https://nerdy.dev/color-from-color-contrast-result
smfr: I think we're assuming that contrast is used on the fg of an
element.
smfr: But might want to use it for the bg - seems like we're biasing
chris: We're actually not doing that - we're explicit about whether
the color is a fg or bg
chris: So this is only an issue where it's the bg color that's
partially transparent
fantasai: I think I'd prefer we went with opacified fg, or
"UA-chosen worst possible color"
fantasai: We're trying to find a color that passes a threshold for
some contrast
argyle: What if we added an option for users to specify it?
argyle: Like it defaults to canvas, but as an author I know what
color it's gonna be against
argyle: So authors can add intelligence but we still have a
reasonable default
<chris> color picked by the UA sounds handwavy, difficult to test,
non-interoperable
<fantasai> chris, it's "color picked by the UA to minimize contrast
per the contrast algo used"
<fantasai> which is not so vague
chris: I see what Adam's suggesting, but I think putting the same
color in twice means you have to update it twice and keep in
sync
argyle: Custom props is your way out of that - already this algo is
loaded with inputs that need copy/paste or custom props
<dbaron> Seems like what Adam's suggesting could also be done with a
composite(A over B) color function or similar rather than
additional syntax for the contrast function.
lea: Even using the custom prop is some repetition
lea: Remembering which of the custom colors you're using
lea: Does seem nice as optional, but shouldn't be only way
astearns: We're over time, and I'm not hearing consensus, so let's
take back to issue
Received on Thursday, 9 February 2023 00:46:22 UTC