[CSSWG] Minutes Telecon 2020-01-15 [mediaqueries] [css-pseudo-4] [css-sizing] [cssom] [css-text-decor] [css-ui]

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

F2F Agenda

  - Any items for the F2F agenda need to be added soon so that people
      can review and come prepared.
      - The Summer F2F timing will be added to the agenda.

Media Queries

  - RESOLVED: Remove hyphen from rec2020/rec-2020 in all contexts;
              everything else (P3/display-P3) stays as is (Issue
              #4535: color-gamut Keywords)

CSS Pseudo Elements

  - RESOLVED: Whatever highlight being applied uses colors from before
              even if came from pseudo element like
              ::first-letter/::first-line (Issue #4625: Original color
              of highlight pseudo inside ::first-letter/::first-line)
  - Adding an inactive-selection media query wouldn't solve the
      original use case for ::inactive-selection/::active-selection
      (Issue #4579), though there may still be use cases for the media
      query. fantasai will revisit having a selector on the element as
      well as the other proposals within github to see what works
      better for the use cases.

CSS Sizing

  - The group was leaning toward adding a contain-intrinsic-size
      property to address issue #4531 (intrinsic-size lost the
      thread), but wasn't quite ready to resolve. TabAtkins will write
      up proposed spec text and dbaron will add some past examples to
      the issue.
      - This will be added to the F2F agenda for resolution.
  - RESOLVED: Specify Firefox's behavior [Give max-content
              contribution of replaced only-aspect-ratio elements ICB
              width and then ratio height] (Issue #4218: max-content
              contribution of replaced only-ar elements might be


  - The group agreed that on Issue #4444 (Table row resolved width and
      height) there needed to have round trip for block axis. Once
      there is spec text the group will review and resolve.

CSS Text Decor

  - RESOLVED: Add an 'always' value to 'text-decoration-skip-ink'
              (Issue #4277: Consider adding an `all` value to


  - For issue #3728 (Should mention the possibility to ignore custom
      cursors that go outside of the viewport) Firefox has been
      invalidating images that are too large for a custom cursor.
      Chrome will add its approach to the issue so the group can
      decide if the spec should change.


Agenda: https://lists.w3.org/Archives/Public/www-style/2020Jan/0004.html

  Rachel Andrew
  Rossen Atanassov
  Tab Atkins
  David Baron
  Christian Biesinger
  Oriol Brufau
  Tantek Çelik
  Emilio Cobos Álvarez
  Dave Cramer
  Elika Etemad
  Simon Fraser
  Chris Harrelson
  Dael Jackson
  Brian Kardell
  Brad Kemper
  Chris Lilley
  Myles Maxfield
  Anton Prowse
  Manuel Rego Casasnovas
  Florian Rivoal
  Devin Rousso
  Jen Simmons

  Ravikiran Ramachandra
  François Remy
  Christopher Schmitt
  Lea Verou

Scribe: dael

F2F Agenda

  astearns: Does anybody have any changes for the agenda? There's one
            we'll postpone that's far down on the list
  astearns: Anything other than that?
  fantasai: Scheduling? rachelandrew has been asking us for a lot of
            months to lock down summer dates
  astearns: I don't think we can get to it on the call. We're waiting
            on Google people to confirm dates. Let's make sure we get
            to it at F2F next week

  astearns: F2F is next week, we could use more agenda items. Please
            add them as soon as you can so people can be prepared at
            the meeting

Media Queries

