[CSSWG] Minutes Telecon 2021-03-31 [css-cascade] [css-pseudo] [css-values] [css-break] [css-color] [css-flexbox] [css-sizing]

=========================================
  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.
=========================================


Cascade / Pseudo-elements / Values / Fragmentation
--------------------------------------------------

  - RESOLVED: The return value of getComputedStyle to match Firefox
              behavior that first-line is ignored in getComputedStyle
              (Issue #1510: currentColor when fragments have different
              colors)

Color
-----

  - RESOLVED: Clamp values between 0-100, all other values are invalid
              (Issue #6047: How should negative percentages behave in
              color-mix()?)
  - RESOLVED: Highlight color represents selected text color which is
              what you'd use for ::selection (Issue #6008: Consider
              clarifying Highlight system color, and maybe adding a
              new system color for control background)
  - RESOLVED: Add keyword to represent selected item with name TBD
              (Issue #6008)

Flexbox & Sizing
----------------

  - There were some complex questions which need to be discussed in
      order to resolve issue #6069 (Interaction of flexbox minimum
      height and aspect-ratio minimum height) and the group ran out of
      time on the call to cover them all. Discussion will continue on
      github.

===== FULL MEETING MINUTES ======

Agenda: https://lists.w3.org/Archives/Public/www-style/2021Mar/0029.html

Present:
  Rachel Andrew
  Rossen Atanassov
  Tab Atkins-Bittner
  Christian Biesinger
  Mike Bremford
  Oriol Brufau
  Emilio Cobos Álvarez
  Elika Etemad
  Simon Fraser
  Megan Gardner
  Chris Harrelson
  Daniel Holbert
  Dael Jackson
  Sanket Joshi
  Jonathan Kew
  Daniel Libby
  Chris Lilley
  Peter Linss
  Myles Maxfield
  Morgan Reschenberg
  Jen Simmons
  Miriam Suzanne
  Lea Verou

Scribe: dael

Reminders
=========

  Rossen: Let's get started
  Rossen: Couple of reminders
  Rossen: Next week is our extended call time
  <Rossen> https://wiki.csswg.org/planning/virtual-april-2021
  Rossen: I would encourage you to put your name on the wiki if you
          are going to be present during next week's extended call
          hours
  Rossen: Tuesday and Thursday pacific time
  Rossen: We have 9 issues marked. We'll need at least that many to
          fill the days. Please mark issues needing discussion and
          good for F2F
  Rossen: When you put yourself on wiki we can manage the schedule

  Rossen: I wanted to also remind you, last week astearns talked about
          longstanding PRs. Made a bit of progress, thank you to those
          that engaged. We have more, so please pay attention to those
  Rossen: I think we have a few documents ready for publishing, but
          not yet published. It would be good to push through
  Rossen: Any last minute agenda items or anything you want changed in
          current?

Cascade / Pseudo-elements / Values / Fragmentation
==================================================

