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

[CSSWG] Minutes Telecon 2020-05-20 [css-color-adjust-1] [css-selectors] [css-cascade-4] [css-sizing] [mediaqueries]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 20 May 2020 19:09:04 -0400
Message-ID: <CADhPm3thwaa7op+kpDhpu3GNr5zM4uhu-ov2cvJcaKoLxv1k1Q@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 Color Adjust

  - RESOLVED: The color computed values are defined as used values
              using the color-mix function (Issue #4915: Is forced
              background-color computed or used value?)

CSS Selectors

  - RESOLVED: Expose this selector and name it ::file-chooser-button
              (Issue #5049: Can you standardise a pseudo-element
              selector for file inputs?)

CSS Cascade

  - The concerns about the spec allowing a 'revert' at computed value
      time (Issue #4155: Revert at computed-value time) may be
      addressed by the proposed !override property so as that's
      written this issue will be re-reviewed.

CSS Sizing

  - RESOLVED: Percent based gaps for flex in the cause of undefined
              constraint resolve to 0 (Issue #5081: Make flex %
              row-gap resolve to 0 when height is indefinite (only
              flex, not grid))

Media Queries

  - Most of the group was okay with deprecating speech (Issue #1751:
      Deprecate 'speech' media type as well?) but needed to hear from
      others before resolving.
  - There wasn't enough time on the call to dive deeply into issue
      #5044 (length units in video-* media features) but there was
      interest to continue conversation about the expected behavior
      for the video-* properties on github.


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

  Rachel Andrew
  Tab Atkins
  Rossen Atanassov
  Christian Biesinger
  Oriol Brufau
  Emilio Cobos Álvarez
  Dave Cramer
  Elika Etemad
  Simon Fraser
  Megan Gardner
  David Grogan
  Chris Harrelson
  Daniel Holbert
  Dael Jackson
  Peter Linss
  Stanton Marcum
  Myles Maxfield
  Nigel Megitt
  Anton Prowse
  Manuel Rego Casasnovas
  François Remy
  Florian Rivoal
  Jen Simmons
  Miriam Suzanne

Scribe: dael

CSS Color Adjust

Is forced background-color computed or used value?
  github: https://github.com/w3c/csswg-drafts/issues/4915

  Rossen: This is in the context of forced-colors-adjust.
  Rossen: Short summary is in the previous impl of what used to be
          ms-high-contrast and is now forced-colors we were reverting
          colors including background and override with system color
  Rossen: At the time at MS we didn't consider taking in the alpha
          channel of the color value.
  Rossen: That meant simply all overrides were stable during computed
          and alpha was always opaque
  Rossen: When working on forced-colors one addition to the feature is
          addition of considering alpha channel of the color. For
          background-color it means we now have to compute the final
          color value during used time
  Rossen: That's how issue came about. Is it supposed to be computed
          or used.
  Rossen: Is AmeliaBR or fantasai on?
  TabAtkins: We have me and I commented

  TabAtkins: Seems clear this needs to be used value time
  TabAtkins: Because we can't do anything with a system color until we
             resolve it which is at used value time because need to
             know color scheme
  TabAtkins: This is to make it reasonably work. Amelia's comment
             brings up the very good point that color mix function
             would be useful for this.
  TabAtkins: If you want to define a computed value that's this system
             color but with the other alpha you can do it simply with
             color mix function.
  TabAtkins: We could and should define computed value of color
             becomes a color mix function with alpha from previous
             color and mix with system color
  Rossen: What do we serialize in OM? used value?
  TabAtkins: All current properties do used
  Rossen: Okay, that continues to work
  TabAtkins: Not 100% clear/remember what happens in image properties.
             But plain colors do used value.
  Rossen: The ones covered by color-adjust are covered.
  TabAtkins: Yeah
  emilio: Not quite used value because :visited and so on
  Rossen: Sure
  TabAtkins: Ignoring :visited hacks they are always used values

  Rossen: Sounds like a good path forward for this behavior
  Rossen: Any other considerations or proposals to consider?
  TabAtkins: If we go with this is means implementors should
             prioritize color mix.
  TabAtkins: Also solves that you can't transition system colors since
             you can use color mix for that.
  Rossen: Sounds good
  <TabAtkins> color-mix(appropriate-system-color, specified-color
  Rossen: Proposal: The color computed values are defined as used
          values using the color mix function
  Rossen: Objections?

  RESOLVED: The color computed values are defined as used values using
            the color-mix function

CSS Selectors

Can you standardise a pseudo-element selector for file inputs?
  github: https://github.com/w3c/csswg-drafts/issues/5049

  emilio: Apparently all others than FF have a pseudo-element for this.
  emilio: Is anyone planning to remove it? If not, can we add a
          specific pseudo for this?
  Rossen: Is question about if component model for the control will
          change so there's no button?
  emilio: No, question is that all of them have a button and all UIs
          except FF expose it as a pseudo-element. Only reason to not
          make a standard version is if underlying model will change.
          I don't see a reason not to add this unless there are
  TabAtkins: Still vaguely uncomfortable about exposing internals of
             form controls, but I'm comfortable with this one. All
             files must have button and I expect will in future.

  emilio: Ideas on name?
  TabAtkins: Name in issue works for me
  Rossen: Can we future proof more?
  Rossen: Currently ultra specific to the input type = file. If we're
          going down the path of exposing selectors to target form
          controls I would hope more generic so if there are other
          input types that can have a button that this selector will
          match with them
  emilio: Not sure I agree. All different input types have values,
          mostly prefixed pseudo-elements. I don't think you
          want...I'd rather it be specific than potentially expand in
          the future and websites change because of that
  TabAtkins: Comfortable with button name. This is a naming convention
             that we could extend

  smfr: I don't like upload in the name. It's choose a file. Not sure
        it should look the same because this is a specific behavior
        about trigger UI file selection. If it says only image types
        it opens photo picker. Name needs to be generic
  emilio: Edge name is ::msbrowse
  <smfr> ::file-chooser-button
  <fremy> ::file-picker-button
  Rossen: We spent quite a bit of time bikeshedding that name back
          when we expanded our control model. I think it was debated
          quite a bit and I was on the other side of the argument. If
          everyone else is fine with it, sure.

  jensimmons: Curious about work around form control styling coming in
              the next few years. Will there be a pseudo-element for
              buttons? What's the names that have been discussed there.
  TabAtkins: I believe gregwhitworth and Nicole Sullivan have been
             working on that and doing user research. Work is ongoing
             but not sure the results.
  jensimmons: I know it's massive and lots of questions, but this
              feels like it should be designed in the context of that.
              Though I don't mean don't push for 2 years
  TabAtkins: I feel you. I think the use cases and name are clear
             enough I think this would be an alright one off to do.

  Rossen: Sounds like general agreement around the reasoning to expose
          this. Naming-wise let's not spend the hour bikeshedding.
          ::file-chooser-button or ::file-picker-button sort of fit
          what has been explained even if case you open an image
          gallery it's still a file
  Rossen: Can we pick one and move on? file-chooser or file-picker are
          good enough for now?
  <fremy> +1 to either
  <jensimmons> I'm ok with file chooser or picker or upload, etc. I
               don't really like "browse" — it's far too generic in
               the context of "browser" and plus a younger generation
               of people don't really know what 'browsing files'
  Rossen: I'll choose ::file-chooser-button. We can rename later
  <fremy> Rossen: ^_^
  Rossen: Objections to expose this selector and name it

  RESOLVED: Expose this selector and name it ::file-chooser-button

  <gregwhitworth> yeah, can we at least do anatomy investigation in
                  Open UI for this?
  <gregwhitworth> emilio: I added a comment regarding the Open UI work
                  to the issue:
                  Feel free to setup some time with me so we can begin
                  defining that and inform the pseudo element naming
                  and if there is need for anything else

CSS Cascade

Revert at computed-value time
  github: https://github.com/w3c/csswg-drafts/issues/4155

  Rossen: Brought up by Anders who would be best to summarize.
  Rossen: Base of issue is when and how do properties overwritten by
          forced colors get reverted
  Rossen: Based on the issue there is a pushback against if the revert
          rules can apply at computed value time and if this creates
          dependency between properties and the way revert and
          override work
  Rossen: Couple weeks ago took a resolution where we introduced the
          !override that can be used to override all the properties
          and all the adjust properties. At that point
          forced-colors-adjust property is not needed
  Rossen: Questioning if this issue will go away and we can close no
          change needed
  Rossen: Noted TabAtkins and fantasai as you made edits in this space
          you may or may not have gotten to this work. Can you tell us
          where you are with this?
  TabAtkins: We haven't gotten to it so not comfortable with details

  Rossen: On the face value would you think if we had !override (tbd
          name) specified and impl would that simply allow us to
          resolve this issue?
  TabAtkins: Given that this is the default...whenever forced-color
             is auto the UA stylesheet overrides. This is about
             effects of forced-color-adjust mode. The property just
             lets you turn things off. THe revert is what happens by
             default not something the author turns on
  Rossen: Yeah. My hope was we could use !override UA declaration
          instead of current revert
  TabAtkins: mmmm...possibly
  TabAtkins: If UA hid it behind MQ maybe
  <TabAtkins> And then authors could use !override to win over the UA
              style when necessary...
  Rossen: If UA spec color with !override forced-color and no user
          style matched with the equivalent you have the forced-color.
          If user wants to expose they can. That's why going down the
          path that override will solve this issue as well.
  Rossen: Given we don't have Anders on I'm fine pushing this by a
          week to see if we can make progress

  fremy: Quick note- Basically revert at computed time kind of does
         exist with :visited. We have stored in browser real style for
         rendering and style for :visited. If I understand spec we
         only need it for 2 properties, color and bg-color. Doesn't
         sound like a huge deal
  fremy: Doesn't seem complex. Examples in issue don't seem like
         reason examples. They're crazy scenarios. Works for scenarios
         in the spec right now.
  Rossen: I think we won't be able to make progress on this issue

CSS Sizing

Make flex % row-gap resolve to 0 when height is indefinite (only
    flex, not grid)
  github: https://github.com/w3c/csswg-drafts/issues/5081

  TabAtkins: We had a number of complicated threads about how to deal
             with percent gaps in grid. Had a good resolution. Gaps
             should act like tracks without content. Thus behavior of
             percent in gaps is same as tracks. Resolve to content
             size for intrinsic and do percent against it. Limited
             value for fixed size, but if everything is percent it's
  TabAtkins: We tried to apply different argument to move this to
             flex. Flex should work same as grid and resolve percent
             same way. Break symmetry argument we tried to apply. If a
             flex gap is empty percent than percent on flex item
             always behaves as auto. Never goes against initial size
             of container
  TabAtkins: More consistent is gaps act like empty items and make it
             so in a flexbox a percent gap resolved against indefinite
             size becomes 0. Avoids annoying extra work and makes
             percent consistently the same in flexbox.
  TabAtkins: We don't know if we put this in flex or grid or
             centralize in alignment, but we'll figure that out when
             we get to it

  Rossen: Agree we should have consistency on resolve percent against
          indefinite constraints. We do this is large number of places
          like intrinsic size with width undefined for all items in
          float, percent goes to 0 initially. Then when we layout with
          defined constraint we'll resolve
  Rossen: With that rule said the rest of rules for block layout where
          for example has same behavior as shrink to fit but in block
          direction things that depend on height don't make sense.
  Rossen: That is not true for when percent computed based on resolved
          height. Items positioned absolutely in box percent resolve
          fine because constraint of containing block is defined. Want
          to make sure we're not introducing a new behavior for how
          percent resolve during a layout regardless of layout types
          being considered
  Rossen: I sympathize with issue but I think in this case we have to
          decide do we consider percent gaps as resolvable during
          final layout pass of flex when all empty space if computed
          and all flexing is done? Is the height defined? Because
          that's when gap percent will be resolved and items positioned
  TabAtkins: We decided that. Percent on flex items do not consider
             that to be resolved. They stay as auto. Changing that in
             general is fine, but different for gaps vs flex items is
  Rossen: I was going other way, keeping same. If we have resolution
          for flex items that percent in undefined are 0 same should
          be true for gaps
  TabAtkins: Yeah. Resolve to be auto, but same deal. No content so
             become 0.
  TabAtkins: If you're in agreement and no one else is disagreeing

  rego: I don't like that we're changing for flexbox only because will
        be different between flexbox and grid since same property
        works different. In grid percent row gutters work nicely
        because you have overflow. I showed example in issue. In the
        end you have overflow items. I don't think it's useful and
        we'd have issues because not interoperable with tracks.
  rego: We can do what's proposed for flex but should do same for grid
  TabAtkins: You want to revert grid so percent gaps become 0 in grid
             and then we should be consistent so percent tracks don't
             resolve to size
  TabAtkins: I'm fine with that. It's consistent.
  Rossen: Not sure I'm on same page for grid. It will make grid row
          and column gaps behave asymmetric. If grid is in a block
          with defined width which is always the case (assuming left
          to right, top to bottom writing mode) the gaps of the
          columns resolve and gaps of rows go to 0
  Rossen: That will be bad, we've gone to lengths to keep rows and
          columns symmetrical. Grid is 2d by its inception and we felt
          keeping the symmetric true. Flex is 1d stack layout, even
          with multi-line. Applying a principle that's 1d in its
          conception to grid which is 2d doesn't always apply. In this
          case I don't believe it applies
  Rossen: Would rather go back and say percent gaps don't make sense
          which is argument I made when we added gaps. That solves all
          the issues. If people want defined gaps they can do it in px
          or fr in any layouts. Percent rarely makes sense in gaps
  TabAtkins: I disagree. jensimmons has examples of people using
             percent to build column with and than it makes sense to
             do percent in gaps
  Rossen: No, I won't say remove percent gaps. Pushing back on
          transferring rules

  rego: So in grid we have different behavior for column and row gaps,
        that's true. But you'll have different behavior in flexbox
        too. Some people switching from grid to flex and reusing gap
        will get strange behavior. Also my point is we implemented
        this 2 years ago and still don't have interop so we're not
        having issues here.
  rego: I don't like flexbox and grid different, it's very confusing.
  Rossen: Agree. Agree that column for flexbox will resolve gaps and
          row will not is terrible.

  rachelandrew: I don't necessarily think it's that confusing if
                flexbox and grid are different in this. Have
                difference in not being able to align items in main
                axis. Need to be clear about it. Grid the same in both
                dimensions is really important. Grid different rows
                and columns is confusing. Once people get their head
                around how flexbox is different it's okay, wouldn't
                like to change grid
  <TabAtkins> Agree with Rachel here.
  <Rossen> Strongly +1 to Rachel
  <TabAtkins> Also: percent gaps *only* do something reasonable if
              you're using percent item/tracks as well; percent gaps
              with non-% tracks automatically cause overflow, it's
              weird and bad.

  cbiesinger: Grid and flexbox already differ in some stuff. 1d vs 2d
              e.g. implied minimum size applies only main axis in
              flexbox and both in grid. There's precedent for
  Rossen: I think there's a general agreement around flex and how flex
          gaps should resolve. percent based flex gaps.
  <TabAtkins> I'd still be fine with changing percent behavior for
              Grid here to match Flexbox and Block.
  <rego> I guess Mozilla is fine doing the change for flexbox (as the
         spec behavior has been implemented in flexbox since 2 years
  Rossen: If I'm reading the call correctly most people don't want to
          transfer to grid and keep grid symmetric. Happy to resolve
          for flex now, but if this comes back to grid we can discuss
          in the future. We shouldn't say keep the same on principle.
          They're not the same.
  <TabAtkins> Note that we can bring up the Grid-% change separately;
              if we make this decision for Flexbox it'll be consistent
              later to change Grid.
  Rossen: rego mostly looking to you
  rego: If it's only me it's fine. I thought it was important to be
        consistent here. If it's only me I don't mind. I think it will
        cause confusion. FF had behavior for a while so I don't think
        web compat, but I'd like to know that they're fine.
  dholbert: I'm fine changing.
  dholbert: One note on grid situation, with grid in block axis there
            is a special scenario with indefinite height but something
            reasonable to resolve percent against. Pixel value grid
            template rows create implicit value. There's cases like
            that where you get definite height without content and
            useful to be symmetric for grid. I'm okay with proposed

  Rossen: Let's try to resolve
  Rossen: Proposal: percent based gaps for flex in the cause of
          undefined constraint resolve to 0

  RESOLVED: Percent based gaps for flex in the cause of undefined
            constraint resolve to 0

  <dholbert> example of the grid scenario I was mentioning (indefinite
             height on the grid container, but still indirectly a
             definite height from the grid-template-rows/columns
             properties: https://jsfiddle.net/dholbert/ebopac3n/
  <rego> dholbert: still you get overflow there, in both directions
         (not very useful to me); and also you can have the very same
         case in flexbox https://jsfiddle.net/h8u53ows/ (that will
         work different only for row gaps)
  <dholbert> rego, (right, there's overflow, but it's consistent/
             symmetric for grid there, and it doesn't have any
             percentages depending on content-measurement, which makes
             it a case that feels less terrible. *shrug*)

Media Queries

Deprecate 'speech' media type as well?
  github: https://github.com/w3c/csswg-drafts/issues/1751

  florian: Nowadays MQ are about media features where you can test
           aspects. Back in HTML4/CSS2 it was about media types that
           are exclusive. We had a bunch, some were speculative, some
           were made but not useful. Deprecated all media types except
           screen, print, and speech
  florian: Media types are exclusive so speech is not screen readers
           which still present visual on the screen. Speech is only to
           audio for example alexa reading a webpage or an audio book.
           Logical possibility for it to exist and some software is
           roughly like this. But I have not run across any software
           that implements speech media type. Others have also looked
  <Rossen> +1 to deprecating
  <fremy> +1
  florian: At the same time it happens repeatedly that people get
           confused and believe that speech is screen reader. So we
           should probably drop it and move it to deprecated media
           types where syntactically valid but defined to never match
  TabAtkins: Strong agree

  fantasai: I don't think this should be resolved until we've given
            Léonie an opportunity to comment
  Rossen: Is she on the call? She's part of the group
  fantasai: Nope
  nigel: Second we should wait
  nigel: Other thing that would be useful is, it described clearly
         there's lack of impl. If we take the suggestion to deprecate
         and never match if interest grows is there a backout route
         where we undeprecate it?
  florian: I don't think it would be a problem. There's no compat
           dependency so there's nothing that would block us from
           later declaring.
  <TabAtkins> Or, even if 'speech' gets poisoned, we can always add an
              'audio-only' type later if we end up wanting it.

  florian: If you want to wait for Léonie lets do so
  Rossen: Seems like most of WG is okay to deprecate. Reasonable to
          wait to hear from Léonie on this.

length units in video-* media features
  github: https://github.com/w3c/csswg-drafts/issues/5044

  florian: As we know length in CSS are interesting. All units fixed
           ratio to each other and either to physical measurements or
           pixel. For length in video what are we expecting?
  florian: I think a third one. video-width and video-height if this
           is 4k I'm expecting an answer in terms of pixels.
  florian: I don't think we discussed use case and usage in much
           detail. Do we expect video plane into angular css pixel?
           Maybe, but if that's the case do we need this? If it's the
           physical pixel we need to write that
  nigel: For using video pixels I think something exists in TTML specs
         where you can define root container region and say how big it
         is in pixels. If you're not doing that you get pixel
         resolution of video. So you can spec location and size which
         defines where you want stuff
  nigel: Similarly define font size in pixels. Very typical to use
         video pixels when authoring in that sense
  nigel: Bit of a push away because makes more sense to use relative
         dimensions to the rendering area as a percentage. For font
         size calc became complicated using percent fonts based on
         parent element.
  nigel: We introduced rw and rh which is relative to rendering area,
         not overall page
  florian: Another confusing thing is we're defining width and height
           of video plane but not saying what's in there. Assumption
           is that's only hardware generated so you wouldn't size
           fonts, but maybe I'm wrong?
  cpn: I think you're right. In full screen we're interested in
       knowing device resolution so we can select appropriate media
       representation for streaming
  cpn: Returning in device pixels is ideal
  florian: But for images we're not doing that but asking API to
           describe the sources and let the UA pick the appropriate
           one. Are we not doing that here? I believe you can desc
           multiple sources, no?
  cpn: If you're using video element you could. If you're using media
       source extensions that becomes web app's responsibility not the

  Rossen: We're at top of hour
  florian: I think I have a direction, but we should explore on github
  Rossen: I would encourage Chris and Nigel to interact on that issue.
          You've got the people to solve this

  Rossen: We're at the top of the hour. Have a great rest of your
week. Stay safe and happy and we'll chat next week.
Received on Wednesday, 20 May 2020 23:09:46 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 20 May 2020 23:09:47 UTC