color-gamut Keywords
  github: https://github.com/w3c/csswg-drafts/issues/4535

  astearns: chris you commented last
  chris: I'm of the opinion this is shipped in 2 browsers so large
         change cost. If we designed now more generic names would be
         better but fact is Apple and others have shipped P3-gamut.
  chris: We discussed hyphenation and got consensus on that and I
         don't want to rename them back. We went to display-P3 and
         then we'd have to rename and it would become ambiguous again.
         TabAtkins has a different opinion that they mean the same
         thing. I don't think they do mean the same
  TabAtkins: I said they are approximately the same. They're close to
             meaning same. Especially in rec2020 where one has a
             hyphen and one does not is extremely bad. p3 and
             display-p3 are different words.
  TabAtkins: Still of opinion we should be consistent. We shouldn't
             change color gamut so we should revert color function
             keywords because else wise people will ask why are they
  florian: I would argue they mean the same. If you understand MQ to
           ask if gamut is supported by screen with this approximately
           as large as this color space then it's yes. If screen isn't
           an exact match it's okay. You're not asking about color
           space specifically

  chris: No one suggests re-naming display-P3 to P3?
  TabAtkins: I'm possibly in that realm. I would like rec2020 to be
             consistently hyphen-less. P3 and display-P3 sound
             different. Hyphen difference shouldn't be
  florian: I would align P3 to the one used in MQ.
  chris: Remember Apple wanted display-P3. When we reverted to what
         they wanted and what everyone talks about that's the name
  TabAtkins: That's why I'm okay with display-P3. A subset of name in
             color gamut is okay. P3 means approximately any of these.
  florian: I don't think I would object to different P3. But your
           question was anyone suggesting we merge and I suggest we
           do. Won't object to don't
  TabAtkins: Revert rec2020 in color to be hyphen-less and leave
             p3/display-p3 alone?
  chris: Okay with that....
  <fantasai> I would strongly object to having the only difference be
             the presence of hyphens
  florian: Maybe hear from Apple?
  smfr: Apple prefer to keep
  astearns: Proposal: Remove Hyphen from rec2020?
  astearns: Objections?

  RESOLVED: Remove hyphen from rec2020 in all context; everything else
            stays as is

CSS Pseudo Elements

Original color of highlight pseudo inside ::first-letter/::first-line
  github: https://github.com/w3c/csswg-drafts/issues/4625

  fantasai: Currently specified if author specifies background color
            and no color we use color of originating element
  fantasai: With ::first-letter/::first-line it will cause it to
            change color because look at paragraph. Would be weird for
            spelling or grammar error.
  fantasai: Do we make it look up ::first-letter/::first-line color or
            is that difficult?
  TabAtkins: While I'm inclined to think it's complicated but heycam
             thought it was fine so sure. I think it's reasonable
  astearns: Other impl feedback?
  astearns: Prop?
  fantasai: Use the color of the text prior to applying the highlight
  fantasai: Whatever highlight being applied uses colors from before
            even if came from pseudo element like
  astearns: Any other pseudo elements effected?
  fantasai: Not sure, possible ::before or ::after
  fantasai: Point is make it clear if there's a pseudo element
            changing the color we use that color not the document
  astearns: Objections?

  RESOLVED: Whatever highlight being applied uses colors from before
            even if came from pseudo element like

  fantasai: One note is currentColor keyword we'll have to make it
            resolve to a value for purpose of gCS. Will need to
            represent multiple colors
  florian: Why?
  fantasai: If you have a selection...we attach selections to an
            element not ::first-letter/::first-line. Could change the
  florian: I see
  fantasai: That's going to be interesting
  florian: Yeah. For ::before/::after it's not a problem, but weird
           for ::first-letter/::first-line
  fantasai: I'll try and spec it out. It will be complicated

  tantek: Impact on implementations with change?
  fantasai: No one implements this right now. Would all have to change
  chrishtr: Backwards compat?
  fantasai: No one does this. It's difficult to implement I think.
            That's why I raised it
  chrishtr: Good to have things not difficult to implement
  fantasai: But good to have good behavior too. I can spec it
  TabAtkins: I had same feeling as you but heycam thought it most
             reasonable to do. Since he doesn't think impl overrides
             correct behavior I decided to trust him
  smfr: Is the resolution to accept heycam proposal?
  TabAtkins: Accept fantasai proposal
  astearns: heycam was agreeing this is right behavior to spec. We'll
            try and spec and get implementation experience to say if
            it's reasonable. We can back out if too complicated to
  tantek: I was reviewing GH and saw fantasai question what to do. I
          didn't see the proposal.
  fantasai: I need to write a proposal. Not worth it if no one wants
            to do it.
  tantek: Looks like heycam had a proposal.
  fantasai: There's two possibilities at a high level and heycam said
            this one.
  tantek: That's what we resolved on?
  fantasai: Yes

  myles: Why is it hard to implement?
  fantasai: Highlight is attached to element in doc not ::firstline.
            So you can have a highlight span and have to look up
            different colors depending on if you're first line even if
            same element. You have to paint with different colors and
            have currentColor with presumably multiple colors.
  fantasai: I don't know how machinery will work; per-element
            ::selection needs substantial changes to make it work.
            We'll have to see what happens and how implementations
            shake out
  myles: My intuition is this wouldn't be difficult to implement. In
         MacOS we draw highlight per element so it's just an if for
         us. iOS is different. I don't think would be hard
  fantasai: Okay
  florian: Clarification we resolved on high level principle and
           fantasai you're going to worry about how to do currentColor
  fantasai: Yep
  astearns: Next step if fantasai spec this out. Anyone with enough
            concern that it's a waste of time for her to work on this?
  astearns: Then we'll let resolution stand

