[CSSWG] Minutes Telecon 2021-05-19 [css-typed-om] [css-images] [css-color-adjust] [css-contain]

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


  - Issue #1039 (CSSColorValue section needs WG review) brought to
      light many different concerns which need to be split into
      separate github issues and discussed. The biggest topic raised
      which will need further discussion is the scope of CSSColorValue
      and if it should be a generic color manipulation object. Since
      there are several items in front of TAG which relate to this
      question, it will need some prioritization for discussion once
      the issue is created.

CSS Images

  - There was no strong opinion of which behavior to use on Issue
      #6286 (Behaviour of SVG degenerate aspect-ratios) so the group
      will wait to hear back from AmeliaBR before deciding.

CSS Color Adjust

  - There is enough need  currently to include the only value in the
      first level of CSS Color Adjust (Issue #5089 (Re-add only to
      mean "don't auto-adjust me", per WebKit's behavior)). smfr
      provided a link that describes the current WebKit behavior in
      order to guide the creation of spec text.
  - RESOLVED: Add print-color-adjust as an alias for color-adjust and
              have the generic color-adjust be deprecated (Issue
              #3880: Combine forced-color-adjust and color-adjust
              properties somehow?)

CSS Contain

  - RESOLVED: Specify this in CSS Contain (Issue #5913: :root/body
              viewport propagation and containment)
  - RESOLVED: If the used value of contain is other than the default
              we break propagation (Issue #5913)


Agenda: https://lists.w3.org/Archives/Public/www-style/2021May/0005.html

  Rachel Andrew
  Adam Argyle
  Tab Atkins-Bittner
  David Baron
  Christian Biesinger
  Elika Etemad
  Simon Fraser
  Chris Harrelson
  Daniel Holbert
  Brad Kemper
  Jonathan Kew
  Ian Kilpatrick
  Dael Jackson
  Rune Lillesveen
  Chris Lilley
  Peter Linss
  Alison Maher
  Florian Rivoal
  Cassondra Roberts
  Alan Stearns
  Miriam Suzanne
  Lea Verou

Scribe: dael


CSSColorValue section needs WG review
  github: https://github.com/w3c/css-houdini-drafts/issues/1039

  leaverou: This was committed in December 2020 as editorial. Has
            stayed in spec and adds a new API. We thought needs wider
            review. Especially because referenced by other groups and
            proposed as accepting inputs for color
  leaverou: Back in December when this was posted without spec text it
            was an API for CSS syntax. At time had concerns but
            assured it was not a color object. Chris and I have been
            working on color object since July.
  leaverou: Now saying it should be used as a color object. After
            review seems unsuitable. Need to review if first we want
            this as API for CSS syntax and second what is the scope of
            the API; syntax or generic color manipulation
  leaverou: For second one I have more strong opinions and arguments.
  leaverou: Posted some thoughts in issue. Side discussion with plinss
            and chris which is fairly long and misleading title. It
            evolved into what should this API do
  <chris> Lea's comment:
  leaverou: Using this as a color API for the web I would object. Not
            focusing on missing functionality, though there are
            issues. They can be fixed. Not sure a typedOM should be
            used. Example, color object should allow adding color
            spaces by adding color code
  leaverou: CSS color needs to use numeric objects, not numbers, which
            makes API clumsy. As input accepts numbers but get output
            you have to use .value and convert angles
  leaverou: Worse, not always concrete. Could be a CSS math value
            which is calculations
  leaverou: Unclear to me when writing code snippit how I would do a
            simple color manipulation like lightness if you get back a
            CSS math value. What happens when you can't resolve into a
  leaverou: If we use this object as general color object this
            complexity needs to be accounted for in author code
  leaverou: And because it's CSS format it needs complex. CSS rgb or
            CSS color object have different shapes. In order to read
            the color you use different methods. Author code needs to
  leaverou: Even as an API it's awkward and that can't change as
            typedOM object. It's trying to have an API do 2 things

  TabAtkins: First thing, would love wider review. Review from
             leaverou and chris has lead to nice changes. More eyes is
             always great
  TabAtkins: For the rest, I think this was too much of an info dump
             to be done as a late agenda+ or a single issue on the
             call. I would love to do this as a structured F2F where
             people can review. I think people tuned out with the list
             and I want to handle individually
  astearns: It is a lot of information. Are you interested in arguing
            for this should be a general color object?
  TabAtkins: Certainly
  astearns: We could have had a quick resolution if generally agreed,
            but yes would need point by point

  chris: Agree with leaverou about webGPU and type things where this
         type of CSS internals don't want this approach. I don't think
         they realized an object can be complicated and how many of
         the details they don't care about as an input. Especially
         when extended to be an output
  chris: Also feel somewhat mislead because lot of discussions about
         what this is and consensus was this is not a color object and
         we should hold back. But then TabAtkins has been promoting
         this as the color object for the web and even if another was
         needed it would be complex and no one would implement. Being
         told to sit back and wait because we're not designing it and
         then whoops it is what we're designing doesn't feel like how
         it should be designed
  chris: I have a lot of specific concerns about things like color
         gamut handling which I guess is under general review
  TabAtkins: I dispute that I have been disingenuous.
  astearns: I would like us to center on technical issues and not on
            personal issues
  chris: You're right astearns
  astearns: Let's just talk about the API itself
  <fantasai> I think it's fair to say that it's inappropriate to
             commit an entire API under an editorial commit message
             and then pretend it was always in the spec without asking
             the CSSWG for review, though...

  leaverou: When it comes to using CSS color values as input to other
            APIs there doesn't need to be mention in spec. If they
            stringify they can accept color objects. This isn't about
            accepting as inputs, but about other uses
  astearns: I appreciate you brought it to the agenda to get more
            eyes. I do agree this is a little much for a single issue.
            I'd like to see a lot of this broken out into particular
            issues that we can discuss separately and not re-work the
            whole deal
  astearns: I would appreciate concerns with use on canvas APIs to
            bring it up in those venues

  fantasai: If we have major concerns with API it should be marked in
            the draft so it's clear to anyone reading the intended
            scope and if there are major issues. Maybe if Chris and
            Lea and TabAtkins can work out a summary of the major
            points of concern or confusion it would help people
            reading understand what's in contention
  chris: You're right there are many intertwined issues. Crucial
         question is what are we designing. Are we designing a color
         object for the web or a thing specific to CSS parts of which
         can be used elsewhere. Without a clear sense of what we're
         designing it's hard to scope other technical comments
  astearns: Can you open an issue specifically on that saying are we
            designing CSSColorValue as a color object for the web? And
            particular issues that crop up there will need to be spun
            out and they may depend on the general answer.
  chris: Happy to do that

  <chris> The more up to date Canvas proposal for WCG and HDR is here

  plinss: chris said a lot of what I want to say. I accept this is
          bigger and needs more discussion and eyes. I'm concerned if
          we push this to next F2F or a long term period that a lot of
          work will be done in a direction without us picking one and
          I don't want to get to where we're stuck
  <lea> plinss +1
  <chris> plinss++
  <fantasai> plinss++
  <florian> plinss++
  plinss: I want to address the meta issue about purpose of these
          classes before more work gets done leading us down that path
  astearns: Happy to convene a meeting specifically on this as well.
  TabAtkins: Wanted to say the scope of current work people are
             building on is about an input to canvas APIs. Accept CSS
             values as strings and want to accept as typedOM.
             Everything you can express in typedOM is possible by
             putting it in string form so any of those concerns have
             been present since canvas was introduced. Anything
             further about this being a general color object should be
             discussed, but not as pressing because no one is building
             on that in the short term
  TabAtkins: Let's have the larger discussion when we can prepare and
             have time for it. No reason to be afraid we're setting
             anything by not discussing because nothing you can do now
             that can't do in strings
  plinss: I want to agree with TabAtkins in part and rebut part
  plinss: TypedOM objects as inputs is non-controversial
  plinss: Problem is what are we using as the output and that is more
          pressing. There's eyedroppers and color inputs that TAG is
          reviewing and they output colors and we need to tell them
          how to input. Need shorter than 6 month answer
  <TabAtkins> Oooh, I wasn't aware of those impinging on this work.
  <TabAtkins> (Our next f2f is sooner than 6 months ^_^)

  astearns: Please continue discussions. New issues will be opened and
            we'll come back

  <lea> I will reiterate that using CSSColorValue as input is not
        something that needs to be explicitly added to a spec, as long
        as it serializes

CSS Images

Behaviour of SVG degenerate aspect-ratios
  github: https://github.com/w3c/csswg-drafts/issues/6286

  iank: Digging into replaced elements. Series of test cases in grid
        repo that is probing this and there's a subtle difference in
  iank: If you go to SVG issue it contains example in 1st comment.
        When embed SVG in image need to know SVG intrinsic size and
  iank: SVG are unique in you can have one or the other or both.
        Firefox has intrinsic but no aspect-ratio.
  iank: Blink and WK has both
  iank: Specific example: have width 0px, height 50px. Viewbox says
        aspect-ratio is 1-1
  iank: Firefox has intrinsic 0x50 which matches Blink and WK.
        aspect-ratio is different
  iank: Firefox does one interpretation where treats aspect-ratio as
        degenerate and null. Blink and WK go this is degenerate so
        fallback to viewbox
  iank: That's the crux of the issue
  <TabAtkins> example: <img width=100px src="<svg viewBox='0 0 1 1'
              width='0' height='50px'>">
  <TabAtkins> what is the <img>'s height?

  fantasai: If in general case have width of 1px rather than 0 we will
            ignore viewbox and use aspect-ratio from width and height?
  iank: Correct
  fantasai: Because it's degenerate blink falls back to viewbox, and
            gecko continues to ignore viewbox
  iank: Correct. Written down in the CSS spec. Linked to SVG text but
        it's same text.
  iank: I don't think when algorithm was written it considered that
        width and height could result in degenerate a-r
  fantasai: Yeah, I don't think we considered this
  iank: You can also specify width -50px and get same behavior
  fantasai: I have no opinion of what we out to do here. Don't think
            it matters for authoring. Would be interested to know what
            AmeliaBR thinks
  <TabAtkins> I too have no real opinion on how we resolve this. Both
              behaviors seem reasonable.
  iank: Yeah, tagged AmeliaBR on the SVG but haven't received a
  fantasai: Is there a reason to do one or the other?
  iank: Not particularly. Could argue blink/WK is slightly better in
        that we use an aspect-ratio when it's available. But really I
        don't expect authors to write this. Only reason I'm bringing
        it up is there's 6 test cases asserting a behavior, I think
        written by a Gecko engineer. Not clear those tests are right
  fantasai: Yeah, should clarify
  fantasai: As long as we can't think of a reason my inclination is
            let AmeliaBR read and make a decision for us
  fantasai: I can ping her

  iank: Anyone else with thoughts?
  astearns: This is just what to do in this edge case and theres no
            real world changes we can think of that would result from
  iank: Correct. Not addressing because a bug. Going through grid test
        suite and noticed this edge case was unclear
  astearns: Happy going with AmeliaBR but also happy going with 2/3 of
            engines went this way so let's spec
  astearns: Leave until AmeliaBR comes?
  fantasai: Or resolve to do whatever she says
  astearns: Objections?

  chrishtr: Question
  chrishtr: Did we discuss if degenerate cases in non-SVG are handled
  fantasai: 2 sources of information for aspect-ratio. Most image
            formats don't have that confusion. We have general
            degenerate case, but here is when hit in more primary
            source of information. Do we fall back to secondary?
  iank: Some precedent in aspect-ratio where if you specify a
        degenerate it falls back to image's aspect-ratio I believe
  iank: Is that right?
  fantasai: Don't remember off top of head but I think we decided that
            to match SVG
  <fantasai> "If the <ratio> is degenerate, the property instead
             behaves as auto."
  iank: With that small amount of precedent then Blink/WK behavior you
        can tie together. aspect-ratio behavior is if it's degenerate
        it falls back to next best thing
  astearns: Did that answer question?
  chrishtr: What I heard is it's much more uncommon because images are
            unlikely to have 0 height
  fantasai: Not a real world case
  chrishtr: because SVG is replaced element it behaves different
  <iank> https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=9292
  iank: Example ^ showing fallback for aspect-ratio property. I spec
        degenerate where it will use the images a-r
  iank: That's the fallback. If we want aspect-ratio to have this
        fallback being more consistent then blink/wk fallback makes
        more sense
  <cbiesinger> I mean, for a while a-r: 1/0 was a parse error
  <cbiesinger> but I think that was changed for consistency with
               calc() that computes to zero
  <fantasai> and then changed to 'auto' because that's what SVG does,
             IIRC ...

  astearns: Given that bit of consistency shall we resolve on Blink/WK
            and see if AmeliaBR objects?
  dholbert: I weakly lean against that. Feel like with aspect-ratio
            property if you're explicitly providing invalid it makes
            sense to not do anything. In SVG we've got a usable height
            and width and it makes sense that does establish a value
            to use
  iank: You can also specify -10px width and has same behavior. And
        you don't render at -10
  dholbert: True. More that aspect-ratio is downstream. Don't feel too
            strongly. Feels a little weird adding a special fallback
            that no one will need for real content. I think it's a
            trivial change
  fantasai: I think we should wait and hear back from AmeliaBR. She
            might have SVG logic that leans one way

CSS Color Adjust

Re-add only to mean "don't auto-adjust me", per WebKit's behavior
  github: https://github.com/w3c/csswg-drafts/issues/5089#issuecomment-840840562

  TabAtkins: There's some details which I don't have clarity on
             exactly behavior of 'only' keyword. Something about
             suppressing auto-darkening. Since I don't have great
             details and browsers aren't trying to ship force
             darkening I propose punt to L2
  smfr: Even though not in Safari it is in the mail app and we
        consider CSS to cover non-browsers. Only is UA should not
        apply auto color adjustment to content.

  smfr: One of the issues spec doesn't address is color scheme and
        forced color interaction. Interesting on how color scheme
        should interact with forced colors and can authors opt out of
        forced colors
  fantasai: Do have a property to opt out
  <fantasai> https://www.w3.org/TR/css-color-adjust-1/#forced-color-adjust-prop
  smfr: We do but separate. I think need mind-meld of color scheme,
        color adjust, and forced color adjust and I don't think spec
        teases it out
  TabAtkins: We preferred to say don't merge, they're separate, and
             treat them as such. I think that's the next issue
  smfr: I guess I'd like to hear from an implementor that has both to
        understand how they interact
  chrishtr: Chromium has both. I believe they don't interact
  chrishtr: Some chromium browsers to have auto-dark mode that's use
            controlled. Ex Samsung internet. Content opting out is
            important where auto-darkening doesn't work well

  TabAtkins: Alright, was under assumption there wasn't anything out
             there. We should address. I'd ask smfr to provide more
             details on how this works so we can add a spec
  TabAtkins: Would like to know what things cause dark and light to
             happen, the whole shebang so we can write a spec for it
  smfr: There's a URL for original proposal we implement.
  <smfr> original proposal on which color-scheme is based:

  futhark: We also have opt-out of forced in Android. We use meta tag
           presence as a way to opt out for web view apps

  fantasai: Answering about interaction. If you have forced color and
            can determine if it's light or dark we force color scheme
            to be that. Color scheme and MQ get changed by forced
            colors. Color scheme does not cause forced color to do
  smfr: Forced color always wins?
  fantasai: Yes and changes color scheme to match
  smfr: Only way to opt out is forced-color-adjust property?
  fantasai: Yeah
  astearns: So we'll continue to discuss and not punt?
  TabAtkins: Yeah

Combine forced-color-adjust and color-adjust properties somehow?
  github: https://github.com/w3c/csswg-drafts/issues/3880#issuecomment-839880816

  TabAtkins: Been an issue for a long time wondering if we can combine
             the properties and generalize into a larger thing that
             controls color adjustments
  TabAtkins: After discussion fantasai and I concluded we shouldn't
             because addressing different issues. Don't think
             appropriate to make it easy to turn them all off at once
  fantasai: And have WG resolution on this
  <fantasai> https://github.com/w3c/csswg-drafts/issues/3880#issuecomment-816280715
  <fantasai> https://github.com/w3c/csswg-drafts/issues/3880#issuecomment-816275920
  fantasai: Reason it's on agenda is leaverou brought up information
            about color-adjust property and looking at data. That
            color adjust mostly affects print but has generic name it
            seems like it should be shorthand. There was
            -webkit-print-color-adjust. Looking at that wondering if
            should call it print-color-adjust and leave color-adjust
            as a deprecated alias
  <smfr> +1 to print-color-adjust
  fantasai: Reason it was generic is we thought it would be a generic
            switch but it doesn't end up working well. Having a
            generic name is more confusing than helpful
  <lea> +1 to print-color-adjust
  astearns: Seems reasonable to be more specific, though have to
            support both

  florian: Wondering while not fully generic are we sure it's not more
           generic than print? Not wasting energy for screens with
           different profiles. There might be adjustments similar to
           print but not actually print. Or are we ruling those out?
  fantasai: Good point but majority of use is for print.
  smfr: There is a potential application. If we do HDR colors they
        have a power usage impact so this may allow authors to decide
        if high energy colors are allowed
  florian: Thanks for a more concrete example. Could a default be
           suppress and opt in or no default suppression?
  smfr: Haven't decided yet. Maybe prevent cross-origin. Who knows
  chris: Implementations require an explicit request for HDR current.
         I think that would be the case here
  florian: So could be applicable?
  chris: Certainly
  florian: Should we punt and explore that topic? Or is there time
  fantasai: 2 open issues on color-adjust. One is waiting on review
            and the other we just discussed. Not much time pressure

  astearns: Point of moving the name is to disabuse that color-adjust
            is a shorthand?
  fantasai: yeah
  astearns: Pretty weak reason to add another name
  fantasai: And that people are using print-color-adjust and WK is
  florian: We're aliasing through shorthanding so we could add
           highdef-color-adjust and then color-adjust is a shorthand
  astearns: Deprecate the generic until we have a need and than
  chris: I like combining the 2 if we need it
  florian: And can do separately
  florian: Introduce print, make the non-specific a shorthand but call
           it deprecated for now
  astearns: Arguments against?
  astearns: Proposal: Add print-color-adjust as an alais for
            color-adjust and have the generic color-adjust be

  RESOLVED: Add print-color-adjust as an alias for color-adjust and
            have the generic color-adjust be deprecated

  <fantasai> Note https://github.com/w3c/csswg-drafts/issues/5710 is
             the major issue still open

CSS Contain

:root/body viewport propagation and containment
  github: https://github.com/w3c/csswg-drafts/issues/5913#issuecomment-836692271

  futhark: I was not in APAC call so clarification questions.
           Resolution says stops propagation if there is containment.
           Applied or contain property?
  futhark: Does paint containment stop it? Any containment?
  futhark: And then there is which spec does this go into? Various
           specs that talk about propagation or the CSS Contain spec?
  futhark: I don't know if anybody had opinions

  astearns: So where does this get specified?
  florian: Suggest contain spec, possibly with notes pointing to it
  astearns: Objections to spec this in CSS Contain

  RESOLVED: Specify this in CSS Contain

  astearns: What types of containment change propagation?
  astearns: Any non-default or all of the values that create a
  futhark: Problem with those that establish a container is we may
           need to change behavior as we add values
  futhark: Can spec as the containment necessary to establish a
           container but that breaks content if you use containment
           for all things
  astearns: Downside to saying we break propagation for non-default
  futhark: Don't think so. Not strictly necessary
  florian: Feels overkill, but is it really bad?
  fantasai: My thoughts exactly
  florian: We're not effecting any amount of propagation from root,
           it's from body to root?
  futhark: Body to viewport and potentially root
  futhark: Also for applied containment. Used or applied
  astearns: Sounds like your preference is that if the used value of
            containment is other than default it breaks propagation
  futhark: Yep
  astearns: Slightly worried that things which use contain:paint might
            depend on propagation but can't think of a reason
  <iank> I think its a non-issue here
  florian: In the absence of container queries, doing containment on
           body might not be common, so we're probably fine

  astearns: Proposal: If the used value of contain is other than the
            default we break propagation
  astearns: Objections?

  RESOLVED: If the used value of contain is other than the default we
            break propagation

  <chrishtr> \o/
  astearns: Other questions on your list?
  futhark: No

  astearns: I think we are done for the day. thanks everyone for
            calling in and we'll talk next week

Received on Wednesday, 19 May 2021 23:07:32 UTC