- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 30 Oct 2019 22:53:25 +0300
- 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 Color 4
-----------
- RESOLVED: We come up with a set of mandated color mappings for
deprecated system colors, put in spec, and write tests
for them (Issue #3873: Prevent fingerprinting with
deprecated system colors)
- RESOLVED: Make system color keywords behave like currentColor and
inherit as keywords (Issue #3847: Make system color
keywords compute to themselves)
- RESOLVED: Rename text keyword to CanvasText (Issue #4465: Text
system color conflicts with background-clip)
- RESOLVED: Publish a new WD for Colors 4
CSS Paint API and Typed OM
--------------------------
- RESOLVED: Specify that the PaintWorklet's canvas-ish methods can
take color keywords and do the right thing (Houdini
Issue #921: Current Color as an input to paint worklets)
- RESOLVED: Fix Typed OM spec to ensure that currentcolor and system
color keywords reify as CSSStyleValue, not
CSSKeywordValue, until we have CSSColorValue for them to
reify as. (Houdini Issue #921)
CSS Transforms
--------------
- smfr introduced issue #236 (Provide a way to specify rastered
content scale for transformed content) and there was interest in
giving authors a way to pass more information and influence
rasterization, but there wasn't enough time on the call to
create a solution.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2019Oct/0027.html
Present:
Rachel Andrew
Rossen Atanassov
Tab Atkins
David Baron
Amelia Bellamy-Royds
Christian Biesinger
Tantek Çelik
Dave Cramer
Benjamin De Cock
Elika Etemad
Simon Fraser
Chris Harrelson
Dael Jackson
Daniel Libby
Chris Lilley
Peter Linss
Anton Prowse
Manuel Rego Casasnovas
Christopher Schmitt
Alan Stearns
Lea Verou
Regrets:
Ravi Ramachandra
Florian Rivoal
Scribe: dael
Rossen: I think we're ready to start
Rossen: As usual let's go ahead and start with a call for any
additional items or changes.
smfr: The first item has been closed so we can skip
chris: He added it a couple days ago and now there's consensus.
CSS Color 4
===========
Prevent fingerprinting with deprecated system colors
----------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3873
AmeliaBR: Already in fonts 4 there's a vague warning about how
system colors have some fingerprinting potential b/c they
review user settings
AmeliaBR: I think browsers haven't followed up with changes. I
suggest now that we have a decision on which system colors
are useful for accessibility and which are legacy we go
one step further and say UI should not expose any
fingerprintable data in the deprecated ones
AmeliaBR: Especially true because some deprecated ones are so vague
that the data from browsers can't be used in a useful way.
AmeliaBR: Change from vague wording to normative requirement. These
colors would still have to result in a reasonable value,
but that should be determined by nothing more than the
combo of UA and OS. It shouldn't have any individualized
colors.
fantasai: Not quite
fantasai: Also consideration in cases where can map to a user color
they should do that
fantasai: If you map all background to canvas that seems reasonable
AmeliaBR: Okay.
AmeliaBR: You suggest that the deprecated ones could be consistently
mapped to one of the theme colors we are undeprecating. As
long as UA is consistent not additional fingerprinting
source
dbaron: One note is there was comment about how the properties are
not defined well. We do know how to define them well. I
tried to propose the definitions ~17 years ago. WG wasn't
interested in better definitions
TabAtkins: We accepted the definitions at least 6 years ago. They're
in spec
dbaron: I think some, not sure if all
TabAtkins: All ones in email we found when we transferred to github
are in the spec. If you've got more, great, we're glad to
take them
AmeliaBR: Might not be definitions, but that no one updated
implementations. There are one sentence definitions, not
sure when added
AmeliaBR: Background is one I brought up with different results
between browsers about which OS theme was exposed
TabAtkins: Chrome is nonsensical on background.
TabAtkins: I'm happy with this sort of change. We mandate that
deprecated system colors must not be more user specific
then good colors. They must map to good colors or is not
user specific. I'd be happy to do that and spec in more
detail how they work and what should look like.
TabAtkins: Given current lack of interop it's not like anyone is
depending on them so might as well give reasonable
definition for browsers.
TabAtkins: Sounds good to me all around
chris: Sounds good if browsers will do it
TabAtkins: No one uses the colors because no one can use them so
they're not high priority to work on. But they're good
first blood for someone to work on a browser. So I'm
happy to give definitions so that it can be done
myles: Web platforms need motivation
AmeliaBR: Making this normative and with tests are the keys to get
browsers to change
TabAtkins: Unless we mandate what the colors or mappings are I don't
see how to test besides run this on 2 machines and see if
it's different and that's not something test engine can do
AmeliaBR: Good point. Testing isn't set for you to control OS
settings. And even then we don't know which expose the
fingerprint
AmeliaBR: If we normatively say these colors must not be certain
values or must match a non-deprecated keyword we can test.
Might get false passes on a default install that doesn't
have user customizations
chris: [missed]
TabAtkins: I'm fine with specific colors. I want one for light and
one for dark
chris: White and black!
<dbaron> clearly the default set of colors should be whatever those
colors were in the default theme of Windows XP :-)
Rossen: This was stated as something used for fingerprinting for
people with accessibility needs?
AmeliaBR: Not just accessibility. Certain system colors have
accessibility needs but that's separated. We have list of
undeprecated ones with use cases. This is ones still
deprecated. Some expose user theme settings
TabAtkins: Not accessibility. It's a fingerprinting vector with no
gain
Rossen: I want to separate and make sure rest [missed]
TabAtkins: She's saying previously mix of used for accessibility and
just legacy. Accessibility ones are separated out. The
remaining only exist for backwards compat. We can remove
fingerprinting there because there's no value to them.
They have no reason to be user dependent
AmeliaBR: They are fingerprinting risk for everyone. Ones we're
keeping for accessibility benefits they still have a
fingerprinting risk but enough benefit to justify the
risk. These have no benefit to justify the risk
Rossen: That's fine. I think we're still abusing user accessibility
here but keep going
TabAtkins: Proposal: We come up with a set of mandated color
mappings for deprecated system colors, put in spec, and
write tests
many: sounds good
Rossen: Objections?
RESOLVED: We come up with a set of mandated color mappings for
deprecated system colors, put in spec, and write tests for
them
<dbaron> Worth noting that some UAs might want to make different
fingerprinting tradeoffs for the nondeprecated ones.
Rossen: Do we need item 1 from the agenda TabAtkins?
TabAtkins: No, looks good
Make system color keywords compute to themselves
------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3847
TabAtkins: Back in the day system colors could become rgb at
computed value time. Now that we can switch user themes
using color-scheme you can turn it on and off at subtree.
That changes what system colors resolve to
TabAtkins: Thus they should act like currentColor
TabAtkins: Talked to our impl and it's fine
chris: There was an issue about animation, but can animate
currentColor
AmeliaBR: Don't have interop on currentColor
AmeliaBR: As far as making system color keywords inherit as keywords
we want them same as currentColor. We just need
implementors to go through details of making currentColor
and these inherit as keywords
AmeliaBR: Right now FF does it. Chrome and I think WK do not
TabAtkins: Chrome appears to. I tested yesterday. We're doing it
sufficiently close to look correct in a test
AmeliaBR: Doesn't when you animate or you're newer chromium version
TabAtkins: Might be just passing my straightforward test
<tantek> interesting, thought we had enough currentColor tests to
get interop. curious about the test cases that demonstrate
non-interop
<dbaron> q+ for getComputedStyle
<fantasai> dbaron, getComputedStyle would return a resolved color
AmeliaBR: Complexities with animations; if we still agree
currentColor spec is right those same rules would apply to
making system colors inherit as keywords
chris: Makes sense to me
myles: Does that mean fingerprinting stuff we just resolved on is no
longer necessary?
TabAtkins: Nope because they always show as rgb in gCS
TabAtkins: That's a hard compat requirements, people have been
relying on it
chris: Need animation tests on current and system colors?
TabAtkins: Sure
AmeliaBR: With the caveat that we need more tests, any objections to
making system color keywords behave like currentColor and
inherit as keywords?
<tantek> inherit as keywords makes sense to me
<fantasai> +1, we need this for them to behave correctly in the
presence of forced-color-adjust / color-scheme
RESOLVED: Make system color keywords behave like currentColor and
inherit as keywords
Text system color conflicts with background-clip
------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4465
TabAtkins: When we introduced the set of new good system colors we
names one text. Means in BG shorthand supplying color
text conflicts with clip of text.
TabAtkins: It's going to be a problem when we unprefix
TabAtkins: Proposal is rename text to CanvasText which matches other
pairs. CanvasText is unambiguous and resolves situation
TabAtkins: And I don't think text was an old word
fantasai: Anyone shipped?
TabAtkins: No. FF wanted to but ran into grammar
Rossen: Same for us.
fantasai: In favor. Makes sense and less likely to conflict
leaverou: Agree
myles: Is it worth trying to come up with system to discover these
ambiguities automatically?
<tantek> that's what CR is for, right? ;)
TabAtkins: Sounds like it would be valuable, but a bunch of work
AmeliaBR: TabAtkins write a bikeshed extension for all grammars ^-^
<dbaron> Such a tool wouldn't have caught this because we haven't
actually written the grammar for the background
shorthand in backgrounds level 4.
Rossen: Objections to rename text to CanvasText?
smfr: I think WK has shipped text since KHTML days. Someone might be
using it in the wild
TabAtkins: Really? Never appeared in list from Color 3. I didn't
realize it was live
Rossen: Sounds like only in WK
smfr: Don't know if Chrome removed it post-branch
Rossen: I don't see in Chrome keywords
<TabAtkins> Looks like Chrome has removed it: <body
style="background-color: red; background-color: text;">
is red.
* smfr tested: chrome does not support color:text, webkit does
* smfr https://codepen.io/smfr/pen/YzzrBqZ
smfr: Other comment is I thought background clip text was being
replaced by something in fill and stroke?
TabAtkins: Replaced but can't remove
<tantek> what about WindowText? noticed that's in the MDN docs:
https://developer.mozilla.org/en-US/docs/Web/CSS/color_value
<leaverou> UIText may work too
<dbaron> this is presumably different from WindowText since
WindowText was a CSS 2.1 value
<dbaron> CSS 2.1 list is at https://www.w3.org/TR/CSS21/ui.html#system-colors
<TabAtkins> tantek, window/windowtext aren't a pair we chose to use
<tantek> cool TabAtkins, I guess we need to update MDN
<tantek> FYI Moz also has -moz-default-color User's preference
for the text color.
<TabAtkins> tantek, windowtext is one of the deprecated colors; just
not one of the good ones we're using for forced colors.
MDN is fine.
<tantek> TabAtkins, MDN should label it as explicitly deprecated then
<TabAtkins> tantek, yeah, a bunch of those should be labeled as such
AmeliaBR: Shipped in FF unprefixed. One thing suggested in the issue
is allow background clip text, but don't allow in the
shorthand. More complicated to impl and spec vs changing
the color keyword. If there is compat issue we want to
know what the impact is
chris: Possible to have old text value as an alias so it works in
the longhand but not allowed in shorthand
TabAtkins: Possible, but complexity we like to avoid if we can
fantasai: I think we should rename this. It's better usability and
less complex. If we need to support a text keyword that
means the same thing if we need it for compat we've got a
bunch of mappings we have to do. We should check and see
if need to address. If not maybe WK drops. If so we figure
out a way to handle
fantasai: As far as system colors we're promoting CanvasText makes
sense as will have less problems going forward
smfr: I'm okay trying to rename
Rossen: Objections to renaming?
RESOLVED: Rename text keyword to CanvasText
Publication
-----------
Rossen: fantasai did you say want to republish?
fantasai: Ready for a WD
Rossen: How about we publish a WD with these?
<tantek> do we have a changes section ready?
fantasai: Hold off on fingerprinting until sorted but the last 2 we
can do quickly
chris: There's other things I'd like to get in
fantasai: Which?
chris: A couple close to resolution. I also wanted to update the
changes list
fantasai: Can publish next week. Thinking good to get system color
stuff onto a WD since people want to ship
AmeliaBR: You've got 40 open issues so I'm sure it's going to me
multiple publications
chris: I don't want to close all, there's some possible and I'd like
to get them in
fantasai: Yeah
fantasai: Wait until next week?
chris: Friday is fine
RESOLVED: Publish a new WD for Colors 4
CSS Paint API and Typed OM
==========================
Current Color as an input to paint worklets
-------------------------------------------
github: https://github.com/w3c/css-houdini-drafts/issues/921#issuecomment-546459060
AmeliaBR: Related to what we talked about earlier. About
CurrentColor having a computed value of the keyword
AmeliaBR: For typedOM it's supposed to expose computed values, not
resolved. TypedOM doesn't have a proper model for a color
value so for the Houdini APIs that are getting computed
values using TypedOM objects they're just getting the
superclass version.
AmeliaBR: The issue is what happens if your Paint API relies upon a
color property and author uses CurrentColor. Example: Use
Paint API for a fancy border and relying on border color
property. What happens if border color is default
currentColor?
AmeliaBR: In Houdini currently that's exposed as a keyword and then
in your Paint worklet you'd need to depend on color to get
the keyword's value
AmeliaBR: In shipped Chrome the value exposed isn't a keyword but
it's where two string is rgb function which means current
Paint worklets are happily using that as a color string
they can pass to canvas. but it doesn't match spec
AmeliaBR: Suggestions are first we change the spec to not talk about
currentColor as a keyword which means for now currentColor
is treated as a vague superclass where all you get is a
string. Eventually when we have a color value class
defined currentColor would be represented in the class
same as any other color type.
AmeliaBR: Somehow at time we define this we make sure two string
value always gives us rgb function when applied to
computed style object
TabAtkins: Want to avoid inventing new resolved style. As much as
possible I'd like to keep computed style map returning
computed styles. That means Chrome impl is wrong and
needs to be changed
TabAtkins: Happy with currentColor becoming a CSS color value. It's
compat with that. I don't want to have the value coming
out of computed style map be a used value.
TabAtkins: It is clunky, but I prefer to provide a function that
lets you resolve color values in Paint worklets
AmeliaBR: Other option is to say Paint worklet knows how to resolve
keyword values. Covers most cases where someone grabs
computed style and uses it directly in the Paint commands.
So long as whatever string from typed OM is valid in Paint
commands covers most use cases. Wouldn't cover parse and
do math use case, but that's rarer
TabAtkins: Sounds good too. We can cover all use cases by having
Paint API canvas painting methods be able to take
contextual keywords directly and have Paint worklet have
a function to manually resolve colors into rgb for you.
Then keep computed style map actually a computed style
AmeliaBR: Are you okay...right now there's text in Typed OM that
currentColor is a css value keyword object can we say it
returns as superclass css value type even if string
reflects string of keyword until color models are specced?
TabAtkins: Yes, I think we should
TabAtkins: Need to make sure system colors do same thing
AmeliaBR: Actual change at this point would be remove all property
specific rules in typed om that require currentColor to be
returned as a css key value
AmeliaBR: Separate note for Chrome impl to match spec as far as
returning computed values which happens at same time as
change to paint API which allows keywords to be used in
the paint color properties. That's the other normative
change
<TabAtkins> 1. Specify that the PaintWorklet's canvas-ish methods
can take color keywords and do the right thing.
<TabAtkins> 2. Add a PaintWorklet global function that can resolve
color keywords into RGB.
<TabAtkins> 3. Fix Typed OM spec to ensure that currentcolor and
system color keywords reify as CSSStyleValue, not
CSSKeywordValue, until we have CSSColorValue for them
to reify as.
smfr: Other cases where authors want to convert currentColor to rgb?
Only Paint worklets sounds limited
TabAtkins: Problem is that if we want computedStyleMap to return
computedStyles we're going to have these cases where some
values at time being passed can't be resolved further
because of state. Layout worklets might want this. Other
worklets are in the same boat.
TabAtkins: Similar to resolving percentage and other use time values
that are useful.
TabAtkins: Colors are resolvable just after inheritance so might be
a special case that's handled badly by concept of
computed values
TabAtkins: Unless we define a 4th value mode and say computed style
map returns that I'd rather less convenient but
consistent rather then arbitrary mismatch
AmeliaBR: smfr had good point about universal way to get resolved
color keywords relative to context elements
AmeliaBR: Would expect that's part of spec how colors work in
TypedOM and also part of other color format conversations
AmeliaBR: With that in mind maybe don't do global function in Paint
worklet.
AmeliaBR: What we do need in short term is simple case within Paint
worklet if you use currentColor it works correctly
TabAtkins: Issue with resolve against element we don't pass anything
that's an element into a worklet. Can implicitly resolve
with a context. I think works for custom Functions
AmeliaBR: Model I suggested in issue for resolving values is that
the computed color value object is associated with a
palette that defines what color values represent for
keywords so it's passed in at that time
TabAtkins: At computed value time we don't know that yet. You could
say here's the possible values, but you don't know what
it ends up as. Unless we have another value stage between
computed and used we can't express that in a meaningful
way
AmeliaBR: When you know computed values you also know value for
color and color scheme. From those you know the palette
that describes what keywords mean for any other color
property
TabAtkins: I think you're right. I take it back. We can call this a
computed value that knows it's a keyword, but it knows
what it will turn into because we know other valyes
TabAtkins: Implies new dependency edges and need to think about how
to do those
TabAtkins: I do think there's a path forward
TabAtkins: The used value time colors should downgrade to generic
superclass. Paint API takes those and acts appropriately.
I'll work on how to solve getting you the colors properly
TabAtkins: I listed several things, I'll put 2 to resolve on
<TabAtkins> 1. Specify that the PaintWorklet's canvas-ish methods
can take color keywords and do the right thing.
<TabAtkins> 2. Fix Typed OM spec to ensure that currentcolor and
system color keywords reify as CSSStyleValue, not
CSSKeywordValue, until we have CSSColorValue for them
to reify as.
AmeliaBR: Do the right thing means when you use...
Rossen: I just wanted to know if we were resolving. If not, we can
just resolve on these
Rossen: Proposed resolution #1 is Specify that the PaintWorklet's
canvas-ish methods can take color keywords and do the right
thing
Rossen: Objections?
AmeliaBR: Do we understand do the right thing in this context? It's
using context of element you're painting
RESOLVED: Specify that the PaintWorklet's canvas-ish methods can
take color keywords and do the right thing
Rossen: Second is Fix Typed OM spec to ensure that currentcolor and
system color keywords reify as CSSStyleValue, not
CSSKeywordValue, until we have CSSColorValue for them to
reify as.
fantasai: This is change to typed OM?
TabAtkins: Yes. Currently says it's CSSKeywordValue and we're going
to superclass instead
fantasai: Wasn't point of typed OM is when you ask for computed you
get computed
TabAtkins: Yes, which is currentColor keyword. But we used the
superclass when we don't have something represented
specifically
fantasai: It's a keyword but expose as something else?
AmeliaBR: As a generic css computed value where all you can do is
expose the string
fantasai: Okay, gotcha.
Rossen: Prop: Fix Typed OM spec to ensure that currentcolor and
system color keywords reify as CSSStyleValue, not
CSSKeywordValue, until we have CSSColorValue for them to
reify as.
Rossen: Objections?
RESOLVED: Fix Typed OM spec to ensure that currentcolor and system
color keywords reify as CSSStyleValue, not
CSSKeywordValue, until we have CSSColorValue for them to
reify as.
AmeliaBR: All other things will turn into a proposal for L2
TabAtkins: Or L1, but later.
CSSOM
=====
Table row resolved width and height
-----------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4444
Rossen: emilio opened.
TabAtkins: If emilio, fremy and alexks aren't on we can't discuss
reasonably
Rossen: Fair. Looking through webex I don't think they are
AmeliaBR: astearns wants to ship shapes
CSS Transforms 2
================
Proposal new transform-style: detached
--------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4242
AmeliaBR: We introduced last week, but wanted to hold for Rik
<astearns> we could probably resolve on
https://github.com/w3c/csswg-drafts/issues/675,
but my audio apparently isn't working
CSS Transforms
==============
Provide a way to specify rastered content scale for transformed content
-----------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/236
smfr: Browser have traditionally rasterized elements to gpu texts
when authors apply something like 3d transforms.
smfr: Various attempts by impl to choose a good scale. User says
scale-3d 2,2,1 At least in WK we don't re-rasterize so it
becomes pixelated. Re-raster is hard because if content is
dynamic what scale? Right thing is let the author decide since
they're only one that really knows what's going to happen?
smfr: This issue proposes a new property to let authors spec
rasterization scale. Reasonable. UA should be able to decide
not to use that scale for reasons like memory
Scribe: TabAtkins
chrishtr: I'm not sure what the right API shape should be and how we
should describe it
smfr: I assume it would be `scale-suggestion: 2` or something
<TabAtkins> (i made up the property name)
AmeliaBR: I assumed `max-expected-scale`
AmeliaBR: Transforms are cumulative though; needs some detail about
how much accumulation is expected.
dbaron: Gecko at some point in the past tried to do smarter things,
and we did occasionally hit things where devs had an
expectation of the simpler WebKit behavior.
dbaron: One example was a very quick zoom-in animation; it loads by
starting big and quickly shrinking to the correct size.
dbaron: We had a bug where we were rasterizing with too much memory
in that situation. This animation was on the firefox home
screen so it was detected.
dbaron: So we did see some cases where authors didn't want the
logical rasterize to be at the highest density point,
because it was zoomed through quick enough to not matter.
chrishtr: I wonder if it would work to have something that declares
it will animate, with the curve or the balance.
AmeliaBR: Maybe add more info to will-change
AmeliaBR: will-change:transform isn't a lot of help; different
optimization for transform vs scaling
dbaron: I think will-animate isn't necessarily enough. Some
animations are slow and you want detail; others are fast and
you don't.
Rossen: So we're over time. Take this back to the issue.
Received on Wednesday, 30 October 2019 19:53:57 UTC