currentColor when fragments have different colors
-------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/1510

  <fantasai> https://github.com/w3c/csswg-drafts/issues/1510#issuecomment-803203212
  fantasai: We discussed what to do when an element is fragmented so
            it has different parentage. Span split between first and
            second line and there's a first-line pseudo. Decided on
            inheritance and a bunch. Resolved currentColor or em or
            resolved per fragment
  fantasai: Firefox has implemented this based on test cases in issue.
            Edited in
  fantasai: Don't have answer when you call API like getComputedStyle
            on the element. Has one style per element. Proposal is
            define the API which assume single value per box must
            ignore effect of non-tree abiding elements
  fantasai: Means span split across 2 lines pretends first-line pseudo
            is not there. You don't have to compute differently if
            have broken across lines. Seems to be what Firefox is doing
  fantasai: Want to run past working group

  Rossen: Proposed behavior is similar to that of first-line for
          getComputedStyle?
  fantasai: Talking about defining the case of first-line for
            getComputedStyle
  Rossen: Rephrase: if you have an inline item that has a spec
          line-height and you do getComputedStyle and that line item
          has a number of fragments, one if first and one in second.
          getComputedStyle will return the first. Perhaps line-height
          isn't good example. What returns used values
  TabAtkins: Color
  Rossen: What would color return?
  fantasai: Color it will ignore the first-line style. First line is
            blue, span on second line and it's black. Span splits it
            returns black. Span on the first-line still returns black.
            That way browser doesn't have to take into effect if the
            span breaks. We ignore first-line styles
  fantasai: Could say take style of first box fragment. That's another
            possibility

  Rossen: Okay, makes sense. Thank you
  Rossen: Any feedback?
  Rossen: If not we can call for objections
  oriol: Concern is usually cascade is in element tree and this is in
         fragment tree. Given display:contents you can have elements
         without fragments in fragment tree. Not clear it's well
         defined. Might be outside of scope of the issue. It may need
         extra work in the future in another issue
  Rossen: Thanks oriol
  fantasai: Either way we need an answer for what getComputedStyle
            returns
  Rossen: Proposal here is have the same behavior as Firefox and as
          you described for color?
  fantasai: Yep
  fantasai: 2 things that could make sense. Return the styles ignoring
            first-line. Other is return style of first fragment.
            Firefox has implemented first option so we propose that.
  Rossen: Implementation point of view this is easier. User point of
          view these are equally wrong since you don't have per
          fragment access. For consistency sake with current impl I'm
          in favor of that proposed behavior
  Rossen: Not hearing other proposals. Objections to resolve return
          value of getComputedStyle to match FF behavior that
          first-line is ignored in getComputedStyle

  RESOLVED: The return value of getComputedStyle to match Firefox
            behavior that first-line is ignored in getComputedStyle

  Rossen: Anything else on this?
  fantasai: Just need to fold in edit

CSS Color
=========

