- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 10 Nov 2021 19:32:31 -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.
=========================================
Syntax, Values, Cascade, and Fonts
----------------------------------
- There are several people coordinating to review pull request #6175
(Formalize fetching and resource timing reporting)
CSS Lists
---------
- RESOLVED: Accept proposal (Issue #6797: Algorithm for initial
counter value in reversed list should repeat the last
increment instead of the 1st one)
Media Queries
-------------
- There are several smaller questions that need to be resolved in
order to address issue #6793 (Clarifications on
[video-]dynamic-range MQs). There are editorial changes necessary
to differentiate similar media queries. Additionally, there is
clarification needed to state what the combo of UA and output
device is intended to be a superset of the values. Last, there
needs to be a better definition about what should be returned and
when for video-dynamic-range. Discussion will continue on GitHub
to develop proposed new text.
CSS Position
------------
- The group will wait on Firefox to see if they can change their
behavior before resolving on issue #6789 (Behaviour of
semi-replaced elements)
CSS Color & Color Adjust
------------------------
- The group will revisit issue #6773 (Consider reversing the
resolution of #3847) once there is more implementation experience
to indicate the right direction.
CSS Color
---------
- RESOLVED: Move @color-profile and device-cmyk() to L5 (Issue #6765:
Defer @color-profile to L5)
- RESOLVED: Add srgb-linear color space (Issue #6087: Expose
Linear-light sRGB as CSS syntax?)
CSS Cascade
-----------
- RESOLVED: WG leans towards weak proximity at this time, and
recommends this direction for prototyping to get more
feedback (Issue #6790: Strong vs weak scoping proximity)
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2021Nov/0005.html
Present:
Adam Argyle
Rossen Atanassov
Tab Atkins-Bittner
David Baron
Mike Bremford
Oriol Brufau
Elika Etemad
Simon Fraser
Megan Gardner
Chris Harrelson
Daniel Holbert
Brad Kemper
Chris Lilley
Peter Linss
Alison Maher
Morgan Reschenberg
Jen Simmons
Miriam Suzanne
Lea Verou
Regrets:
Jonathan Kew
Scribe: drott
Syntax, Values, Cascade, and Fonts
==================================
Formalize fetching and resource timing reporting
------------------------------------------------
github: https://github.com/w3c/csswg-drafts/pull/6715
fantasai: Areas where we need to better integrate with the fetch spec
fantasai: chris recently merged PR contributed by contributor
fantasai: We need those to be reviewed - and ask to publish these
changes
iank: did these get reviewed by Anne or Dominic Denicola?
TabAtkins: I did review it
TabAtkins: Anne and Domenic coordinating on reviewing...
<chris> Yeah I reviewed it too
fantasai: If it sounds like it's been reviewed, then I'd suggest to
accept the changes
CSS Lists
=========
scribe: fantasai
scribe's scribe: drott
Algorithm for initial counter value in reversed list should repeat the
last increment instead of the 1st one
----------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6797
oriol: Define reversed counters
oriol: Either specify start explicitly or calculate automatically
oriol: I think algorithm doesn't make sense
oriol: If don't have any counter-set, some of the increments of the
items for the counter
oriol: but first increment is counted twice, not once
oriol: and then sum is adjusted by -1 to get start value
oriol: Counting the first increment twice, the reason might be
otherwise last item will have value of ??
oriol: but in case of -1, we want the last item to get a value of 1
oriol: If all increments are the same
oriol: when they are different, I think we should actually repeat the
last increment
oriol: I have some examples in the issue
oriol: if list with all increments -1
oriol: and take one item in middle of list to -2, this only affects
preceding items
oriol: but if we change first item, this will affect the value of the
last item
oriol: and modify all values in the list
oriol: which seems unexpected
oriol: Another issue with counter-set, you have some increment there
and the with counter-set
oriol: start without counter-set, and item with value 2
oriol: and then we assign counter-set: 2
oriol: This should have no effect
oriol: Probably it's what the author expects
oriol: with current spec this can have an effect
oriol: in issue itself I proposed how to update the spec
oriol: Also variant of spec text taking into account resolution from
6738
oriol: where we decided to skip elements that are hidden
oriol: so only non-zero increments
oriol: Mats said it makes sense
oriol: and he already has an implementation
oriol: so suggest to take this change
Rossen: Sounds like a reasonable change, any others with an opposing
opinion?
[silence]
<TabAtkins> +1 btw
Rossen: objections?
RESOLVED: Accept proposal
Media Queries
=============
Clarifications on [video-]dynamic-range MQs
-------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6793
florian: We have 2 MQ which are similar, dynamic-range and
video-dynamic-range
florian: 2 issues in 1 here
florian: One is primarily editorial, doing poor job of explaining the
difference between these two queries
florian: Notion of video plane is fairly rare concept that relates to
TVs and how they have unusual screen buffer impls that we
can query separately
<chris> +1 to that editorial clarification
florian: Core question raised in this issue, besides clarification
florian: is that we have 2 values: high and standard
florian: You might assume, and this apparently is what Safari did,
that any device will match standard and some will match high
as well
florian: this is not how currently specced, though
florian: Devices expected to match one or the other
florian: Not standard and high simultaneously
florian: The query about color-gamut does behave differently, it has
3 values
florian: and these are additional, when you match broader gamut you
also match narrower one
florian: unclear what we should do here
chris: I agree, media capability does the same thing, of using
supersets
chris: Overall I think it's a better model, think we can easily make
spec say that
chris: The reason to do it is that when we add super-high later on,
we want it to be a superset that still passes high
chris: so I think we should change the spec; not because it's what
implemented, but because it makes more sense
<chris> see also https://w3c.github.io/media-capabilities/#hdrmetadatatype
dbaron: Wanted to add, think there's a 3rd issue
dbaron: Currently wording in spec about combo of UA and output device
dbaron: needs clarification what the UA part of it means
dbaron: Definition of high says, combination of UA and output device
fulfill all the following criteria
dbaron: There are a number of people in the issue saying that the UA
bit should be ignored, and should only be query about the
output device
dbaron: but if this is question of UA capability, which are you
considering if UA can do for some things but not others
dbaron: e.g. videos but not images, or ...
florian: I suspect querying device and not UA is useless
florian: because if the UA isn't able to access the capability, it's
not helping you
florian: but if capability varies within UA, that's a problem
Rossen: Is one a superset of other? Is UA subset of device?
dbaron: I wouldn't think of it that way
florian: We're querying union of both
florian: need both UA and device to be capable
chris: Also, HDR capability can vary over time
chris: high power usage
chris: so off by default
chris: so need to know that it can change
chris: One, is the device capable of HDR mode, and then two, is it in
that mode?
chris: we are mixing those two up
florian: We do
fantasai: We should take a resolution to change the query to superset
model
fantasai: multiple things to be clarified
fantasai: Let's ask editor to go back to the thread to work out
results
fantasai: A lot of the clarifications are straightforward
fantasai: need a resolution to change the media queries
florian: Don't quite agree, question of capability or in HDR mode
currently
florian: or videos vs images etc.
florian: Not quite clarification, is change in functionality
florian: Puzzle how to answer if we don't change the syntax
florian: so can do things fantasai highlighted, but not enough to
solve the issue
chris: Media capabilities spec talks about capability, "can the
device do it"
chris: If we clarify that way, need the other query as well
chris: The capability and concrete "am I in this mode" are separate
florian: Is it expected to remain this way?
chris: Especially for mobile, definite power drained
chris: Can be switched automatically, doesn't require user action
chris: but there needs to be a capability
chris: and need to know which mode you're in
fantasai: I think we should spec as being able to use the switch
fantasai: from a media queries point of view, how are we styling the
document - many of those questions on depend on current mode
fantasai: [missed parts]
florian: What do we do about if UA can do for images and video but
not CSS colors?
florian: or some other variation?
florian: Should we consider the UA does or does not fulfill the
criteria?
florian: or do we think about query in a different way
florian: I haven't thought about deeply, but maybe you would have
high-dynamic-range: video | canvas | etc.
florian: and would get something true if that specific thing is in
HDR mode
Rossen: Sounds like a conversation to continue in GH
Rossen: and doesn't seem we're ready to resolve just yet
Rossen: Propose we stop here, and then after working out proposal in
issue, bring back and we'll record a resolution
Rossen: but hopefully attracted some help on this issue
CSS Position
============
Behaviour of semi-replaced elements
-----------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6789
iank: Bunch of history here
iank: When we have width/height=auto
iank: can either shrink-to-fit or stretch in that axis
iank: in Grid Layout, most items will stretch except replaced elements
iank: every layout mode make these decisions
iank: semi-replaced element in block layout, flex, is shrink-to-fit
iank: Question is about abspos semi-replaced element, say with
inset: 0
iank: Firefox stretches in block axis, shrink in inline
iank: webkit stretch both axes
iank: chrome ...
iank: So what do we want to do here?
iank: previously FF team strongly wanted shrink-to-fit here
Rossen: anyone from FF?
Rossen: Do we shrink-to-fit in both axes, or stretch in both axes, to
make behavior symmetric and consistent
dholbert: Don't have an answer atm, but will take a look
<TabAtkins> As I said in the issue a few minutes ago, "every
divergence that buttons make from a standard inline-block
is unfortunate."
<TabAtkins> Because it has been asserted quite confidently in the
past by implementors that buttons were *not* replaced
elements, and were fully described solely by inline-block
behavior ^_^
fantasai: TabAtkins and I figured that
fantasai: since webkit implements stretch on both axis
fantasai: that makes it web compatible
fantasai: [missed] you can always get the other behavior by switching
alignment
TabAtkins: In the past, impl have said that buttons aren't replaced
elements
TabAtkins: and fully described by inline/block behavior, so the more
we can make that true the better
TabAtkins: Having them stretch by default would make them match
non-replaced
iank: I'm fine either way, but historically FF folks have been very
strong in their opinion wrt shrink-to-fit
Rossen: OK, let's give dholbert some time to look through it
Rossen: if we can resolve on this later on in the call, great, if
not, bring back next week
CSS Color & Color Adjust
========================
Consider reversing the resolution of #3847
------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6773
emilio: We made system colors compute to themselves because wanted
them to react to color-scheme
emilio: but that's not behavior any agent has, and when you do that
you get lacking contrast if color scheme changes but you
didn't change the bgcolor
emilio: Not quite clear to me what Blink is doing
emilio: but, computing system colors to the keywords themselves also
causes complexity
emilio: With interpolation, issues open since we resolved that
emilio: So can we undo that resolution?
TabAtkins: A couple of points emilio made are present today regardless
TabAtkins: e.g. complexity of interpolating color, currentColor
resolves at used-value time
TabAtkins: exact same case for system colors
TabAtkins: Also has a point about needing to set system colors in
pairs, and yes, you do, and spec says you should always do
that
TabAtkins: It's very easy to get messed up and have bad colors if you
don't, in general
TabAtkins: If we compute system colors and computed value time, then
whenever color-scheme changes, in particular if you go
across any embedding boundaries, shadow boundaries,
they'll be messed up as well
TabAtkins: They'll assume in light mode and responsibly use system
colors, get wrong colors inheriting in
TabAtkins: so I think the current specced behavior is the best
TabAtkins: Chrome's behavior is weird and inconsistent right now, but
once matches spec, I think it will be reasonable behavior
TabAtkins: and won't save any complexity by changing it
emilio: Not about setting colors in pairs, but about changing color
scheme
emilio: if ...
emilio: if you make system colors compute to themselves,
forced-color-adjust: preserve-parent-color is like forcing to
resolve their values, which is pretty odd
emilio: we're landing workarounds...
emilio: I disagree that this doesn't introduce complexity
emilio: preserve-parent-color is literally working around this
behavior
TabAtkins: preserve-parent-color is about forced-color-adjust, where
we want SVG to be able to opt out of being forced-colored,
but still be able to respond to system colors coming in
TabAtkins: We have plenty of SVG in the wild that want to respond to
outside color and set some of their own colors as well
TabAtkins: to work in forced color mode, need some way to tell
whether receiving system color vs other color
emilio: Not true, FF behaves correctly right now [...]
alisonmaher: preserve-parent-color was a workaround due to handling
forced-colors mode, not about system colors computing to
themselves
emilio: To me, both are related. If don't preserve ??? then can't at
used value time
alisonmaher: In Chrome we do implement this workaround. We also
haven't shipped system colors computing to themselves yet
alisonmaher: Essentially piggybacking on top of, have an
implementation where it computes to itself, so
workaround with impl that hasn't shipped yet
Rossen: So building on the capability but not exposed?
alisonmaher: yeah
emilio: We define system colors to compute to themselves
emilio: you need to implement forced-colors at used value time and
vice versa
emilio: Complexity comes from making both forced colors and system
colors compute at used value time
fantasai: If we don't make the system colors compute to themselves
fantasai: if you switch scheme, it won't have any effect - which is
not expected
emilio: Let's say have a dark background and background is Canvas
emilio: If you just change color-scheme you get illegible text
dbaron: If they don't compute to themselves, you run a restyle
fantasai: If you have an element that is color-scheme dark, inside
one with color-scheme light
fantasai: are you going to have light or dark? or what's happening
inside?
fantasai: If you move it out, you'd expect it to stay on that
fantasai: but it inherits different resolve colors depending on
parent color scheme
fantasai: to get colors you expect, you can't rely on system colors
inheriting, have to re-declare them when declaring
color-scheme
<TabAtkins> From what I can tell, emilio, you're saying that if
authors don't set colors in pairs, they can get bad
results. Is that right?
emilio: Need to restyle anyway, need to set at least the backgrounds,
so can't rely on inheritance otherwise get broken behavior
emilio: Always need to set in pairs, but even if you do, but if you
change color-scheme without setting any color then behavior
is broken if they compute to themselves
emilio: because changing only foreground color and bg color doesn't
change because not inherited
<chris> "Authors may also use these keywords at any time, but should
be careful to use the colors in matching
background-foreground pairs to ensure appropriate contrast,
as any particular contrast relationship across non-matching
pairs (e.g. Canvas and ButtonText) is not guaranteed."
<chris> https://drafts.csswg.org/css-color-4/#css-system-colors
<chris> Also "The following system color pairings are expected to
form legible background-foreground colors:"
Rossen: Given the complexity of these different combinations and
where Chromium implementation is, in its inconsistent state,
I propose we continue to work on this issue in GH
Rossen: and once more implementers as well as others have a stable
conclusion, can bring it back for resolution
Rossen: Going in circles here trying to define expected behaviors
Rossen: as well as what everyone is talking about
emilio: Yeah, agree, I think we're talking past each other a bit
Rossen: ok, well thanks for opening issue
Rossen: Let's move on to next issue
CSS Color
=========
Defer @color-profile to L5
--------------------------
github: https://github.com/w3c/csswg-drafts/issues/6765
lea: Custom color spaces have not gotten same implementer interest of
other features in L4
lea: and complicate a lot of discussions due to custom color spaces
lea: Also had some ideas that depend on L5 features
lea: so suggestion is to defer to L5
lea: but Tab raised that device-cmyl() depends on it
lea: which is implemented only in print impls
lea: Suggest is to also defer device-cmyk()
TabAtkins: I agree with this, and there's a lot of interesting things
to work on here
TabAtkins: that could use time to bake without holding up L4
chris: I also agree
chris: Also have some feedback, have a descriptor called 'components'
that doesn't appear to do anything because what it affects is
in L5, so another reason to move
Rossen: So proposed to move @color-profile and device-cmyk() to L5
RESOLVED: Move @color-profile and device-cmyk() to L5
Expose Linear-light sRGB as CSS syntax?
---------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6087
chris: Linear-light sRGB is sRGB without gamma function
chris: already extended beyond 0 and 1
chris: some hardware uses this to do HDR
chris: used in WebGPU and Canvas
chris: also SVG filters do all their work in this mode
chris: We export the term for re-use, but don't expose it to authors
chris: so question is do we want to do that
smfr: WebKit supports adding this
chris: Does anyone object?
chris: Just notice that it has a much higher precision function than
sRGB
chris: so you will need a half-float to hold these values
RESOLVED: Add srgb-linear color space
CSS Cascade
===========
Strong vs weak scoping proximity
--------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6790
TabAtkins: Right now, scoping spec cascade-6 is intentionally
ambiguous on exactly where scoping sits in cascade
TabAtkins: offers two options: less strong that specificity (just
stronger than order of appearance) and another that's
stronger that specificity
TabAtkins: Given it's currently ambiguous, makes difficult to do test
implementation
TabAtkins: Would like to do a test implementation, and prefer weak
scoping
TabAtkins: I've argued in the thread about why the weaker scoping is
the better way to go, going for strong would be a mistake
imho and make things less usable for authors
TabAtkins: but for the moment, I think we should at least currently
resolve to go with weak scoping
TabAtkins: and revisit later
TabAtkins: fantasai said in issue, she believes that related features
have been released to make a decision
TabAtkins: that would delay scoping feature by a year or two
TabAtkins: and I don't think the input we'd get would be worth that
level of delay
fantasai: No problem if chrome wants to go ahead and do prototyping
of weak scoping
fantasai: Exactly how it works will be fundamental to how css is used
fantasai: Need to be diligent and figuring it out
fantasai: 6 months timeframe is reasonable for that
fantasai: scoping feature is desired and useful
<Rossen> +1 to fantasai point ^
<TabAtkins> (I really, *strongly* think that going with "strong"
scoping would be making a serious mess, but I argued that
in volume in the thread already.)
fantasai: More important to get it right, first time around - waiting
6 months to a year is reasonable for the proportion of this
feature
fantasai: I suggest to resolve with something like: "the WG is
leaning towards weak proximity and thinks it's the right
way for prototyping"
fantasai: but keep the issue open for discussion
<miriam> +1
RESOLVED: WG leans towards weak proximity at this time, and
recommends this direction for prototyping to get more
feedback
Received on Thursday, 11 November 2021 00:34:14 UTC