::selection vs ::inactive-selection
  github: https://github.com/w3c/csswg-drafts/issues/4579

  fantasai: Started discussing last week, came up with...discussion
            was why not have a MQ instead of two pseudos. Then we ran
            out of time.
  fantasai: Do we want to go in that direction and drop
            ::inactive-selection from spec and add a MQ to MQ5?
  astearns: Use case for inactive MQ outside of selection?
  fantasai: Probably. There's some JS methods that allow you to detect
  <fantasai> https://github.com/w3c/csswg-drafts/issues/4579#issuecomment-572188785
  astearns: Main difference is instead of having to fully spec both
            styling you can do all your selection styling and have an
            inactive override which might reduce duplication
  fantasai: We have to do that anyway because selection is when window
            is inactive. Whatever way we take it needs to apply. 3
            ways to do it, 2 are in the issue and 3rd is do in a MQ
            where you can do inactive anything

  AmeliaBR: Selection styles always apply active or not is what we
            have. Doesn't match browser styles. I like MQ idea and
            have benefit of being able to do things like pause
            animations and transitions which is more consistent with
            request animation frame transitions
  smfr: Need to be a little careful with window activation. An iframe
        without focus is inactive color. It's focus state of document
  smfr: Wondering case about inactive selection with the same document
        as active selection. There may be scenarios like that
  AmeliaBR: Interesting. Then inconsistent with page visibility APIs
            concept of active/inactive. Useful to have specific
            examples of which browsers and OS conventions do have
            those distinguishments between this selection is preserved
            but not currently active and the cases where that can
  astearns: I'd want to make sure the MQ had as much of same behavior
            as page visibility API. Doesn't seem like should be a
            difference if we can manage it
  fantasai: Then it's not same as ::inactive-selection. When you have
            ::inactive-selection and ::active-selection in the same
            page we need the pseudo.

  fantasai: Other idea taken up during previous call was a selector on
            the element that says hey this element is focused so make
            selection this color. Some word that represents being
            selectable in an active way. Don't know if it would work
  AmeliaBR: That would cover case of text area preserving selection
            even when text area doesn't have focus. A pseudo class on
            text area and then selection style with regular selection
  fantasai: Yeah, I think so. but then...I don't know...need to think
            about cascading
  fantasai: That's good points, we should move to another issue. We
            won't solve now.
  astearns: I'm still interested to see if an inactive MQ would be
            useful, but may be out of scope for this problem
  astearns: Let's continue in GH and maybe on agenda for next week

CSS Sizing

