[CSSWG] Minutes Telecon 2021-06-16 [css-color-adjust] [css-fonts] [css-contain] [cssom-view] [css-transforms] [css-flexbox] [css-overflow]

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

Color Adjust

  - RESOLVED: Add new keyword to forced-color-adjust as described
              above, apply it in UA default stylesheet for SVG root
              element (Issue #6310: Spec currently breaks use of
              currentColor for SVG icons in WHCM)

CSS Fonts

  - The group generally felt that 'size-adjust' could be shipped soon
      (Issue #6371: Is the 'size-adjust' descriptor stable enough to
      ship?) however they wanted to first get feedback from myles and
      publish the FPWD for Fonts 5. The goal is to have a draft ready
      in about a month.
  - RESOLVED: Switch ic and ch to ic-width/ic-height/ch-width (Issue
              #6288: Clarify/reconsider interaction of new
              font-size-adjust options with writing modes)

CSS Contain

  - RESOLVED: Add style containment back to 'strict' and 'content'
              values of 'contain' (Issue #6287: 'contain: stricter'
              like strict + style)


  - RESOLVED: Incorporate visualViewport into cssom-view and add bokand
              as editor (Issue #6339: Merge visualViewport into working

CSS Transforms

  - RESOLVED: Clamp to 1px for both getComputedStyle() and
              interpolation as well (Issue #6320: clamping of
              perspective() function to >= 1px should affect
              interpolation | Issue #6346: clamping of perspective()
              function should affect resolved value of transform)

CSS Flexbox

  - RESOLVED: Accept edits [in
              (Issue #5985: Clarify whether collapsed flex items
              influence the flex container's intrinsic main size)

CSS Overflow

  - There is some clarification needed for issue #4791 (Scrollable
      Overflow contributions of zero height/width elements) however the
      group ran out of time on the call to go into much detail.


Agenda: https://lists.w3.org/Archives/Public/www-style/2021Jun/0009.html

  Rachel Andrew
  Adam Argyle
  Rossen Atanassov
  Tab Atkins-Bittner
  David Baron
  Christian Biesinger
  Oriol Brufau
  Elika Etemad
  Simon Fraser
  Chris Harrelson
  Daniel Hobert
  Brad Kemper
  Jonathan Kew
  Daniel Libby
  Ting-Yu Lin
  Peter Linss
  Alison Maher
  Fran├žois Remy
  Morgan Reschenberg
  Cassondra Roberts
  Jen Simmons
  Alan Stearns
  Miriam Suzanne
  Greg Whitworth

Scribe: fantasai
Scribe's scribe: fremy

Color Adjust

Spec currently breaks use of currentColor for SVG icons in WHCM
  github: https://github.com/w3c/csswg-drafts/issues/6310#issuecomment-858112357

  fantasai: The current proposal is not gonna get us in good shape in
            all cases
  fantasai: currently our resolution would not work if the svg has set
            its color explicitly
  fantasai: so my new proposal is that if the color is originating from
            outside the svg then we recolor, but if not then we keep it
  fantasai: Proposal is to add a new keyword for that magic behavior
            which depends on the origin of the value of color
  fantasai: (if you are not inheriting from outside, then we don't
            reset the color)

  alisonmaher: I agree with the proposal
  alisonmaher: only problem I wanted to ask about was whether we can do
               at computed value time
  alisonmaher: if we take the used value of the color, might expose the
               color where otherwise wouldn't
  TabAtkins: :visited won't be exposed that way
  TabAtkins: That's done by selector-hacking
  TabAtkins: and the rest of colors are already automatically exposed
             via getComputedStyle
  TabAtkins: because getComputedStyle returns used value of color
  TabAtkins: so not sure there's info leakage problem

  Rossen: While we're on the topic, wrt TAG review
  Rossen: We convinced ourselves that having a grouping of color values
          that we essentially return just defaults for, and lie about
          the computed or used values
  Rossen: colors used for fingerprinting
  Rossen: could be a good path forward
  Rossen: These are magic values, you won't get the actual values
          though getComputedStyle
  Rossen: benefit of user for privacy
  fantasai: That's a separate issue, here
  fantasai: In that issue there are further comments there that says
            why it's probably not possible
  fantasai: but this is not linked to our current issue here
  astearns: If we end up doing anything special for particular sources
            of colors
  astearns: If we add this new mechanism, we'd have to do whatever
            magic here, too
  fantasai: You'd also have to taint Canvas, and a lot of other things,

  astearns: alisonmaher is it enough to note that, whatever protections
            would end up happening here also?
  alisonmaher: We're storing [?] in chrome, so would be possible to do
               at used-value time
  fantasai: The issue is that would have to track this down the tree
  fantasai: and this type of tracking is usually done via inheritance
  fantasai: I don't think implementations have a special inherit for
  alisonmaher: We inherit that info separately in Chromium
  astearns: So what do we resolve to deal with this
  fantasai: We need to add a new value
  fantasai: We need to a new value to forced-color-adjust
  fantasai: as described in
  fantasai: We can call it something else, but need something that
            behaves like that
  astearns: New value, not something to add to default?
  TabAtkins: Yes, absolutely
  TabAtkins: and needs to be set in default UA stylesheet for SVG root
  astearns: Exposed to author styles?
  TabAtkins: Yes; don't want it to be special unspecifiable magic
  astearns: So proposed resolution is to add this keyword
  astearns: and to add that to the default UA stylesheet

  RESOLVED: Add new keyword to forced-color-adjust as described above,
            apply it in UA default stylesheet for SVG root element

  fantasai: Other than this issue
  <fantasai> https://github.com/w3c/csswg-drafts/labels/css-color-adjust-1
  fantasai: we have no other remaining issue for the spec
  fantasai: so our plan is to make the edit
  fantasai: publish a new draft
  fantasai: and ask for last comments before trying to propose to make
            a recommendation
  fantasai: So, heads up
  astearns: And get wide review?
  fantasai: We already have sent an email in December
  <fantasai> https://github.com/w3c/csswg-drafts/issues/5768
  astearns: Sounds like a good plan

CSS Sizing

Compressible elements with aspect ratio
  github: https://github.com/w3c/csswg-drafts/issues/6341

  iank: Added table kinda late, can punt to next week if we want

CSS Transforms

Clamping of perspective() function to >= 1px should affect interpolation
  github: https://github.com/w3c/csswg-drafts/issues/6320

  astearns: is dbaron on the call?
  fantasai: we can skip for a later time

CSS Fonts 5

Is the 'size-adjust' descriptor stable enough to ship?
  github: https://github.com/w3c/csswg-drafts/issues/6371

  jfkthame: We've implemented size-adjust descriptor in Firefox
            Nightly, and want to know if stable enough if we can ship
            to release
  jfkthame: My understanding is that Chrome is also wanting to ship soon
  <chrishtr> agree it's good to ship
  fantasai: I think the descriptor is pretty stable
  fantasai: The way it is defined is standard and I don't anticipate
  fantasai: so I think it's probably fine to ship
  fantasai: but we need to publish a First Public working draft first
  fantasai: This could happen very soon

  astearns: Any other concerns?
  smfr: Let's ask Myles, he's not here today
  astearns: Sounds good, also we still need an FPWD
  <fantasai> https://www.w3.org/TR/css-fonts-5/
  <fantasai> 404 ^
  astearns: It's most important to publish FPWD, but even for a regular
            WD would like to publish before group says "you can ship" :)
  astearns: So let's get edits in and get Myles' comments
  astearns: but generally seems like it'll be OK
  jfkthame: Would help to know schedule.
  fantasai: we can get a draft within a month

CSS Contain

'contain: stricter' like strict + style
  github: https://github.com/w3c/csswg-drafts/issues/6287

  TabAtkins: Some time ago we removed 'style' from set of containments
             applied by 'strict'
  TabAtkins: Since at-risk, unsure if FF would implement
  TabAtkins: no longer at-risk
  TabAtkins: Question is should we have a keyword that applies 'strict'?
  TabAtkins: If so, should we add a new keyword or build it back into
  TabAtkins: chrishtr commented that he thinks it'd be fine to add into
             existing 'strict', and willing to do experimentation in
  fremy: I agree, makes sense to me
  <dholbert> Sounds fine by me
  oriol: Wouldn't just be strict, but also ...
  oriol: content
  TabAtkins: content used to be 'strict' without 'size', so add to that
             as well
  fantasai: sgtm
  astearns: So proposed resolution is to add back in style containment
            to 'strict' and 'content' values of 'contain'
  astearns: Any objections?

  RESOLVED: Add style containment back to 'strict' and 'content' values
            of 'contain'

  <chrishtr> I will get this change made in Chromium asap so we can get
             canary channel feedback. Will report back if there are any


Merge visualViewport into working group
  github: https://github.com/w3c/csswg-drafts/issues/6339
  <TabAtkins> https://wicg.github.io/visual-viewport/index.html

  TabAtkins: visualViewport spec that allows getting bounds of visual
             viewport in JS
  TabAtkins: has been implemented cross-browser for awhile
  TabAtkins: probably should be on standards-track
  TabAtkins: suggestion is to put into cssom-view
  <fremy> LGTM

  fantasai: Who is gonna be editor?
  TabAtkins: bokand is editor of visual viewport spec... and is a
             member of CSSWG
  TabAtkins: Could just add him
  smfr: Emilio and I are editors of CSSOM-view, and would appreciate
        editorial help
  fantasai: Sounds like a good idea to have one more person on this
  TabAtkins: chrishtr, can we volunteer bokand?
  chrishtr: We can try, and if he's busy, we'll find someone else on
            our staff
  astearns: So propose to incorporate visualViewport into cssom-view
            and add bokand as editor

  RESOLVED: Incorporate visualViewport into cssom-view and add bokand
            as editor

  fantasai: One more comment
  fantasai: It's a bit weird how things happened here
  fantasai: We are not doing standardization, we are doing documentation
  fantasai: I don't find this workflow appropriate
  fantasai: So I agree to do it here, but it's worth noting I think it
            is not a good workflow
  fantasai: It's too late to make any changes now, so it's not exactly
            accurate to say you're shifting it to the CSSWG for the
            "standardization" process
  astearns: I agree
  astearns: That said, it happens, and we can't change it
  astearns: and documentation is still good
  TabAtkins: Also, it shipped in multiple browsers
  TabAtkins: Discussion happened, in another venue
  TabAtkins: but patent protection was not part of this, and this is
             not ideal
  <TabAtkins> Like, look at the issues list, showing definite
              cross-browser discussion


Clamping of perspective() function to >= 1px should affect
    interpolation and clamping of perspective() function should
    affect resolved value of transform
  github: https://github.com/w3c/csswg-drafts/issues/6320 &

  dbaron: Discussing 6320 and 6346 together
  dbaron: Group resolved that values less than 1px should be clamped to
          minimum of 1px
  dbaron: At the time, discussed as a render-time clamp
  dbaron: I tried implementing this. Believe I was the first
  dbaron: In the process, became clear that the time at which it became
          clamped was the time you convert to a matrix
  dbaron: Problem with zero is that it puts infinite components into
          the matrix
  dbaron: There are 3 different ways convert to a matrix
  dbaron: 1) need to render, to find used value
  dbaron: 2) find resolved value for getComputedStyle()
  dbaron: computed value of transform function is "as specified with
          lengths made absolute"
  dbaron: but resolved value is a matrix
  dbaron: The third one, which is maybe more interesting, is
  dbaron: Perspective function gets interpreted as matrices
  dbaron: if you were to not clamp, and then interpolate from 0 to 2px,
  dbaron: entire range of animation would be clamped to 1px during
          render time, because animating from infinity to 0.5
  dbaron: which crosses 1 basically right when it gets to 0.5
  dbaron: Conclusion was do the clamp anytime I convert to matrices
  dbaron: so for getComputedStyle and for interpolation also
  dbaron: I've already implemented this in Canary ... does anyone think
          we should do something different?
  dbaron: Not clear to me what that could be

  smfr: Seems fine. What happens when perspective property or transform
        with only perspective, not converting matrices, do we need to
        describe behavior there?
  dbaron: For perspective property, group explicitly resolved in 3084
          that the animation should be different
  dbaron: so perspective property should interpret as specified
  dbaron: 2nd point, spec says that even a perspective() on its own
          gets interpolated as matrix
  dbaron: it describes the rules for interpolating matrix and
          perspective as the same thing
  dbaron: so decompose and do the pieces
  dbaron: for perspective it's trivial
  dbaron: but still the decomposition that gets interpolated is the
          matrix component, so ?? reciprocal
  smfr: So that part is affected by your proposal
  dbaron: Yes
  smfr: I think it's reasonable
  smfr: As long as we agree on where conversions to matrices happen
  dbaron: Issues I filed are in terms of this should happen for
          interpolation and this should happen or getComputedStyle
  dbaron: but rational was "wherever convert to matrix"
  smfr: Sounds fine

  astearns: So original resolution for 413, did that cover resolved
  dbaron: No, said "for purpose of rendering"
  astearns: So have a resolution for rendering, and you're saying
            extend to interpolation and resolved value
  astearns: Any other opinions?
  astearns: ... implementation detail?
  dbaron: When editing spec, I'll see if it makes sense to fit that
          note in
  [scribe missed, but guesses note was about the "convert to matrix"

  RESOLVED: Clamp to 1px for both getComputedStyle() and interpolation
            as well

  dbaron: Possible not web-compatible, but can figure that out when we
          have data

CSS Fonts

Clarify/reconsider interaction of new font-size-adjust options with
    writing modes
  github: https://github.com/w3c/csswg-drafts/issues/6288

  jfkthame: Was working on implementing in Gecko, and it occurred to me
            that the behavior that falls out for the new ch and ic
            units probably isn't what we really want
  jfkthame: If you set font-size-adjust: ch 0.4, for example, and then
            use vertical writing mode with upright typesetting
  jfkthame: you'd get completely different scaling
  jfkthame: Seems that would be unexpected and undesirable
  jfkthame: Expectation would be that font + font-size-adjust should
            give consistent results
  jfkthame: So my suggestion is that it applies in the horizontal axis
  jfkthame: so not quite the same as the units
  jfkthame: so maybe need to rename to make more explicit what they are

  astearns: I think I'd like ch-width name
  astearns: Very explicit
  jfkthame: We'd have the option of introducing a ch-height for
            vertical mode, but usage expected to be quite different

  fantasai: That would be more difficult than helpful
  fantasai: The vast majority of the authors won't need that second
  fantasai: I would be ok with it if it is optional
  fantasai: and sets to no effect
  astearns: I think that was the proposal
  fantasai: Currently if you wanted to have an effect in the vertical
            axis, we have a syntax for two values
  fantasai: The disadvantage of that is that you might want different
            values for the different axes
  fantasai: but given few people would want to use two values
  fantasai: Maybe we should just have one value and be clear about what
            it means
  fantasai: and when would you know which one you want, if both are
  astearns: Were we going to have ic-height and ic-width that can set
            at the same time?
  jfkthame: No, just one at a time
  astearns: So proposed resolution is to replace ic and ch with
            ic-width ic-height and ch-width
  astearns: to lock things to the appropriate axis and make that
  fantasai: The one thing we might consider is adding 'ic' and having
            it compute to 'ic-width' or 'ic-height' as appropriate to
            the writing mode and then inherit as that computed value
  fantasai: Worth consideration, but I haven't thought about it much
  astearns: But whatever value you add to that ic would be based on one
            or other metric, so unlikely to have single value that
            works for both
  fantasai: unless you're using 1em, in which case no effect except for
            non-square fonts anyway...
  jfkthame: [...]
  jfkthame: Could look into it, but doesn't seem worth the complexity

  RESOLVED: Switch ic and ch to ic-width/ic-height/ch-width


Clarify whether collapsed flex items influence the flex container's
    intrinsic main size
  github: https://github.com/w3c/csswg-drafts/issues/5985

  TabAtkins: Just got approval from dholbert so probably easy
  TabAtkins: dholbert noticed that collapsed flex items aren't
             explicitly excluded from intrinsic size calculation
  TabAtkins: so we updated to explicitly skip those items
  <fantasai> commits are
  TabAtkins: We made the fix, just wanted WG confirmation it's OK
  <cbiesinger> I haven't read the text but your description sounds good
  astearns: Proposal to accept?

  RESOLVED: Accept edits

CSS Overflow

Scrollable Overflow contributions of zero height/width elements
  github: https://github.com/w3c/csswg-drafts/issues/4791

  fantasai: Seem to have weird but interoperable behavior here,
            question was should we spec it
  iank: Not so weird, we compute the "inflow" bounds
  iank: ...
  iank: If you add a transform to the item and move it outside the
        scrollable area
  iank: all browsers transform out
  iank: If something is zero area, it doesn't itself contribute, but it
        might contribute to "inflow bounds"
  fantasai: ???
  iank: If you have something like a grid area, that's where we
        determine where to put the "padding" to contribute to overflow
  iank: Here it's the body element contributing to the scrollable area
  fantasai: OK, so need to set body to zero to test correctly and issue
            is invalid?
  iank: Question of adding to overflow is just if it's empty
  fantasai: Actually, there is an issue, but it's just that if the
            border area is empty, we need to exclude from the
            scrollable area
  iank: Yea, but also this other thing

Received on Wednesday, 16 June 2021 23:02:12 UTC