How should negative percentages behave in color-mix()?
------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/6047

  Rossen: Do we have right people to proceed?
  many: yes

  TabAtkins: chris, leaverou feel free to jump in
  TabAtkins: A few weeks ago talked about color-mix and grammar.
             Matching so each color has a percent and normalize to
             100% if don't sum
  TabAtkins: Further question about what should allowed range be.
             cross-fade only allows 0-100 and if you exceed it's
             invalid. leaverou and chris argue allowing other values
             make sense. Have justification for it that I can't parse.
             una and I on side of not doing that and matching
             cross-fade
  TabAtkins: Argument is that negative percent and greater percent
             don't accord with mixing colors we're trying to define.
             Not intuitive, though mathematical, and would confuse.
             Also, when normalize to 100%, that is extraordinarily
             weird with negative percent
  TabAtkins: You have to grow values to sum to 100% and get very
             strange large results. red 100 and blue -100 there's no
             way to resolve. Sometimes you get sum but multiply by
             negative to get it. Even if it's well defined the edge
             cases are very weird.
  TabAtkins: leaverou and chris have added explanations, but I think
             they contradict
  leaverou: Not sure we should base on cross-fade which is something
            not widely implemented. Only 1 or 2 implementations and at
            least webkit is not per spec. Not sure why design based on
            that.
  leaverou: Main point is there is a place in css where we color
            interpolate and allow wider range. In transitions. You can
            have cubic bezier that's out of range and it does what
            chris and I advocate
  leaverou: Can look in issue for results, don't think it's
            unintuitive. If you mix with blue -% you get a less blue
            color. Blue coordinates in sRGB is less but hue is less
            blue which is what matters
  leaverou: If you mix -100% something it's weird, but edge cases that
            are weird in everything
  TabAtkins: What you said is wrong. It doesn't make it less blue.
             It's dependent on other color. I have an example where
             -blue + green is more green
  chris: We need to avoid saying you are wrong in these discussions.
  chris: We're talking about a hue angle. Not gamma encoded.
  TabAtkins: Agree you don't get a hue. I have green + negative blue
             and you get more green channel
  chris: You're looking at gamma encoded channels. Can't do it like
         that. Look at actual color
  TabAtkins: Would you like me to show you color and you can tell me
             hues
  chris: Not going to do calculations on the fly
  chris: You can't present as leaverou and chris have weird idea,
         color science has this idea. There is a positive case. You
         get ringing artifacts on the transition. We're not saying
         great use case for -300%. We're saying sometimes you have
         slightly over or under. You have line extend out past the 2
         colors on chromatics.
  chris: I get it could be unintuitive, but possible to spec and
         reasonably useful. I'm fine with clampping 0-100, just
         suboptimal
  leaverou: If we end up not allow they should be invalid. Silent
            clamp there's no feedback to authors and can't change

  Rossen: Point of order. Conversation is lively. chris I appreciate
          working with tone. I want to discourage blaming and direct
          language. Let's focus on issue here.
  TabAtkins: Real quick, I'm talking about facts here. Casting me as
             saying this is technically wrong is being heated is
             disappointing. I don't want this as TabAtkins is angry
             because I'm saying the math doesn't back up what you're
             saying. As far as I can tell my examples show that the
             math is wrong. I want to focus on that
  Rossen: Let's continue to focus on that math. Leave personal out of
          discussion
  Rossen: There's 3 folks on the queue. leaverou and chris you had
          taken turns. Are you done?
  chris: Let's let miriam speak

  miriam: Reading this from mental model I liked in TabAtkins last
          comment the suggestion if we want allow negative mix better
          framed as color interpolation. If we want extending past the
          mix that would get a new name and syntax. For mixing we
          would clamp or make invalid numbers above or below 100 or 0
  Rossen: Hearing 2 folks suggesting clamping between 0 and 100 is
          fine as long as rest of range is handled as invalid
  chris: Agree. Silent clamp we're struck so if restrict have to
         invalid
  TabAtkins: Agree

  florian: chris said he won't do color math on fly. Reasonable. If he
           would do it offline it will show where the math mistake is.
           Based on that if he disproves one math there's no reason to
           continue.
  TabAtkins: Happy to do that. Have a trivial example with single
             numbers we can look at and talk about
  florian: I would suggest we do it offline. Make sure everyone has
           math right

  chris: If we agree we're on 0-100 only we don't have to care about
         math for others. We could get a decision. Would be okay with
         it. We can extend later if needed
  Rossen: I want us to get to a decision. leaverou is on queue
  leaverou: Silent clamp or invalid, cubic bezier used to be invalid
            outside 0-100. I suppose it wasn't deemed useful, realized
            authors wanted it, and we did it. Making it invalid would
            allow a similar path
  Rossen: More support to making invalid
  Rossen: I heard support from a few folks and TabAtkins saying it's
          fine, I think
  TabAtkins: That's my ideal result. Happy
  leaverou: I'm not suggesting we make it invalid. suboptimal. but
            invalid is less evil than clamp
  <fantasai> +1 to leaverou
  Rossen: And gives a path to make better when we're ready. Instead of
          continuing to argue on what we're not ready to agree on, we
          have something we are ready to agree on which gives us path
          to extend

  Rossen: Proposal: clamp values between 0-100, all other values are
          invalid
  Rossen: Other comments on proposal or objections?

  RESOLVED: Clamp values between 0-100, all other values are invalid

  Rossen: Rest of discussion is important. Recommend we continue to
          have this, by way of examples, in the issue when people have
          time for math

Consider clarifying Highlight system color, and maybe adding a new
    system color for control background