intrinsic-size lost the thread
  github: https://github.com/w3c/csswg-drafts/issues/4531

  myles: Can we rename the github issue to something that makes more
  TabAtkins: If you can think of something, sure.

  TabAtkins: Last month we talked about this and asked for any
             additional use cases beyond the major one that caused
             this issue and the minor cases we came up with after.
             Since then no one has commented.
  TabAtkins: Suggests it's not important enough to think about over
             holiday at least
  TabAtkins: Given there's no additional suggestions our current
             proposal is revert back to a property with a default size
             for a contain:size element. Proposed name is
             content-placeholder-size. Happy to bikeshed. Makes it
             clear that it's a special case.
  TabAtkins: Objections or additional ideas on use cases with expanded
             form of content size please say so.
  <dbaron> (it wasn't minuted, but I did say above that I wasn't aware
           of https://github.com/w3c/csswg-drafts/issues/4585 until it
           was mentioned today)

  fantasai: I think if specific to contain it should be prefixed with
  TabAtkins: contain-placeholder is fine
  myles: Placeholder a term of art for inputs?
  fantasai: It's used for placeholder in inputs. I'm hesitant to use
            the word
  TabAtkins: Where is placeholder in css?
  <fantasai> ::placeholder and :placeholder-shown
  dbaron: pseudo element and pseudo class
  TabAtkins: Yeah, forgot about that one
  fantasai: contain-size unless you've got a good word in the middle
  astearns: contain-initial-size
  TabAtkins: initial or default seems reasonable
  fantasai: If it's a flex item stretched it won't size to that size.
            contain-content-size maybe. Initial may not make sense
  fantasai: I would prefer a word that clarifies in the middle
  TabAtkins: contain-size sure

  astearns: Issues with contain-size?
  astearns: Proposal: Change the current contain:size to contain-size
            as its own property
  chrishtr: It's a parameter to contain:size
  <rego> "contain: size" and "contain-size"
  chrishtr: contain-size is a parameter to contain:size that indicates
  cbiesinger: Rename intrinsic-size to contain-size
  chrishtr: If contain:size is on an element we look to see if
            contain-size is set and then set placeholder sizing
  TabAtkins: Contain-size is none or lengths
  fantasai: contain-intrinsic-size?
  astearns: Proposal: Add contain-intrinsic-size property with an
            initial value of 0 that takes a pair of length
  cbiesinger: Rename intrinsic-size to contain-intrinsic-size
  chrishtr: And conditioned on contain:size being present
  astearns: Proposal: Have a contain-intrinsic-size property

  dbaron: I missed the request for examples. I'd like to try and do
          that next week and get examples in the past
  fantasai: Let's say if we do in this direction we'll do this and
            waiting on dbaron examples

  florian: We mentioned initial value. For contain-size it's 0 for
           non-replaces which isn't always 0. Does initial value = 0
           and adds size or is it auto?
  TabAtkins: Initial value of none. If you specify a size it'll
  florian: Initial size of 0 it replaces?
  TabAtkins: Yeah
  astearns: TabAtkins can you commit to speccing this out so we can
            have all the details and dbaron examples and see if it
  TabAtkins: Yes
  fantasai: TabAtkins maybe spec both and we'll delete the one we
            don't select
  astearns: Let's get proposal and examples together and we'll look
            next week

max-content contribution of replaced only-ar elements might be
  github: https://github.com/w3c/csswg-drafts/issues/4218

  fantasai: We triaged this last week. Case is we have some box which
            says I want width max-content
  fantasai: Something inside it intrinsically sized with an aspect
            ratio and no size info
  fantasai: No interop. Chrome is 0x0 as max content. Spec says use
            300px width and ratio for height. Resolvable but
            arbitrary. Firefox uses initial containing block. That
            seems useful. We suggest spec Firefox behavior.
  astearns: Concerns?
  astearns: Objections to Specify Firefox's behavior?

  RESOLVED: Specify Firefox's behavior


