W3C home > Mailing lists > Public > www-style@w3.org > February 2020

[CSSWG] Minutes Telecon 2020-02-26 [css-pseudo-4] [css-color-adjust-1] [css-images-3] [css-images-4]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 26 Feb 2020 21:38:02 +0200
Message-ID: <CADhPm3syDQ437w4mHYid7n5Y6KSV9rWh5KLtVj5hguHtRBEYeQ@mail.gmail.com>
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 Pseudo 4

  - There is an announced intent to ship the WICG Custom Stats Pseudo
      Class spec ( https://github.com/w3c/csswg-drafts/issues/4805 |
      https://wicg.github.io/custom-state-pseudo-class/ ). The TAG
      recently gave their review and the working group discussed the
      proposal and the feedback on the call.
  - Though this proposal only exposes a boolean value the pseudo class
      was designed to allow extension to multiple values in the
      future. There was concern that the JS API did not appear to have
      the same extensible design.
  - Several people were interested in exploring changing the name from
      :state to :--name though if the name changes :path should also

CSS Color Adjust

  - RESOLVED: If the color scheme of an iframe differs from embedding
              document iframe gets an opaque canvas bg appropriate to
              its color scheme (Issue #4772: `color-scheme` should
              affect embedded iframes)

CSS Images

  - RESOLVED: Add this [text to allow dithering] to Images 3 and 4
              (Issue #4793: Allow dithering as a gradient-painting

===== FULL MINUTES BELOW =======

Agenda: https://lists.w3.org/Archives/Public/www-style/2020Feb/0021.html

  Rachel Andrew
  Rossen Atanassov
  David Baron
  Amelia Bellamy-Royds
  Christian Biesinger
  Oriol Brufau
  Emilio Cobos Álvarez
  Dave Cramer
  Elika Etemad
  Javier Fernandez
  Simon Fraser
  Chris Harrelson
  Daniel Holbert
  Dael Jackson
  Dean Jackson
  Brian Kardell
  Brad Kemper
  Chris Lilley
  Peter Linss
  Stanton Marcum
  Anders Hartvoll Ruud
  Christopher Schmitt
  Jen Simmons
  Alan Stearns
  Lea Verou

  Florian Rivoal

Scribe: dael

  Rossen: We are 2 minutes past the hour
  Rossen: Let's get started
  Rossen: As usual I wanted to ask if there are any additions to the
          agenda you want or changes to it?
  Rossen: I have a couple of things to start with
  Rossen: Potentially push the 2nd item toward end of the call

  Rossen: Other things I wanted to talk about where we have upcoming
          F2F which is going to be in Cork Ireland at end of April
  Rossen: Given this is usually the time people start booking travel
          the one thing I wanted to bring to attention is all the
          COVID-19 virus happenings
  Rossen: I don't know if this will be effected but use your best
          judgment when booking. We're nearing time when affordable
          travel window is closing
  Rossen: Anything else about the F2F from organizer PoV?
  Rossen: Assuming we're good. I know hober isn't on.
  smfr: As far as I know everything is fine
  Rossen: Yep, nothing to be concerned about yet but hard to predict
  jensimmons: Glad you brought this up Rossen. It seems likely to
              sweep through Europe. I've heard people recommend travel
  jensimmons: Something for group to think about at what point do we
              call this. What would it look like.
  TabAtkins: Similar to when there was the reactor meltdown in Japan
             and we almost didn't make quorum but had enough to hold
             it. We'll look for people to drop out and monitor for if
             we make quorum
  Rossen: Yep, I think we'll monitor. I don't want people to freak out
          for no reason, but things are escalating

CSS Pseudo 4

Custom state pseudo class proposal
  github: https://github.com/w3c/csswg-drafts/issues/4805

  Rossen: This is about a custom state pseudo classes. Being worked on
          in WICG.
  Rossen: Ready to be shipped by chrome in I believe 82 which is 4 or
          6 weeks from now-ish. I don't know exact dates for when it's
          on by default but feature will be spread and enabled for
          large amount of users
  Rossen: Some of TAG feedback was around shape of API and it only
          allows bool state checks
  Rossen: This was acknowledged by feature authors but dismissed as
          can live with for now
  Rossen: Talking about with WG is I looked through past feature
          discussion and didn't see this covered. Before it's too late
          wanted to give air time with group and gather if any
          reservations or concerns
  bkardell: I wanted to mention that a whole bunch of people from WG
            have been involved in design and discussion. This is like
            constructible stylesheets where that's the case and it's
            hard to know right venue for discussion. Given there's
            history and thought would it make sense to present a bit
            about it?
  Rossen: Sounds great. If you want to take a couple minutes and frame
          the feature and intent it would be great. Are you the right
          person or should we ask somebody else?
  bkardell: I suppose I could, but TabAtkins is on and can do a good

  TabAtkins: Been a bit since I looked at it. Core deal is custom
             elements sprout a new DOM token map that takes strings.
             Can match with :state you say :state(token) and it can
  TabAtkins: Reason is you want to expose internal selectors can match
             without manipulating visible dom. Shadow dom is a lot
             about exposing attributes without impacting outside.
             Design is canted toward that direction where it's bool
             token or not. Future room for name and value but right
             now it focuses on class
  bkardell: Not unlike :focus, :hover internal states
  TabAtkins: That's what it's meant to be able to expose. Internal
             states like that. It could be done via a class but b/c
             it's UA it's pseudo classes

  Rossen: Questions here. Is the current proposal in it's form going
          to preclude addition of anything other than bool?
  TabAtkins: No. Syntax is easily extensible to allow it when we want
             to do it.
  Rossen: And this was major concern raised and attempted to be
          debunked in issue I linked to. It was that there are no
          interesting bool states and no need to feature creep.
          Checkbox has 3 states and things like that. As long as
          non-bool aren't precluded in the future this is not too bad
  TabAtkins: Correct. Nothing would prevent that in the future
  <bradk> So, not really for things similar to ‘nth-child()’ ?

  emilio: This is for top level custom element, right? Find it weird
          it works for custom and not regular elements. Exposing
          states from parts they must be custom or different like
          tokens. It's a bit ugly
  emilio: Let's say you want to expose a state in a component. It
          would only work if the part is a custom element. If you
          don't want custom for example if it's SVG you need part
          elements instead using :state which is meh. Why doesn't it
          work for all elements?
  TabAtkins: Main reason is...easier to put this structure on the root
             instead of arbitrary elements. You articulate a good use
             case for parts of shadow element exposing states.
             Ordinary element can just use class and multi ways for
             same thing is weird. Leads to there is a way to do bool
             state in parts which is add more part names. Parts are
             basically classes and states are basically classes
  emilio: Could use same argument to say top level element can use
  TabAtkins: But then if you use class component messes with outer
             page visible section which we try and avoid, especially
             with things like aria stuff we're trying to mess with.
             Exposing controls without visible extra attributes is the
             goal of shadow dom. That's what's different for class.
             Doesn't apply to state vs part
  emilio: Okay, I can buy that. A bit weird to have 3 ways to attach
          bool token to element
  bkardell: If you read the issue there is a desire to have parity
            where we could do the same thing on focus and hover type
            elements. They work today and it would be handy to have a
            custom element where you can have state. I agree this
            isn't solving all problems like this but I think the idea
            here is limit the scope

  plinss: Two concerns
  plinss: I accept that majority of use cases are bool. There are
          examples of non-bool state. Happy it's extensible in css but
          JS api is not in a way that's dev friendly. There's already
          things that are map-like but we don't use map api. I'd like
          work done on api to make it more future proof. I'd like it
          to be able to handle non-bool cleanly
  * emilio agrees with plinss
  plinss: Second is should it be :state or :--[name] and really make
          it a custom pseudo class and not an odd pseudo class called
  TabAtkins: Not a bad suggestion. Alright.
  plinss: If we change this to :--[name] I'd like to see part do the
          same for consistency. For syntax they should be a unit. I
          have other issues with :part but that's separate convo
  <bkardell> I have brought this up in the past, I think :--name  is
             more interesting, but I think the argument is made this
             is diff and specifically about a kind of parity
  fremy: I think plinss brought a good point. Thinking similar. I
         understand TabAtkins' argument about need for aria mapping
         not changing with setting attribute. But we could do same as
         :part Maybe we want JS API to be able to remove values not in
  fremy: I don't understand why we need :state and :part. Why can't we
         have same API that applies on the same thing as :part. Maybe
         it's a point to think about
  plinss: That ties into my issues about part. I think it's valid to
          have custom state and custom part. How part is now is like a
          pseudo class and I'd like to be a pseudo element thing. Then
          it makes sense to have them as 2 things
  <bkardell> can I ask how is it the same as parts, it seems not the
             same to me... ?
  <bkardell> +1 what peter said
  <bkardell> and to what emilio said :)
  fremy: Can query multiple part things, but I was going to mention
         that [missed]
  fremy: It does make sense, fine.
  TabAtkins: Switching to :-- we're switching to tag name not class
             name. Requires if people to decide if it's class name or
             part name like. Maybe shouldn't expose to authors.
  TabAtkins: Can we put this in GH repo? This is good.
  plinss: I raised this in TAG review and didn't get a fair shake I
          felt. It would be good if it's addressed. You and I can
          haggle on :part separately. This is about :state for now

  Rossen: Given we're 30 min into call I think reasoning and
          motivation to put this in group is achieved. Raising
          awareness and getting right people while we can provide
          feedback and engage with folks getting ready to ship.
  Rossen: I see two people on queue. I'd prefer to move on unless
          emilio or bkardell want to bring something pressing
  bkardell: One thing before it's lost. Of course I 100% agree with
            plinss with wanting to see :-- for custom pseudoclass and
  bkardell: Question worth getting plinss and group thought is if
            that's the same as this or if this is discrete and about
            custom elements. It's been portrayed to me that they are
            different. Encapsulating state is a different things then
            a general purpose pseudo class
  bkardell: Interesting to think about
  Rossen: Let's continue in linked gh and WICG.
  Rossen: We'll also take this is TAG

  <fantasai> Fwiw wrt :--statename vs :state(statename), I think
             latter is better, clearer, more consistent with
             ::highlight(), easier to extend

Media Queries 5

  Rossen: Skipping 2nd topic because florian is not on, but I
          encourage you to review
          ( https://github.com/w3c/csswg-drafts/issues/2370 ).
  Rossen: This is about having the first working draft published and a
          new issue being added to MQ 5 post that decision. Question
          is would it be fine to fold the new issue intp fpwd or roll
          prefers-reduced-data back out and publish fpwd

  chris: We're unable to publish fpwd where there's a delta spec
         currently. Letting people know that even though it was a few
         weeks ago with resolutions those are still on the queue

CSS Color Adjust

`color-scheme` should affect embedded iframes
  github: https://github.com/w3c/csswg-drafts/issues/4772

  Rossen: This was added by Chrome folks
  chrishtr: Problem with dark backplate behind iframe is it's not dev
            controllable. Proposal is there be a white or black
            backplate of an iframe if the owner element has a
            different color-scheme
  chrishtr: A frame with an iframe have both dark you get that. One
            light and one dark backplate you get this.
  chrishtr: backplate is the canvas behind the root element
  <fremy> +1 to chrishtr's proposal
  <dbaron> Is this specifically black/white background, or is it dark/
           light background?  (i.e., are we requiring exactly black/
  <dbaron> (seems like it should match what's required for the root

  AmeliaBR: Document canvas. We have legacy issue that iframes don't
            have document canvas but we also have expectation that if
            child document says it supports darkmode it assumes part
            of that package is browser painting dark canvas. One
            document embedded in the other and one does darkmode
            switch things can get unreadable. Proposal is iframe
            canvas is by default transparent unless mismatch between
            embedding element and root element. With mismatch you draw
            opaque canvas on
  emilio: With used color scheme of iframe?
  AmeliaBR: Yes. canvas system color of root element of iframe
  emilio: Makes sense
  AmeliaBR: Might not always be great for svg. Might need an issue
            that this may only apply to iframes or something. Not sure
            which is worse, color mismatch or chance at a transparent
            background. Specifically for webpage and iframe this
            should handle most cases. Open issue on svg

  Rossen: Detectable from within frame?
  AmeliaBR: Shouldn't be. No way within doc to tell what the canvas
            color is because it's before root background so not
            accessible to cssom
  emilio: Work for cross origin iframes?
  Rossen: That's why I asked. If there's additional information
          provided through mechanism to cross origin that's not today
  AmeliaBR: Shouldn't be a way from embedded to tell if opaque drawn
            or not. Might be a user tricking way for parent doc to
            figure out if content is transparent based on if user can
            read content. I don't think there's a direct dom way outer
            document could tell
  TabAtkins: Other than tricking user the information isn't exposed to
             embedding or embedder
  emilio: Timing attacks from masking iframes and I'm assuming drawing
          opaque background is cheaper you could get creative
  chrishtr: Isn't that potential risk anyway?
  emilio: Would allow you to detect if there's a difference assuming
          you can detect painting of background
  AmeliaBR: Maybe add a warning to avoid the timing attacks by taking
            care when optimizing rendering into opaque iframes

  Rossen: Besides the note sounds like consensus around how it should
          work. Any additional comments or objects to making the
          canvas of embedded documents match canvas of embedding
          document by either matching internal color scheme or
          applying opaque canvas in a case of mismatch
  emilio: Assuming designing a doc designed to be embeddable can you
          design to match? I guess not and this does not solve. Mostly
  AmeliaBR: That was my other proposal. The support color scheme
            option on child doc interpolation based on parent and that
            was possible cors issue because then child doc would be
            able to tell...
  emilio: Yeah
  emilio: Okay. No concern.
  Rossen: I didn't hear objections
  TabAtkins: If the color scheme of an iframe differs from embedding
             document iframe gets an opaque canvas bg appropriate to
             its color scheme
  dino: If owning doesn't provide color?
  AmeliaBR: Legacy color scheme is still considered

  RESOLVED: If the color scheme of an iframe differs from embedding
            document iframe gets an opaque canvas bg appropriate to
            its color scheme

CSS Images

Allow dithering as a gradient-painting strategy
  github: https://github.com/w3c/csswg-drafts/issues/4793

  TabAtkins: webkit uses dithering to make gradients better. This is
             great. Spec does not allow and dictates every pixel.
             Technically webkit violates but I think spec should allow
             in both css and canvas
  <smfr> (and svg gradients)
  <dino> Related PR on WPT -
  TabAtkins: If no one objects I'd like to add a few paragraphs to
             images to allow dithering. Not sure if you want to say
             yeah you can dither or if we want to put some
             restrictions where you should be close like we do for box
  <dbaron> A downside of this means it becomes even more difficult to
           reftest gradients...

  bradk: If it displays and you only have 256 colors no dithering?
  TabAtkins: CSS doesn't recognize less the 24 bit color. Otherwise no
             it does define what the display color should be
  dino: CSS spec defines theoretical color. If you display on black
        and white monitor that's not css problem

  dino: I referenced PR where I changed test to allow dither. It's 2
        out of 256 slots can be different in any channel. In practice
        our dithering is in that range an not all bands.
  dino: Reason we do this is because it does make gradients look

  Rossen: Let's see if we can move to resolve
  Rossen: Sorry chris I didn't see the queue
  <bradk> Sorry

  chris: I agree we should allow this. Surprised reading of spec means
         it's disallowed. This is wide practice where you need to do
         things like dither. For testing we need to sample on small
         area so it averages and you get mean result. I'd be
         astonished if we disallow
  leaverou: Shouldn't disallow better visual result for testing
  <fantasai> +1 to leaverou
  TabAtkins: No one is arguing don't allow dither. I defined what the
             color of a gradient should be and didn't think about
             dithering it around.
  <smfr> you can still do reference testing with some SVG filter stuff
         to batch the pixel values
  chris: Disagreement I have is 5%, what does that mean. 2 counts in
         rgb is noticeable in some places. I was suggesting delta-e,
         maybe that's hard to do. 5% is meaningless.
  TabAtkins: I don't care that much, you won't dither badly. It's what
             boundaries can we put on tests to pass a good
             implementation and not pass a bad one. We did 5% on
             shadows because that lets you say here's the ideal and
             get close to it. I was going for same deal where it
             detects when you've gone widely off
  AmeliaBR: Do we have useful reftests for shadow blurring or is that
            arbitrary rule in spec?
  TabAtkins: Don't know
  dbaron: At least one test which I wrote
  <fantasai> Here is dbaron's test
  chris: In general hardly have tests for gradients b/c hard to figure
         out how to do automatic reftest
  smfr: You use svg image and then mask out areas that should be
        solid. We have tests in wk
  <chris> can you sent those wk tests to wpt?

  <bradk> Are  monitors with larger than normal color gambits not
          allowed to display more colors in the gradients?

  dbaron: Is there a spacial requirements for the dithering? Is it
          color distance, spacial distance or both?
  TabAtkins: I had example text and my intention was color distance of
             ideal color
  dbaron: wk test depends on spacial distance
  TabAtkins: Can you describe that?
  dbaron: That's what I heard from smfr but maybe he can explain. I
          thought her said it was for solid segments and masking
          pieces of boundary
  smfr: With continuous gradients you can do component transfer on top
        to posterize the gradient, convert a range to a flat color.
        Hides some issues but lets you test interp color stops
  TabAtkins: Artificial banding to get close to idea
  smfr: Correct
  <dino> If you pick the components correctly, you can emphasize the
         banding in the gradient, and then mask out the relevant
  <dbaron> smfr also said before the minuted part that they or (or you
           can) do that for solid parts

  chris: Two types of dithering. One is higher precision. Calc color
         and dither to get mix.
  chris: More common is dither position on gradient so if you have
         linear instead of a vertical line you fuzz that. I think FF
         is doing that. We need to allow both
  chris: smfr or dino can you confirm?
  chris: [repeats] I'm assuming you're doing the latter, dither on
         gradient axis.
  smfr: I don't think it's directional, jut adding noise
  dino: When I suggested a test that you show I'm testing, not what we
        do. It's a noise filter on result
  chris: I see
  smfr: It's not wk it's the underlying graphics that's using gpu
        shaders and stuff

  <smfr> example of a test using feCompontentTransfer:

  chris: Seem to have consensus spec shoudl say this, question of how
  AmeliaBR: Can we resolve on general spec and then get people to give
            specific examples of how to test?
  Rossen: Yep.
  Rossen: Obj to Add this to Images ?
  TabAtkins: I'll put it in 3 and 4
  Rossen: Objection to add this to Images 3 and 4

  RESOLVED: Add this to Images 3 and 4

  Rossen: Anyone with tests they can contribute to wpt please convert
          them so they can be used as ref tests

  Rossen: There's a few items we'll push to next week as well as MQ
  Rossen: Next call is APAC time
Received on Wednesday, 26 February 2020 19:38:45 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:15:13 UTC