------------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/6008

  emilio: We defined highlight system color as highlights. MacOS has 2
          kinds, one for selection and one for stronger color
  emilio: The question is, webkit exposes it and blink exposes via
          webkit focus ring. Both colors are exposed, one with wk
          prefix. Question is, should highlight be the selection color
          or the other color?
  emilio: Should we define a non-prefix of -wk-focus-ring?

  fantasai: Reason we have system color is so authors can use forced
            colors in a meaningful way. If I recall there's a handful
            of colors in windows UI and took handful of colors in that
            and added a few more that were missing. I don't remember
            what highlight-color was supposer to represent, but should
            clarify for that.
  emilio: On windows only 1 highlight color. Selection color is same
          as selected in styling
  emilio: My point is that UA stylesheets should use system colors
          exclusively for this. Respect dark mode, forced colors works
          correctly. That can be magic
  emilio: Ideally we would have 2 colors and I can remove prefixed
          version. We don't have one exposed in macOS accent color. If
          we say highlight should be selection I need a prefix for the
          other. Ideally we would avoid it. Id rather come up with a
          name for it and spec it
  <chris> It was originally defined on Windows 95 and Java; it was
          already out of date by Windows 98
  <fantasai> chris, the non-deprecated system colors are the set that
             matches Win10 forced colors mode
  <fantasai> chris, that's what we need to align with

  fantasai: First question is do we want to add separate keywords and
            second is what do we call them. Let's do first question
            first
  emilio: Chris mentioned he wouldn't like to expose a system color
          but they're doing it.
  <chrishtr> The comments were not from me. :)
  emilio: Someone mentioned it on the last call
  emilio: I wanted to make sure if there is concern we can address that
  Rossen: I'm unclear if this system color can be backed by actual
          system colors
  emilio: Browsers do different things. FF in some situations nervous
          about fingerprint. Webkit doesn't do highlight, but does the
          others.
  Rossen: System colors make sense across all systems as they exist
          now. This makes sense on some systems, not others
  emilio: I think makes sense in all, but in some systems they're the
          same
  emilio: On windows when you have select multiple color of
          highlighted item is same as selection color. Doesn't have to
          be
  Rossen: Weird to provide system colors from css and not other way.
          System colors up till now were things in all systems and
          drive enough need to expose and uniform enough across
          platforms
  Rossen: This is slightly opposite to me. We want to impose there's 2
          colors and hope in some systems they'll add a different
          color. To me is backwards requirements and we can't expect
          platforms to take that and make the system color.
  Rossen: Certainly not backwards into OSs in use
  emilio: Not sure I agree. You're right windows won't have separate
          color soon or ever. But that doesn't mean having 2 colors
          doesn't make sense. They're conceptually different, even if
          shown in the same color on windows
  Rossen: I think I made my point here. I can't add anything to make
          it clearer. Want to hear from others
  fantasai: Agree with emilio they can map to the same color. Question
            is do we add the value so systems that do distinguish have
            ability to do so
  florian: A little confused by your point. If trying to add colors
           that don't make sense because on some systems you cannot
           currently answer what is the system color because there's
           2. If we add one and it's teal on both you can answer teal
           on both. But if we add a section value it lets the other
           system answer truthfully one is teal and one is blue

  Rossen: Where is this conversation going?
  fantasai: Two options. First define that the highlight color matches
            either text selection or the select box color. Have to
            pick because can be different on some platforms. That
            leaves open do we define a keyword to represent other
  fantasai: For Windows this question doesn't matter. For Mac it does.
            If you ask for highlight, which color are you getting?
  Rossen: Can anyone from apple answer this?
  smfr: Currently it's the selection color. Not opposed to exposing
        value to capture darker blue
  florian: Given it's exposed already aren't you saying you need to
           expose both and you're okay picking one because you have
           both exposed?
  smfr: I didn't follow.
  fantasai: Highlight color represents selected text color. What you'd
            use for ::selection
  smfr: Which is what we do now
  fantasai: Resolve on that, then talk about adding new color?
  smfr: Fine
  Rossen: What's the proposal?
  fantasai: Highlight color represents selected text color which is
            what you'd use for ::selection
  Rossen: Objections?

  RESOLVED: Highlight color represents selected text color which is
            what you'd use for ::selection

  fantasai: Do we want to add a keyword to represent selected item in
            a list-box? That color.
  fantasai: If we don't when you're in forced-color you cannot match
            that color
  Rossen: I'm not sure if silence is...I'll take it as agreement we
          want the keyword
  florian: Given it has a wk name I'd say yes
  Rossen: Is there a name?
  fantasai: Not yet
  Rossen: Proposal: Add keyword with name TBD
  Rossen: Objections?

  RESOLVED: Add keyword to represent selected item with name TBD

  fantasai: No great ideas on name
  Rossen: Bikeshed in the issue

