- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 9 Aug 2023 19:11:39 -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
----------------
- The group discussed the three options to address issue #8048
(Declarative Cross-document View Transitions) that emerged from
the F2F.
- There was some pushback on using media queries, but not an
immediate alternative so people will continue gathering ideas in
the issue. Feedback on which CSS pattern to use for customization
is particularly necessary.
CSS Color
---------
- RESOLVED: Add light-dark() function that returns a color based on
the color scheme (Issue #7561: Add a function to allow
authors to specify colors reacting to `color-scheme`)
- RESOLVED: No (further) change (Issue #8629: Computed value and
serialization of `Infinity` and `NaN` in color functions)
CSS Backgrounds
---------------
- RESOLVED: Close no change (Issue #8026: Add slashes between
individual `border-color` values)
CSS Pseudo
----------
- RESOLVED: All 'display' values other than 'none' or 'contents' on
'::backdrop' compute to 'block' (Issue #7845: Define
::backdrop)
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2023Aug/0003.html
Present:
Rachel Andrew
Rossen Atanassov
Tab Atkins
Mike Bremford
Oriol Brufau
Emilio Cobos Álvarez
Yehonatan Daniv
Elika Etemad
Mason Freed
Paul Grenier
Daniel Holbert
Jonathan Kew
Vladimir Levin
Noam Rosenthal
Khushal Sagar
Miriam Suzanne
Bramus Van Damme
Sebastian Zartner
Regrets:
Florian Rivoal
Chair: Rossen
Scribe: fantasai
View Transitions
================
Declarative Cross-document View Transitions
-------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8048
khush: Last time discussed lots of good feedback.
khush: Main issue is figuring out declarative feedback for doing
cross-document navigation transitions
khush: Sub-cases are same-origin vs same-site navigation
khush: Same-document it's just syntactic sugar, can do via JS API
in L1
khush: but nice to have
khush: First, if we go for simplest opt-in, binary yes/no allow/
disallow
khush: but a bunch of cases have different parameters, and authors
may want to decide opt-in based on what navigation corresponds
khush: additionally there are some parameters to decide what
transition looks like
khush: i.e. what elements animate independently, or how to style the
animation
khush: same-document / cross-document / same-origin / same-site
khush: You call document.startViewTransition, generally that should
be opt-in
khush: but we found some cases where someone might want to disable
transitions for prefers-reduced-motion
khush: and declarative syntax makes this easy
khush: For navigation, might want different animation depending on
type of navigation
khush: e.g. forward vs back
khush: There's also replace navigation, and push navigation
khush: Lastly, which page are you going to.
khush: e.g. clicked item in the list, decides UI of next page, want
to customize based on that
khush: From all these cases, if there are some which are mutually
exclusive, only thing that needs to impact opt-in
khush: wouldn't change opt-in depending on same-document vs
cross-document, don't need to change if the DOM looks the same
khush: In that case, have it be opt-in
khush: but if based on that you want to customize transition, e.g.
back vs forward, change direction that content slides
khush: Let's make that something that can be used to customize all
CSS, not just this opt in
khush: I thought at first to use an @media query
khush: noam proposed using pseudo-classes instead
khush: and there's precedent for doing this with @page at-rule
khush: Right now 3 proposals
khush: 1. Use @media queries for deciding navigation back/forth/
specific URL
khush: also whether initiated via script, etc. All these cases are
expressed as tokens in the opt-in rules
khush: @view-transition takes a parameter, 'transition-trigger', and
you can specify various tokens for allowing
khush: Previously we discussed having reloads disabled by default,
but with this syntax it's hard
khush: It seems to imply reload
khush: Second tries to solve that by saying that we can add another
parameter to the at-rule, which is just 'reload', allow/
disallow; initial value can be disallow
khush: only reason to do this is that media queries, they don't add
any specificity, so can't add a UA style rule that says "don't
trigger for reload"
khush: Later on, one suggestion from SebastianZ to include reload
token within the 'transition-trigger' list itself
khush: technically not mutually exclusive, because same-origin or
cross-document is [missed]
<TabAtkins> Wait, can't you tho? We don't need specificity, just
order of appearance, right?
<TabAtkins> Ah tho if the author turned on some navigations that
would override the "not on reload" rule then
<vmpstr> any author opt-in would override the reload "opt-out"
<vmpstr> yeah exactly
khush: but we're not aware of use cases where people would want to do
differently for cross-document vs same-document reload
khush: Last option was using pseudo-class, use @view-transition but
you can add a pseudo-class which is a mapping to the
navigation type
khush: then we can add a UA style rule @view-transition :reload { [no
transition] }
khush: It will have more specificity, so UA rule would win
khush: Because of that I'm liking this option the most
noamr: Want to add that this conversation came from F2F where we were
asked to think ahead to features we wanted in View Transitions
noamr: even though all we want to do in L2 is the simple opt-in
noamr: idea that we think ahead to how things look like
noamr: In all those options, the first version is very similar
noamr: where we have a view transition rule and inside of it a
navigation trigger etc.
<TabAtkins> hmmm, I might suggest making the property
comma-separated, one keyword per - then you can add
additional features (like reload) to each iteration.
<TabAtkins> trans-trigger: none | [ [reload | no-reload] ||
<transition-type> ]#
emilio: I wanted to mention that media queries seem like an odd
choice here
emilio: feels cleaner to just extend the rule to allow selecting the
cases you want
emilio: Media queries you can do anything inside them, not just view
transition rules
emilio: so unclear when that applies
emilio: do we need to do a full style update?
emilio: so it feels like an odd choice, so if we need to add this
kind of selector capability, extending the rule itself seems
better
<TabAtkins> Bringing in specificity for the rule itself seems a
little more complex than we need, and it seems strange to
promote reload, specifically, to be the thing promoted to
"selector"-ish.
emilio: Other thing to mention, we have a kind of precedence for this
kind of stuff with scroll-behavior
emilio: it was mentioned that what you want to do is e.g. disable
imperative animations
emilio: stylesheet would override
emilio: that's not how scrollIntoView etc works
emilio: so might want to be consistent with that
SebastianZ: Noam pointed out important thing, this is divided into
3 pieces
SebastianZ: URL, type, and mechanism
SebastianZ: was thinking about, maybe they shouldn't be part of the
prelude but rather different descriptors
SebastianZ: so have a descriptor for each of these pieces
SebastianZ: so you'd have a type descriptor that takes "reload |
travers | etc"
SebastianZ: a descriptor for same-origin / cross-origin
SebastianZ: and a descriptor for the mechanism itself
fantasai: Wanted to point out that in the cascade, origin is more
powerful than specificity
fantasai: so even if specificity of the :reload pseudo-class is
higher UA origin would override
fantasai: I also want to agree with emilio wrt stashing this on a
media query
fantasai: SebastianZ's idea of encapsulating all these in descriptors
makes sense, it's like @font-face
fantasai: the other thing authors might want to control is defining
the type of navigation based on the URL
fantasai: and you might want to have that centralized
fantasai: that way when you need to update any of these types of
navigations you don't need to go through everything to
update the URL list everywhere
fantasai: I think it would be useful to style based on the class of
view transition (author-defined class)
noamr: Idea of having descriptor for transition class or group,
equivalent to how we would do it in SPA, like a parameter to
.startViewTransition
noamr: in this case, we can't have other descriptors for URL origin
for navigation type
noamr: because they would interfere with each other
noamr: that's why I want outside the braces, as part of pseudo-classes
noamr: If this is a back navigation, use this transition
noamr: if it is a ???, then don't allow cross-origin
noamr: It needs to be outside so we can style navigations based on it
noamr: so what's outside is the navigation type and origin, and
inside is only the mechanism
noamr: something that shouldn't affect the styling, but only be a
trigger boolean opt in
khush: Question for fantasai and emilio
khush: You mentioned you don't like idea of media query or
pseudo-class
khush: but if I want to add a view transition class name based on
what type of transition it is
khush: how would I go about doing that?
khush: either can specify any CSS rule, or ...
khush: any suggestion other than MQ or pseudo-class? How would they
specify different `view-transition-name`?
<fantasai> Good question... I don't have a good answer.
Rossen: Doesn't seem we're ready for resolution, but getting some
sense of direction
Rossen: Seems like it should continue in the issue
khush: Can take to issue
khush: What I'm stuck on is what CSS concept to use on customization
khush: If someone could put some thoughts, that would help move the
issue forward
<khush> Thank you!
CSS Color
=========
Specified value for color when calc() is used
---------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8318
emilio: Clamped at specified value time in the past, unsure if we can
change. Not sure about hsl() etc.
emilio: but we may want something special for rgb()
emilio: might be able to change what spec requires, but also not
super excited about it
emilio: all browsers are interoperable right now on the weird thing
TabAtkins: No strong opinion, but in some cases impossible to resolve
calc() until later time
TabAtkins: current spec rules define that
TabAtkins: I'm OK to define earlier resolution behavior for certain
color functions
TabAtkins: but suggest take it back up once there's a concrete
proposal for what to do
TabAtkins: Given Chris isn't here, would prefer to have a proposed
resolution prepared
Add a function to allow authors to specify colors reacting to
`color-scheme`
-------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7561
emilio: Discussed briefly in F2F
emilio: Tab's proposal about having a variable-like thing ...
emilio: I'm not sure this is ready for resolution. I added Agenda+
F2F and we didn't remove.
TabAtkins: I'm happy to discuss my proposal. Two things to consider
TabAtkins: The first and easiest one is, just having a color function
that responds to color scheme
TabAtkins: this doesn't require anything fancy
TabAtkins: Proposed syntax is ...
<TabAtkins> color-scheme( <color>#{2} | [ <custom-ident> <color>
]#{2,} )
TabAtkins: You can either provide two colors
TabAtkins: or provide color scheme ident and color pairs
TabAtkins: This matches behavior of existing function that browsers
have access to
TabAtkins: I know that Chrome and Firefox have something like a
light-dark() function
TabAtkins: it's simply a color, goes where colors go, responds to
color scheme
TabAtkins: other one is if you want to do other stuff, e.g. turn
shadows on
TabAtkins: and that requires var-like semantics
TabAtkins: but simple color one will solve a majority of cases we
care about here and be very simple
fantasai: If you only spec 2 colors, and we later introduce a new
color scheme, what happens?
TabAtkins: Suggest to default to "light"
TabAtkins: same issue applies with the list option
TabAtkins: in that case, maybe choose first one. or maybe choose
"light" if specified
fantasai: One of the nice things about chrome's internal function is
that it makes very explicit what goes where
fantasai: like minmax() in grid
fantasai: so I understand that at some point for more schemes we want
to tag individual values
fantasai: but currently we just have light and dark
fantasai: I think it's a lot better to have light-dark like chrome has
fantasai: At some point in the future that could become effectively
syntactic sugar for a more-comprehensive function
fantasai: but even if we have that we could have a light-dark() since
that's the more common thing
<TabAtkins> I'm fine with `light-dark()` even if we have more schemes
in the future, it's still a reasonable name.
bramus: I want to support what fantasai said, start with light-dark()
and have it be syntactic sugar for color-scheme() or whatever
in the future
bramus: Internally Chromium had light-dark-color(), but then changed
to light-dark() which allowed using in properties other than
colors
TabAtkins: I'm fine with light-dark() as a name. That's still fine
if/when we do define more color schemes
TabAtkins: For having a second function that has var-like semantics,
but can do anything ...
TabAtkins: makes sense to me, but that should be a separate thing so
that we have a well-defined <color> that can be accepted
in places that accept colors
<fantasai> +1
emilio: Should we resolve on light-dark-color() and potentially
extend to more color schemes or value types in the future?
<emilio> I'd go just for light-dark() as a name fwiw
<emilio> but light-dark-color() wfm
Rossen: Proposed resolution is to add a light-dark() or
light-dark-color() color ... extend for other color schemes
later
dholbert: If we do want to add an additional function name,
light-dark() sounds like a more generic thing
dholbert: so might want to use light-dark-color() for the
color-specific thing
<TabAtkins> light-dark-value() for the "anything" one?
dholbert: but that's just naming thing
fantasai: Thought about what dholbert just said, but the color is
going to be by far the most commonly used thing
fantasai: so might make sense to have light-dark() for color and
something longer for the value syntax
dholbert: makes sense
fantasai: poll on the name?
Rossen: Let's pick one and discuss in the issue.
<TabAtkins> (and note proposals to, say, name nth-value() to grab an
arbitrary value from the list. "value" as an indicator of
arbitrary, var-like behavior is somewhat leaned toward as
a pattern.)
<TabAtkins> 1) light-dark-color()
<TabAtkins> 2) light-dark()
POLL: 1) light-dark-color 2) light-dark
<fantasai> 2
<emilio> 2
<TabAtkins> 2
<bramus> 1
<miriam> either
<dholbert> 2, per fantasai's note on making-the-common-thing-easy
<rachelandrew> 2
<oriol> abstain
<masonf> 2
bramus: What about schemed-color() etc.? Would we then have
schemed-color() map to light-dark() and schemed-value() to
light-dark-value() ?
TabAtkins: More color schemes in the future, but light-dark is just
for these schemes
bramus: Returns a color?
TabAtkins: Yes. If we want value, we can use light-dark-value()
RESOLVED: Add light-dark() function that returns a color based on the
color scheme
CSS Backgrounds
===============
Add slashes between individual `border-color` values
----------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8026
SebastianZ: My point was that we're adding more features to the
border-color shorthand
SebastianZ: to make the syntax more future proof, I suggested to
change the syntax for when using features to add slashes
between the different values for different sides
SebastianZ: or could be something else, but we already use slashes in
border-image and grid-area
SebastianZ: We already added stripes() function, for example; this
would make it clearer that they are different values
fantasai: I don't think this is necessary, because stripes() is
an image
fantasai: I think if we're going to make border-color more
complicated we might want to pull it out into different
longhands
fantasai: if we want to provide something like you'd do with
backgrounds then we should have something else
fantasai: in most cases I don't anticipate that people will mix
stripes() with other things
<oriol> +1 to elika
Rossen: Seems like good reason to not do this just yet
Rossen: SebastianZ, anything to add?
Rossen: otherwise we can resolve no change for now
SebastianZ: I think it's fine. My suggestion was to make it
future-proof now rather than later
Rossen: Proposed resolution is no change
Rossen: we can return to it later if needed
RESOLVED: Close no change
CSS Color
=========
Computed value and serialization of `Infinity` and `NaN` in color
functions
-----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8629
TabAtkins: Question was about if understanding of how infinity and
NaN showing up in color functions should be serialized at
various value stages (and handled in general)
TabAtkins: does run into question of whether to do earlier resolution
for color functions
TabAtkins: but aside from that
TabAtkins: if you put an infinite calculation into an rgba(), the
behavior is well-defined: clamp to the allowed range
TabAtkins: I think for rgba() it's 0-255
TabAtkins: at at least computed value time
TabAtkins: specified value time is separate issue
TabAtkins: negative infinity clamps to zero
TabAtkins: and NaN becomes zero when it escapes a calculation tree
TabAtkins: That's all defined now
TabAtkins: so unless there is any disagreement on these cases, we can
confirm no change
TabAtkins: and close the issue
TabAtkins: Only thing left is separate issue of whether we eagerly
simplify certain math functions in some cases
TabAtkins: but that's a separate issue
fantasai: Separate issue is filed?
TabAtkins: Yes
<TabAtkins> (the separate issue is #8318)
<TabAtkins> (#4 on the agenda this week, we skipped it because
no Chris)
Rossen: proposed resolution is no (further) change
RESOLVED: No (further) change
CSS Pseudo
==========
Define ::backdrop
-----------------
github: https://github.com/w3c/csswg-drafts/issues/7845
<TabAtkins> https://github.com/w3c/csswg-drafts/issues/7845#issuecomment-1507536451
TabAtkins: Some questions about how ::backdrop should work in the tree
TabAtkins: First, should it be forced to 'display: block !important'
in the UA stylesheet?
TabAtkins: Doing so avoids some follow-up questions
TabAtkins: Given it's just designed to put color behind an element,
seems unlikely that giving it any other display type would
ever matter
TabAtkins: so first question is, can we force it to 'display: block'?
oriol: I disagree with this
oriol: because I think that 'display: none' makes sense
oriol: I would be fine would be saying that all values except 'none'
and maybe 'contents' compute to 'block'
oriol: but I wouldn't do this with a UA !important rule
TabAtkins: Another possibility is to lean on 'content: none', which
would cause it to not generate
TabAtkins: so we don't need 'display: none' to make it disappear
oriol: I guess that could work
oriol: but 'display: none' tends to work on pseudo-elements
oriol: but I guess 'content: none' could address the use case
TabAtkins: But we could also do special computation rule
emilio: My question was same as Oriol
emilio: is there a use case to set 'none'
emilio: but I'd rather magically turn to block than rely on 'content:
none'
emilio: but as long as 'none' works, fine to make everything else a
block
TabAtkins: proposed that all values other than 'none' or 'contents'
values compute to 'block'
RESOLVED: All 'display' values other than 'none' or 'contents' on
'::backdrop' compute to 'block'
Received on Wednesday, 9 August 2023 23:12:14 UTC