Table row resolved width and height
  github: https://github.com/w3c/csswg-drafts/issues/4444

  emilio: Height doesn't apply to table rows depending on writing
          modes. There was interop issue found by jquery folks. A
          bunch of discussion on the issue.
  emilio: Various options. Nice to get an agreement.
  emilio: Webkit and Chrome behavior doesn't roundtrip. I propose to
          return computed value which is what we do for other elements
          that don't support height. People argued against that
  TabAtkins: I'll proxy Alex and say Firefox is correct and roundtrip
             should work. Let's roll.
  astearns: Reading thread. What needs to be done to roundtrip height?
  emilio: Using the computed value works. FF does give a resolved
          value it just roundtrips so not what I proposed.
  emilio: Edge used to report auto
  emilio: And the computed value
  emilio: Computed value of auto Firefox gets a roundtrip height and
          Blink doesn't make sense. Edge returned computed value which
          is consistent with inlines

  astearns: Proposal: Return the computed value of height for table
  emilio: When it doesn't apply which is not always. Depends on
          writing mode
  emilio: I think that makes most sense. Alex argued for Firefox
          behavior. There are other comments from fremy and oriol
          saying computed value may not be most useful
  emilio: A bunch of use cases for this

  fantasai: Seems there are two discussions. One is which property
            applies and therefore has meaningful value. And which is
            in height axis of table. Then should property of block
            axis return auto or used value.
  fantasai: Mapping question should be switching based on writing mode
            of table. In terms of if we return used value or auto I
            don't have option other than it should round trip
  fantasai: Means block axis on row needs to return. Can't default to
            auto. Inline axis doesn't matter
  emilio: Used to have stronger opinion but I'm happy to keep
          discussing and figure out best compromise. If people don't
          have strong opinion
  astearns: Leave that intent is to have round trip for block axis and
            leave it at that until we have actual text?
  emilio: Fair.
  astearns: Concerns with having round trip value for block axis of
            table rows?
  astearns: Let's work in issue.

CSS Text Decor

Consider adding an `all` value to `text-decoration-skip-ink`
  github: https://github.com/w3c/csswg-drafts/issues/4277

  myles: Right now when you turn on text-decoration-skip-ink you can
         use auto which is skip everything except cjk. cjk letters
         usually lower on line and intersect too much with underline.
         That was a decision I made many years ago; looked at cjk and
         it was awful so made it not apply
  myles: Other value was none which is don't skip.
  myles: Now that there's a property to move underline it's reasonable
         for an author to want to place underline such that it doesn't
         intersect. Then having ink-skipping on cjk makes sense. Let's
         add a 3rd value that does it on everything, even cjk. Makes
         total sense to me
  <fantasai> I agree with doing this, would suggest using always
             rather than all
  jensimmons: Makes sense to me to give authors rest of power to do
              what they want. They should have option to force it on
              even if default for script is off
  florian: Makes sense to me
  astearns: fantasai prefers always instead of all? Any other opinion?

  astearns: Proposal: Add an always value to text-decoration-skip-ink
  astearns: Objections?

  RESOLVED: Add an 'always' value to 'text-decoration-skip-ink'


Should mention the possibility to ignore custom cursors that go
    outside of the viewport
  github: https://github.com/w3c/csswg-drafts/issues/3728

  florian: Can specify an image as cursor. If image is too large
           browsers expected to shrink
  florian: Recently Chrome and FF figured out security concern and
           they wanted to reject instead of shrink. I know they've
           tried things, reject or crop. I believe what they do is not
           what spec says. Maybe need to change spec to allow. Maybe
           experiment points to a right thing.
  florian: I would like people experimenting to report their findings
           after doing it for a few months
  emilio: In FF we fallback to next image or to default. We treat as
          invalid. You can't shrink b/c you can set a hotpoint and
          then need to shrink that too. I think Chrome did the same
  emilio: I could be wrong on Chrome
  astearns: Anyone know who looked at this on Chrome?
  chrishtr: Need to follow up
  florian: I'd appreciate follow up.
  astearns: Let's see if we can get information on Chrome and continue
            discussion then

  astearns: I'm told it's florian birthday so happy birthday
  <rego> happy birthday florian 🎉
  everyone: happy birthday
  <florian> thank you all!
  astearns: Safe travels everyone, talk to you then

Received on Thursday, 16 January 2020 00:33:25 UTC