Flexbox & Sizing
================

Interaction of flexbox minimum height and aspect-ratio minimum height
---------------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/6069

  <fantasai> https://github.com/w3c/csswg-drafts/issues/6069#issuecomment-790046695
  <fantasai> https://github.com/w3c/csswg-drafts/issues/6069#issuecomment-797028657
  Rossen: Summary ^
  Rossen: Can you repeat it?
  fantasai: Proposal is a non-replaced element ignores transfered
            sizes for auto min sizing
  fantasai: Auto min sizing in flex and grid where initial value is
            auto. You take size of min-content so you don't shrink
            flex item too much. On images with aspect ratio if you set
            for a row flexbox a height on the image we transfer that
            through aspect-ratio and modifies minimum
  fantasai: Makes sense for images and that's what it was designed
            for. For non-replaced boxes this makes less sense. When we
            thought through we considered don't do this. Make this
            behavior restricted to replaced elements. Don't apply to
            non-replaced elements that have aspect-ratio added by
            aspect-ratio property

  florian: You're left with min prior to aspect-ratio being used?
  iank: min-content or intrinsic
  fantasai: For replaced element natural and min-content size is same.
  fantasai: For replaced if you spec a size on the axis we clamp
            auto-min by that size.
  fantasai: Other than that we transfer that and other content and min
            that.
  fantasai: Non-replaced we don't transfer
  florian: If the transfer aspect-ratio would have made min size
           smaller clearly good to not do. If transfer aspect-ratio
           makes min-size bigger is it not good to honor it?
  fantasai: Trying to remember the logic
  fantasai: This was because on items with an aspect-ratio...consider
            a block with aspect-ratio. min-height: auto. Decided that
            means element with an aspect-ratio will ignore
            aspect-ratio if content is larger than height it would
            have imposed by aspect-ratio. 1:1 aspect-ratio block.
            100px width which gives 100h. 500px content so I have to
            block 500px
  fantasai: When you turn it into a column flexbox we want same. But
            if we transfer size we can't get same behavior because
            made auto-min dictated by aspect-ratio. To have same
            behavior of the content blowing out the aspect-ratio in
            both blocks we can't use same transfer behavior we have
            for replaced
  florian: Makes sense, thank you
  fantasai: More like thanks cbiesinger
  <cbiesinger> you're welcome

  iank: This means a min-content size will ignore transfered min and
        max heights. But min-content contribution will respect them?
  fantasai: min-content contribution will have to take into
            account...[thinks]...something complicated about this but
            I don't remember
  fantasai: I think min-content contribution needs to take it into
            account. I remember complicity on how defined in a
            different issue and I'm not sure if it was relevant there
  cbiesinger: min-content contribution doesn't matter in flexbox?
  cbiesinger: flexbox intrinsic sizes are defined in flexbox spec.
  Rossen: Got it
  iank: I asked about it to make sure it is applied there. grid spec
        does use the min-content contributions directly
  iank: In certain circumstances
  fantasai: yeah
  cbiesinger: I don't think we can use that in content contribution
              because don't know content-height. We would create
              circular
  Rossen: Yes

  Rossen: We're getting to top of hour. Doesn't sound like we're ready
          to resolve on this. Not quite.
  Rossen: Perhaps I would suggest we take it back to the issue and
          answer the questions there and then resolve during the F2F.
          Let's make sure we're not missing any of the points raised
          here
  Rossen: Let's end here

  Rossen: Please add agenda F2F items and add yourself to the wiki
  Rossen: I wish you a great rest of the week and we'll chat more next
          week

Received on Wednesday, 31 March 2021 23:04:51 UTC