- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 20 Apr 2022 19:06:07 -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.
=========================================
CSS UI 4
--------
- RESOLVED: Accept Florian's pr and submit the corresponding one to
HTML (PR #7224: Provide hooks for HTML to define
rendering for widgets)
CSS Text
--------
- RESOLVED: Reverse previous resolution. Add a unit instead, name tbd
(Issue #3232: Syntax for percentage-of-width-of-space for
'word-spacing')
Media Queries
-------------
- RESOLVED: Have preferred-color-scheme reflect 'color-scheme' on the
embedding element in the embedding document, to the
extent acceptable from security standpoint (pending
security review) (Issue #7213: Should
prefers-color-scheme in SVG images be context-dependent?)
CSS Images 4
------------
- RESOLVED: Force iframe/object/embed/any other scriptable
document-embedding element to object-overflow: clip
!important; via UA rule (Issue #7143: object-* properties
and the iframe element)
CSS Color
---------
- Chromium and Gecko will investigate their filter color space to see
if the proposed solution for issue #7100 (Should no-op filters
produce different output from no filter?) will be okay.
- RESOLVED: System colors compute to absolute colors, but must not be
affected by forced-colors mode (Issue #6773: Make system
colors fully resolve (but flag they were system colors)
thus reversing the resolution of #3847)
- RESOLVED: Republish css-color-4 and css-color-5
CSS Values
----------
- As the call was concluding, there was consensus building to have
NaN become 0 instead of ∞. Discussion will continue on issue
#7067 (Make top-level NaN be invalid at computed value time
instead of ∞) and then come back to the group for resolution.
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2022Apr/0009.html
Present:
Rachel Andrew
Adam Argyle
Rossen Atanassov
Tab Atkins Bittner
David Baron
Oriol Brufau
Tantek Çelik
Daniel Clark
Emilio Cobos Álvarez
Elika Etemad
Simon Fraser
Mason Freed
Megan Gardner
Chris Harrelson
Jonathan Kew
Daniel Libby
Rune Lillesveen
Chris Lilley
Peter Linss
Alison Maher
Morgan Reschenberg
Florian Rivoal
Alan Stearns
Miriam Suzanne
Lea Verou
Scribe: TabAtkins
CSS UI 4
========
Provide hooks for HTML to define rendering for widgets
------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/pull/7224
florian: A while back, zcorpan made a PR against CSS UI and HTML to
link the specs together better, and give HTML a way to
define how appearance:none works for the different widgets
florian: The two specs shared an algorithm for exactly how the
appearance disabled, etc
florian: Normatively it was fine, but editorially I thought the css/
html split wasn't ideal. The CSS spec ended up defining a
button, slider, dropdown, etc, but in a very lightweight way.
florian: Then there was back-and-forth bouncing for the dfns.
florian: This new PR reorganizes the concept, putting the
HTML-specific stuff into HTML and defining some concepts in
CSS that HTML can rely on
florian: Luckily zcorpan likes the rebalancing.
florian: And for clarity I did this with fantasai so that makes three
of us that like it
Rossen: Just reiterating, looks like zcorpan likes the approach, and
it's equivalent except transform-origin
florian: Right, forgot that normative difference. We have a separate
issue for that question.
Rossen: Second question is about revert-level vs revert, he was
wondering if this was meant to be revert-layer
florian: defer to fantasai
fantasai: Yes, of course
florian: So proposed resolution is, after correcting the revert-level
mistake, accept the PR and submit the corresponding HTML
half as well
Rossen: Comments or objections?
RESOLVED: Accept Florian's pr (7224) and submit the corresponding one
to HTML
CSS Text
========
scribe: emilio
scribe's scribe: TabAtkins
Syntax for percentage-of-width-of-space for 'word-spacing'
----------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3232
TabAtkins: Last week we agreed to go ahead and accept that the new
unit can just be a number
TabAtkins: It was since pointed out that in svg word-spacing is
defined and SVG allows all length properties to be
specified as number
TabAtkins: which maps to pixel
TabAtkins: After that I realized that word-spacing accepts quirky
lengths
TabAtkins: so `word-spacing: 2` maps to pixels
TabAtkins: Given we were not super-happy with numbers I propose to
reverse the resolution
TabAtkins: and resolve that we will give it a unit name
emilio: We may be able to get away with numbers if we say that they
mean spaces in non-quirks mode
emilio: All major browser engines map SVG attribute numbers to pixels
at parse time
emilio: You can parse numbers at quirks mode and still have a
specified value px
Rossen: Then you'll have a type difference which is weird
emilio: If you get css text between a quirks and non-quirks
stylesheet it can be confusing, but otherwise this is already
an issue
emilio: Not opposed to a unit, just pointing out that it *is* possible
RESOLVED: Reverse previous resolution. Add a unit instead, name tbd
Media Queries
=============
scribe: fantasai
Should prefers-color-scheme in SVG images be context-dependent?
---------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7213
emilio: We got an interesting bug report in Firefox
emilio: When you have a Firefox theme that's dark, but OS theme is
light
emilio: sites can't choose a reasonable favicon for dark mode
emilio: Suggestion is to make preferred-color-scheme for SVG images
reflect the used color scheme
emilio: Then could have light+dark icons anywhere in your page, and
then as long as your parent has the correct color-scheme will
display correctly
emilio: Maybe worth making this more general
emilio: Tab seemed to have some reservations
TabAtkins: This makes a cross-origin communication bit, and we try to
restrict those
TabAtkins: use case makes sense
TabAtkins: Just one more bit that you can use to talk to an iframe,
and every bit counts
TabAtkins: but if that's considered not too much of a problem, then
I'm fine with it
emilio: It's a communication channel in the sense that the SVG could
request a different image or something
emilio: but SVG images don't run script
emilio: I think Chrome did something like this for iframes, don't
know the details of that
emilio: If your iframe is in color-scheme: ? then you force a light
background
futhark: Behavior for iframes with different color scheme than parent
document is specified in the spec, that you set the
background of the iframe if 'color-scheme' doesn't match
parent
futhark: so you don't wind up with black on black or white on white
futhark: Wanted to ask, has anyone asked for similar functionality
for iframe?
futhark: or will there be other cases?
futhark: other than SVG
fantasai: If the concern is cross-origin, why not restrict to
same-origin
emilio: Possible, but maybe awkward
emilio: wrt Rune's question, we actually do that for some frames
emilio: e.g. for extension popups in Firefox, they're just iframes
inside a popup
emilio: we make those inherit the color scheme of Firefox in a
similar fashion
emilio: so we already have this code to make it work for iframes
futhark: We do something similar for <select> popups in Chrome
futhark: If you have <select> with a color scheme, that affects the
drop-down render
emilio: This seems generally a useful thing then
emilio: Main question is whether it's reasonable, given the issue Tab
mentioned
emilio: I'm not sure I'm the right person to make that assessment
emilio: What about we ask people in privacy/security what they think
about this?
emilio: If we accept it, then we can consider doing iframes as well
Rossen: Seems like a reasonable path forward
Rossen: I think general consensus of the group leans towards the
proposal
Rossen: pending feedback from Security folks
Rossen: So my proposal is to end the discussion here, and then get
back to it as we gather more information
fantasai: Could resolve that we want to do this, if reasonable from
security standpoint
<TabAtkins> Always useful to resolve, if for no other reason than to
have a neat conclusion easy to read at the end
Rossen: Any objection to record this as consensus of group?
PROPOSAL: Have preferred-color-scheme reflect 'color-scheme' on the
element in the embedding document, to the extent acceptable
from security standpoint
RESOLVED: Have preferred-color-scheme reflect 'color-scheme' on the
embedding element in the embedding document, to the extent
acceptable from security standpoint (pending security
review)
CSS Images 4
============
object-* properties and the iframe element
------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7143
TabAtkins: When I was discussing the object-overflow property
internally, it was brought up in security review that
allowing iframes escape the bounds, even if embedding page
opts into it, because they can change content arbitrarily
via script
TabAtkins: use cases for this seem fairly minimal
TabAtkins: main use case for this property was to allow images to be
larger than their content bounds
TabAtkins: iframes don't make as much sense
TabAtkins: so go ahead and enforce that iframes always stay clipped,
with UA !important rule
TabAtkins: Other HTML elements were also brought up, e.g. embed,
object, ??, and I'm not sure about SVG foreignObject
<chris> foreignObject is basically an iframe
TabAtkins: Proposal is to force iframe object embed and any other
HTML or SVG elements that can be scriptable to clip via UA
!important rule
smfr: Can authors override UA !important?
TabAtkins: no
<chrishtr> proposed resolution sgtm
RESOLVED: Force iframe/object/embed/any other scriptable
document-embedding element to object-overflow: clip
!important; via UA rule
CSS Color
=========
Should no-op filters produce different output from no filter?
-------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7100
smfr: Issue here is that CSS filters are specified to use sRGB as
their color interpolation model
<chris> they use linear-light sRGB
smfr: This is a problem when authors apply filters to colors outside
of sRGB gamut
smfr: e.g. display-p3 or color specified with LCH color space
smfr: This is important because often authors will apply no-op
filters, with intent to animate later
smfr: This means such filters will flatten the colors
smfr: In testing, looked like Chrome isn't doing this: they allow
out-of-sRGB colors through filters
smfr: WebKit does limit colors to sRGB
smfr: Don't think this is desirable
smfr: One, I think authors expect no-op filters to not have an effect
smfr: And second as an implementer, I'd like to optimize away such
filters by not doing anything special
smfr: Since CSS specifies sRGB compositing and filters are specified
to do this also
smfr: CSS uses non-linear sRGB
smfr: so I'm not sure how to resolve this, because I don't think we
specify our color compositing model in a way that matches
browsers
smfr: Maybe Chris has an opinion
chris: Correct that filters use sRGB and clamp at each stage in the
pipeline
chris: They do use linear-light sRGB
chris: They don't use gamut-encoded values
chris: Very obvious when you're doing it wrong
chris: I suggested a way forward for this, beefing up filters to have
a wider color gamut
chris: Simon said very nice, but doesn't solve my issue which is
no-op filter
chris: My concern about is that as soon as someone starts to animate,
from 0 to 0.01, then there's a sudden change
chris: I can see that it would help with no-op filters, but not with
an animation case
smfr: That's very true, and that's why I think we need to specify
that CSS filters interpolate in the working color space, so
that they don't truncate colors?
chris: The concept of a working color space isn't well-defined
chris: we have different ones for different operations
chris: Talking about compositing, but not just compositing, it's also
the conversion from luminance or conversion from saturation,
all use constants from sRGB and not display-p3
chris: Need to fix that, and the way to fix that is to continue using
sRGB ones, and because in linear-light make them extended, and
in that way can represent all other colors as well
chris: I think that's the best minimal change, otherwise you
have [problems]
smfr: That would be fine...
chris: If we can bash this out, would be great
smfr: Would be interested in hearing from Chromium and Gecko, what
their filter color space is
chrishtr: I'll have to check
emilio: Same here
emilio: but pretty sure we have code to optimize away no-op filters
Rossen: So, do more investigation on Chrome and Gecko side and then
come back to this?
chris, smfr: sounds fine
* chrishtr will investigate
Make system colors fully resolve (but flag they were system colors)
thus reversing the resolution of #3847
-------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6773
chris: We basically got agreement on this issue, Alison seemed to
like what I proposed and I drafted into the spec
chris: Need to update tests on WPT
chris: and any knock-on effects in other issues
chris: Apart from that, I think issue is ready to close
<fantasai> needs a WG resolution though
chris: Proposal is to make <system-colors> fully resolve, but flag
they were system colors so that forced-colors mode doesn't
touch them
smfr: For forced color mode, does that implementations that don't
implement forced color mode, but do implement light and dark
mode don't need flags?
TabAtkins: Flags only necessary for forcing colors
fantasai: I think the other behavior would be better, but I
understand it's debatable and this is easier to implement
because you don't need to maintain all the system colors as
separate channels
fantasai: The flag part is an internal impl detail; we just need to
spec that these colors, even tho they resolve, need to stay
as-is in forced colors mode.
chris: Suggested wording?
fantasai: I can come up with some, yeah
chris: Once we resolve on this, can I ask for another resolution?
Rossen: Any objections to this proposed resolution?
RESOLVED: System colors compute to absolute colors, but must not be
affected by forced-colors mode.
chris: There's been this change and some others, would like to
resolve to re-publish Color 4 and Color 5
<fantasai> +1
Rossen: Any objections?
RESOLVED: Republish css-color-4 and css-color-5
<chris> once the improved wording from fantasai is in, of course
CSS Backgrounds 4
=================
Issues with listifying border-color
-----------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2532
lea: Let's wait until Sebastian can attend
CSS Highlight API
=================
Triggering restyling/repainting
-------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4596
??: Merged the PR to resolve this, unsure if Florian has anything to
add here?
<florian> [no, I'm good]
CSS Values
==========
Make top-level NaN be invalid at computed value time instead of ∞
-----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7067
TabAtkins: When we added the ability to do arbitrary unit math to
calc(), we introduced the ability to divide by zero
TabAtkins: these turn into infinities, fine, handle as large number
TabAtkins: We also introduced NaNs, though
TabAtkins: We don't now how to make those behave
TabAtkins: We can't know what author intended without inspecting code
TabAtkins: so need to do something arbitrary to NaN
TabAtkins: Current spec turns NaN into infinity if it escapes a
calc() function
TabAtkins: I chose this because a) NaN is definite an authoring
error, always a mistake
TabAtkins: b) infinite is the most likely value to look wrong if
you're doing something with this
TabAtkins: We have an unofficial policy throughout CSS, whenever we
have a situation that can't detect at parse time, but is
obviously a mistake
TabAtkins: we make it break in an obvious way, so that author is more
likely to notice the mistake
TabAtkins: rather than doing something more subtle, that might be
missed
TabAtkins: This came up during TAG review, and Lea suggested that
it's better handled as "invalid at computed value time"
behavior
TabAtkins: I don't have a strong opinion on this
TabAtkins: my only objection to changing behaving time is that it
won't be invalid at computed value time, might not know
it's invalid until *used* value time
TabAtkins: so similar to IVACT, but distinct
TabAtkins: And whatever effect it has would behave differently wrt
inheritance, for example
TabAtkins: The other reason is that I think IVACT behavior is less
likely to be noticeable
TabAtkins: It's less likely to be obviously wrong, compared to
treating as infinity
TabAtkins: I think NaN should break things as much as we possibly can
TabAtkins: and would be useful for authors to give them the more
broken rendering
TabAtkins: but open for discussion
lea: I don't remember most of the arguments from TAG review, but
think there's a more fundamental principle here
lea: Errors don't always arise from authoring, sometimes from
user-generated or other variable input
lea: and user will be first to see this
lea: I want to avoid making the website unreadable
lea: For things like layout, can be very bad
lea: I'm not opposed, but problem with infinity because it would
introduce really bad breakage, would be seen by users first
TabAtkins: I don't agree that invalid at computed value time is less
likely to break
TabAtkins: If you're specifying a width as a calc(), that's going to
be some specific value. If at some point, because using
variables, results in a NaN and becomes invalid at
computed time, that'll switch to 'auto'
TabAtkins: which is just as completely different from author's intent
as infinity is
TabAtkins: We cannot divine an intent from a NaN
lea: Width: auto might produce a layout that's not intended, but not
the same level as breakage as infinity
lea: which can stretch out of the viewport and make content unreadable
emilio: I was going to point out what Tab pointed out, that we still
have an issue of what happens if NaN happens at used value
time
emilio: I'm not a fan of introducing behavior that depends on cascade
before/after
emilio: if we detect NaN at computed value or used value time...
* lea thinks maybe we need an invalid at used value time concept?
emilio: As for what specific behavior, I don't have a super strong
opinion
emilio: When we define NaNs in ..., we normalize to zero.
emilio: Usually just happens in testcases
<iank> we can only really determine this stuff at used value time.
emilio: I don't think it will matter in practice
emilio: I think zero is a bit more reasonable, doesn't create
infinite scrollbars
emilio: I think I'm not a fan of the 2 different behaviors based on
when you find the NaN
oriol: I'm not a big fan of the currently-specified behavior of
treating NaN as positive infinity, which seems arbitrary to me
oriol: That's why I filed this issue to try to choose something
closer to invalid at computed value time
oriol: During discussion realized this would be a problem for
properties that have multiple components
oriol: Maybe only one of these is NaN
oriol: And sometimes we turn these properties into shorthands
oriol: If we invalidate the entire property now, and later turn it
into a shorthand, then we would only invalidate specific
longhands
oriol: To prevent this creating a change in behavior
oriol: we would need something like var(), which on shorthands sets
all longhands to a pending substitution value
oriol: So now I'm more aligned with choosing a specific number for
NaN instead of an approach similar to IVACT
oriol: I'm not sure infinity is the best, maybe zero or minus infinity
<TabAtkins> If it's infinity specifically that bugs people, I can go
with "treat as 0".
<TabAtkins> Just as likely to be wrong, but less likely to pop
scrollbars.
<lea> I think "treat as 0" is more reasonable. width: 0; overflow:
hidden would be problematic, but hopefully that'd be rare
Rossen: I think that during our discussion, and reason to revisit,
the compounding effect of infinity can have very
unpredictable results based on current user settings,
viewport size, fonts available, etc.
Rossen: that will make detect-ability of such errors difficult for
authors, since spurious at best
Rossen: Given we're out of time, don't want to force a resolution
Rossen: but want to really go back and continue and see if we can
agree on something more platform friendly
TabAtkins: In IRC, discussion changing to zero
TabAtkins: I'm fine with that, Lea's fine with it
<chris> zero looks better to me
Rossen: Ok, let's return to that next week
<fantasai> zero sgtm
<dbaron> Yeah, I think I'm happier with 0 than infinity as well.
<emilio> For the record, the NaN -> 0 behavior in Gecko is from
https://bugzilla.mozilla.org/show_bug.cgi?id=1691652
Received on Wednesday, 20 April 2022 23:06:47 UTC