[CSSWG] Meeting Minutes 2019-10-30 [css-color-4] [css-paint-api] [css-typed-om] [css-transforms]

  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.


Agenda: https://lists.w3.org/Archives/Public/www-style/2019Oct/0027.html

  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

  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
  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

  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
  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
  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

  <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
  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

  <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:
  <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


  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
  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

  <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
  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
  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
  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
  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
  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.


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
  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
             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