[CSSWG] Minutes Telecon 2021-01-20 [css-color-4] [css-pseudo-4] [css-cascade-4] [cssom] [css-overflow-3] [css-sizing-4]

  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 4

  - RESOLVED: All new color functions serialize to themselves (Issue
              #5825: What serialization should be used when using color
              (lab ...) syntax to specify a lab color?)
  - RESOLVED: Make the first parameter in the color function, the
              color space, required (Issue #5825)
  - RESOLVED: Have the minimum precision raised to 10 bits (Issue

CSS Pseudo

  - RESOLVED: Add a warning to the section and close this issue but
              continue work (Issue #4619: Who is currently using
              CSSPseudoElement and what events can target them?)
  - RESOLVED: Use the existing parent function in css pseudo element
              as returning first element ancestor and add an immediate
              parent that could possibly return a pseudo element
              (Issue #3836: Should CSSPseudoElement have a pseudo()
              method? Would it be worth considering having two
              separate properties, Element element and
              Element|CSSPseudoElement parent)

Cascade & CSSOM

  - RESOLVED: Fix the draft of cssom so it points to color 4 and then
              publish (Issue #3827: Link "Applies to", "Canonical
              order" in propdef tables)
  - RESOLVED: Publish cascade after resolution of issue #4838 (Issue

CSS Overflow 3

  - florian will edit the spec to clarify that overflow:clip extends
      paint containment (Issue #5800: Clarify when
      overflow-clip-margin has an effect)

CSS Sizing

  - RESOLVED: Take TabAtkins's last comment in GitHub (Issue #5721:
              Expected size of replaced element with aspect-ratio but
              width/height auto)
    - Comment from GH:
        1. No explicit sizes means it uses the automatic sizes of the
        2. For replaced elements the automatic sizes are the natural
        3. When 'aspect-ratio' is in play the automatic size in the
            ratio-dependent axis is instead calculated from the size
            in the ratio-determining axis + aspect-ratio
        4. Since both 'width' and 'height' are using automatic sizes,
            the ratio-dependent axis is the block axis by default.


Agenda: https://lists.w3.org/Archives/Public/www-style/2021Jan/0008.html

  Rachel Andrew
  Adam Argyle
  Tab Atkins-Bittner
  Christian Biesinger
  Oriol Brufau
  Elika Etemad
  Simon Fraser
  Daniel Holbert
  Dael Jackson
  Sanket Joshi
  Brian Kardell
  Johnathan Kew
  Una Kravets
  Vladimir Levin
  Daniel Libby
  Chris Lilley
  Ting-Yu Lin
  Peter Linss
  Alison Maher
  François Remy
  Morgan Reschenberg
  Florian Rivoal
  Devin Rousso
  Alan Stearns
  Miriam Suzanne
  Greg Whitworth
  Lea Verou

  Tantek Çelik

Scribe: dael

  astearns: Thanks to everyone for calling in on time. We'll wait a
            couple more minutes to get the list of people online to
            fill out
  astearns: Let's start. Any changes to the agenda?

Color 4

What serialization should be used when using color(lab ...) syntax to
    specify a lab color?
  github: https://github.com/w3c/csswg-drafts/issues/5825

  chris: I added some comments before the call to clarify the options.
         Two questions, what to do for lab and lch and what do for
         extended precision. Start with lab and lch.
  chris: Spec says if you use lab and lch, lch serializes to lab. But
         if you do color (lab) it serializes to color. Suggested is
         all three serialize to lab. I'm willing but wanted feedback
         to if it's an improvement
  leaverou: On one hand, we have the rule values serialize to shortest
            form. Might be helpful for authors if number of formats
            returned is fewer than ones spec.
  leaverou: I can see arguments for serializing anything that doesn't
            need backwards compat as color

  <TabAtkins> We shouldn't change the specified function like this -
              color() should remain color()
  astearns: TabAtkins mentioned something on IRC. I believe color
            remains color and it's only when serialized with a bare
            lch or lab
  chris: correct
  <chris> Tab, not a proposal
  astearns: I can see argument for shortest that if your color happens
            to have a lab we could serialize to that
  TabAtkins: I'm confused. First post on thread asks for that. Color
             with lab color space to serialize to lab function
  TabAtkins: My assumption is lab should be used when refer to color
             of lab space
  chris: I hadn't read it as meaning that. I read as unclear and said
         spec says what to do. Then it drifted to should we harmonize
  TabAtkins: We shouldn't change function in a major way. They should
             get back out what they put in. Color function has a lot
             more functionality than individual color functions. Would
             be strange to lose that. In TypedOM it would serialize to
             form without fallbacks
  chris: Agree. If you look at my A and B options I don't propose do
         away. A is continue as is. B is serialize as color(lab)
  chris: Clearer?
  TabAtkins: Yes.
  TabAtkins: Taking that opinion we shouldn't do B because it's
             unexpected. I think maybe not A because I find it weird
  chris: When discussed previously seems to be what people want.
  TabAtkins: That's true
  leaverou: hsl() also serializes as rgb(), so lch serializing as lab
            is the same

  plinss: I agree with TabAtkins it's strange if functions changed. If
          we get to world with TypedOM where it serializes as the same
          function the author created. Will make a world of hurt if
          functions change, esp if inconsistent

  <argyle> i like option B as well
  astearns: argyle you mentioned you like changing in IRC?
  argyle: I like it. I am acknowledging hsl serializes to rgb. It is
          the common space. Most common is where tried to serialize. I
          like in option b you can write in either syntax and get the
          superset. You get the higher order. It seems like it
          upgrades colors not downgrade or transfer.
  <bkardell> of the two I like B better too, I think - but it's really
             hard to say without actually using it and living with it
             for a while :-p

  <TabAtkins> Note that the TypedOM will give trivial conversions to
              whatever function form you want.
  chris: I see a comment the TypedOM gives color conversion functions.
         That's not clear to me. I thought that was case but I think I
         see it gives a null string. Discussion on twitter it should
         be separate spec.
  chris: I believe in future there will be color conversion functions,
  chris: That's broader. I could type hsl and get lab. That's much
  <TabAtkins> That Twitter discussion is not reflective of the current
              spec or my continued intention, fwiw.
  leaverou: Even though TypedOM helps because authors don't parse
            manually, they still have to handle different formats
            because closely tied. If lab serializes as color(lab) it's
            unclear to me what TypedOM class will correspond.
            serialization or specified?
  TabAtkins: TypedOM reifies to the class function it would serialize
             to. Specified you get what you put in and computed it's
             rules for conversion
  TabAtkins: Another reason not to change into color is class
             correspondent to color is more difficult to work with
             than lab or lch class. If people using anything else
             would prefer to give easiest to work with.
  <fremy> What TabAtkins just said makes a lot of sense to me
  leaverou: The more different classes and author could expect they
            need to handle. If they don't know color they have to
            handle it
  TabAtkins: Can convert to any form they want
  astearns: And if they return color they would still need to deal
            with first param with all the variations

  chris: Hearing arguments on both sides but no clear consensus.
  smfr: Can you summarize?
  <astearns> options:
  chris: The ones in GitHub. Option A is serialize lab and lch with
         shortest form which is lab.
  chris: Option B is lab and lch as color(lab)
  chris: TabAtkins was worried about an option c that serializes
         color(lab) as lab. I only see objections to that.
  <TabAtkins> I was worried about that because Sam proposed it in the
              original post. ^_^
  smfr: Have to consider along with serialization of rgba and srgb. If
        you look at comment from 3 days ago from Sam he suggests
        [reads] and lab is odd one out
  smfr: One of the considerations is if you used color for srgb you
        want to round trip precision.
  chris: Agree in general. color 3 required round to 8 bits. Currently
         min is 8 bits on both. Happy to increase for color which
         might make sense. I don't know how much existing code exists
         elsewhere but none for color form.
  chris: It's always been 0 to 1 so you had precision
  leaverou: If this is higher precision we could consider opt in to
            other handling
  smfr: One approach would be consider rgb/hsl as legacy and all newer
        colors serialize with color function
  chris: I can see that as clear
  <TabAtkins> My preferred option: serialize lab() to lab(), lch() to
              lch(), and color(anything) to color(). I'd accept
              serializing lch() to lab() if necessary, but would
              prefer to avoid that.
  leaverou: TabAtkins would you argue for changing how hsl serializes?
  TabAtkins: Long past impossible at this point
  TabAtkins: In an ideal world yes, but the compat is out of our hands
  chris: I quite like smfr's suggestion. Color rgb serializes as
         itself. Therefore lab serializes as color(lab).
  smfr: That falls out. Can see it's annoying for authors
  chris: That's the case in both suggestions. We could change that
  TabAtkins: Only reason lch serializes to lab is analogy?
  chris: Yes
  smfr: My thought was color function is used to describe the color
        space and therefore lab and lch are lumped together. Maybe not
        great for serialization
  chris: There's little legacy code, but ongoing implementations. Time
         to change it is now. In 6 months it's too late to change

  TabAtkins: smfr, because you came in later, I'm moderately against
             normalizing to color function because TypedOM form is a
             lot more complicated than individual color functions. I
             would prefer to give the simpler forms if they put them
  smfr: Reasonable
  <TabAtkins> Omitting the srgb keyword is standard "shortest form
              serialization" stuff, I'm fine with that.
  chris: Since talking about sRGB. The first param is the color space
         and it defaults to srgb. Two ways to default it. If code is
         looking at this in serialized forms maybe it's cleaner if it
         always has an explicit color space. I can argue either way.
         Shortest serializeable or explicit color space

  smfr: Question, if you spec rgba with % which means >8 bit. If that
        serializes do you maintain precision?
  chris: Currently, in color 4 they are no longer int. You can do
         137.5 and it's supposed to go to highest possible with a min
         of 8 bits. Most implementations seems to truncate
  smfr: In WebKit we use color function to trigger higher precision
  chris: Lots of int precision on the web. I've read people worry
         about blowing up dom if it's bigger

  <TabAtkins> Proposal: the sRGB functions all serialize to rgb() (
              partially legacy, and partially consistency). All other
              functions serialize to themselves.
  <leaverou> TabAtkins: hwb() too?
  <leaverou> TabAtkins: it's an sRGB function, but no legacy
  <TabAtkins> leaverou: Yes, that's the "partially consistency" I
              mentioned. ^_^
  astearns: TabAtkins has a proposal to have all legacy rgb serialize
            to rgb and all new serialize to themselves. Sounds like
            people are okay with new functions serialize to themselves
  chris: That would amount to option A.
  astearns: Option A except lch serializes to lch
  chris: Okay
  <TabAtkins> But I'm also fine with just "the current legacy
              functions serialize to rgb(), everything else to itself"
  leaverou: If we do srgb to itself it also makes sense to keep lab as
            itself. It's same thing, really
  chris: Right
  astearns: One person I haven't heard from in a bit is plinss. Would
            you be okay with this?
  plinss: That's what I argued for. I don't believe functions should
          change to other functions
  <argyle> 👍🏻
  astearns: Proposal: All new color functions serialize to themselves

  RESOLVED: All new color functions serialize to themselves

  <TabAtkins> color(srgb 1 0 0) should serialize to color(1 0 0), per
  chris: Follow up on that. If I say color(srgb) it's same as
         color(rgb) if I just give rgb. Should they both go to the
         same form and if so which?
  astearns: TabAtkins says shortest omitting defaults
  leaverou: Not sure it's good to have this form without a color space
  <bkardell> +1 lea
  <fantasai> +1 lea
  <argyle> +1 lea
  smfr: I would prefer srgb as explicit
  <TabAtkins> I'd be fine with removing the optionality of the keyword
  plinss: We're talking about the color function optionally losing
  chris: Making it mandatory
  plinss: When it serializes out you don't have it
  chris: That's one option. We're talking if you want srgb you have to
         say so
  leaverou: And I see agreement for that in irc
  <florian> +1
  plinss: Gotcha. No strong opinion
  chris: I think it's consistent with your argument plinss
  plinss: It's fine. If color space is optional in function I'm fine
          if it serializes without, but also fine with it not optional
  leaverou: Can make optional in the future. If we start optional we
            can't change
  chris: I'm fine removing the optionality
  astearns: Proposal: Make the first param in the color funciton, the
            color space, required

  RESOLVED: Make the first parameter in the color function, the color
            space, required

  <TabAtkins> Just clarifying - does the first resolution apply to
              hwb() serializing as itself?

  chris: I can edit this in
  astearns: Something about precision?
  chris: Yes, if you use srgb you expect higher precision. Min is 8
         bits right now. I'd like to increase. P3 min is 10 bits per
         component. Could make same
  astearns: Proposal: Have the minimum precision raised to 10 bits

  RESOLVED: Have the minimum precision raised to 10 bits

  chris: hwb is same as hsl where it comes out as rgb or rgba
  <TabAtkins> I'm fine either way fwiw
  <TabAtkins> non-sRGB functions
  astearns: Resolution about all color functions is amended to
            different way of expressing rgb?
  chris: I see hwb as similar to hsl
  astearns: Amended resolution is now non-rgb color functions
            serialize to themselves
  chris: Yes
  astearns: Is that first part of issue or all covered?
  chris: Covered that. I think I'm good

  leaverou: If color srgb has higher precision and difference between
            that and srgb is maintained can the colors opt into better
            interpolation? Right now we have backwards compat but
            doing it in lch is far better. If they don't have
            backwards compat concerns maybe they can opt into better
  <argyle> well said Lea!
  astearns: leaverou can I ask you to open a separate issue? That way
            people can weigh in on GH

CSS Pseudo

Who is currently using CSSPseudoElement and what events can
   target them?
  github: https://github.com/w3c/csswg-drafts/issues/4619

  florian: This is more of a request for information. CSS Pseudo
           Element class exists and is an event target, but it's not
           clear what API uses and what events it receives. When the
           issue was raised I think intent was figure out who should
           we talk to when we refine events on Pseudos
  florian: This has been sitting in GH for a while without feedback.
           This is a louder call to figure out who is the crowd
  emilio: I think main consumer is web animations. Like css animations
          that target css pseudo elements. Not aware of other
  florian: I'm a little fuzzy on this because decision to stop using
           pseudo elements as a class on animation, but pointed out
           there still is. But that would be for the group
  astearns: One of the reasons we pushed to have css pseudo element
            historically is we thought regions could be made out of
            pseudo elements but that's moot at this point
  florian: I see reasons why it's useful, but before drafting new
           things it would be good to know what's done

  gregwhitworth: Are you saying you can't animation pseudo elements?
  florian: No, but I believe API shape of animations has changed and
           it's no longer done through pseudo element class set up in
           pseudos 4. I could be wrong. A bit out of my area

  astearns: Anyone else with a known dependency or use case for css
            pseudo element as an event target?
  astearns: So it may be down to whatever use case web animations
            might have?
  florian: Plus what sanketj and I want to add
  sanketj: Does anyone use pseudo element not as an event target? Web
           animations is only thing I could tell which has since been
           dropped. I didn't find any users of pseudo element at all
  florian: I have use cases, but not existing usage

  iank: I think this has been one of the things that's an obvious gap
        on api side. Nice to get target if it's exposed but not high
        priority so hasn't been impl
  sanketj: Should we try to remove css pseudo element and come at it
           again in a different way? Not sure the process
  astearns: If there are no consumers and little implementor interest
            it's plausible to remove it and retain intent of fixing
            the hole in the API. Need motivating use cases to spur
            implementation interest
  florian: I don't know. If we suspect API shape is wrong maybe
           remove. But I believe there are use cases that we're slowly
           getting to. Having a place where we accumulate our way to
           useful thing it would be good. If we start by deleting it
           doesn't speed up getting there
  astearns: Fair point
  astearns: sanketj do you have an argument for deletion?
  sanketj: Not specifically. Originally looked around highlight api
           and there are not highlight events. Pseudo element being an
           event target prompted us to look. I don't think I have a
           way to have it useful in highlight, but I don't have a
           strong reason to delete or keep
  florian: I have other use cases to look into in the near future. I'd
           like to keep working. For now it's hear so no rush to delete

  iank: One thing to keep in mind is only before and after pseudo
        elements make sense with this API. Perhaps merging in that
        this might change is a path
  sanketj: Yes, only tree abiding was designed originally I think. I
           don't believe it works for range based
  iank: Yeah, for example doesn't make sense for ::first-line
  fantasai: Would work for any, but only defined for tree abiding.
            Every pseudo element has originating element. If you
            highlight it will cross multiple pseudo elements as you
            cross multiple elements
  iank: In related to geometry apis and event propagation the tree
        abiding ones are much simpler
  florian: I'd suggest slap a warning across this area of the spec
           saying don't rush to impl but if you have use cases or
           problems bring forward

  astearns: As a way forward put a warning on this part of the spec
            that this is early and needs fleshing out. Do we close
            this issue with a resolution to have a warning or do we
            need to dive into web animations usage more
  florian: Since we're not resolving to delete it I don't think we
           need the explanation urgently
  astearns: Proposal: Add a warning to the section and close this issue
  astearns: Objections?

  RESOLVED: Add a warning to the section and close this issue but
            continue work

Should CSSPseudoElement have a pseudo() method? Would it be worth
    considering having two separate properties, Element element
    and Element|CSSPseudoElement parent
  github: https://github.com/w3c/csswg-drafts/issues/3836#issuecomment-502344378

  florian: This is because it is now possible to have pseudos attached
           to pseudos. In addition to element class having pseudo,
           pseudo element class has a pseudo.
  florian: Another question, pseudo element class has an element
           method that returns originating element. Pseudo on a pseudo
           do you want originating or parent pseudo?
  florian: Original thought is return the parent. Later proposed we
           should have both. Element returns originating element, but
           also have a parent method that returns parent pseudo if
           there is one and if there isn't returns originating
  florian: Got thumbs up so proposal is accept
  astearns: If it's not nested parent returns nothing?
  florian: Returns same as element
  astearns: First is element ancestor and second is immediate parent
  florian: Yes

  fantasai: One thought, if we extend to non-tree-abiding, parent is
            not quite the right word. If you select first-letter
            element parent is the first line or some weird nesting. We
            could call it parent and say these things are special
  florian: It would be walking up hierarchy step by step. Just need to
           define weird cases
  fantasai: As long as people say it can be re-purposed to not quite a
            parent it's fine to me. Just wanted to point out it's
            going to be a bit weird
  astearns: Other opinions?
  astearns: Hearing people in favor
  astearns: Proposal: Use the existing parent function in css pseudo
            element as returning first element ancestor and add an
            immediate parent that could poss return a pseudo element

  RESOLVED: Use the existing parent function in css pseudo element as
            returning first element ancestor and add an immediate
            parent that could possibly return a pseudo element

Cascade & CSSOM

Link "Applies to", "Canonical order" in propdef tables
  github: https://github.com/w3c/csswg-drafts/issues/3827#issuecomment-759849067

  <fantasai> https://drafts.csswg.org/css-cascade-4/#changes
  fantasai: Have some text we can link to. Cascade 4 has a nice
            section of it. Needs to be republished as a WD. Changes
            here ^. One issue still being discussed so may not be able
            to publish today
  fantasai: Other major changes we did is define processing of
            elements not in tree and define term property.

  fantasai: Other problem is that canonical order is only defined in
            cssom editors draft. That's far ahead of /tr and it is
            behind on edits.
  fantasai: In order to crosslink we need to republish cssom. But I
            don't know state of draft and if it should be published or
            needs more edits.
  fantasai: We can't make fix to propdef tables as long as spec is out
            of date
  astearns: emilio do you have an idea of if we could publish cssom
            draft as is?
  emilio: I think we could publish. A few fixes I'd like but they
          interact with HTML
  astearns: Could resolve to publish a new WD of cssom as-is?

  TabAtkins: One edit that might be good to pull in which is remove
             color serialization so we can defer to color 4
  chris: I have removed it. But there's a related issue where it keeps
         linking to color 3 and I want to stop it. But the edits are in
  astearns: Proposal: Fix the draft of cssom so it points to color 4
            and then publish
  astearns: Objections?
  <chris> +1

  RESOLVED: Fix the draft of cssom so it points to color 4 and then

  astearns: What do we want to do on cascade?
  <fantasai> https://drafts.csswg.org/css-cascade-4/#changes
  fantasai: Cascade has an open issue on same-origin check for the
            quirks mode. After that we should be ready to publish.
            That should be most of the outstanding edits. Changes list
            is here^
  fantasai: We made 5 or 6 changes
  astearns: Resolving that one issue will take what?
  fantasai: TabAtkins would know
  TabAtkins: I'd have to review to see if Anne responded
  fantasai: He did
  TabAtkins: Is he saying I'm right? If yes it's easy
  <fantasai> https://github.com/w3c/csswg-drafts/issues/4838#issuecomment-762052244
  fantasai: I don't know. There's the comment ^
  fantasai: Do we want to take a resolution to publish once you and
            Anne decide wording
  astearns: Prop: Publish cascade after resolution of 4838

  RESOLVED: Publish cascade after resolution of 4838

  astearns: Anything else on this?

CSS Overflow 3

Clarify when overflow-clip-margin has an effect
  github: https://github.com/w3c/csswg-drafts/issues/5800

  vmpstr: Clarifying a sentence in overflow that says "If the element
          does not have overflow: clip (or another property defined to
          respect this property), this property has no effect."
          Clarifying what "this property" refers to
  vmpstr: Paint containment clips, would like overflow:clip to extend
          paint containment
  florian: Yes, contain:paint applies. Poorly worded, editor will make
           it better
  astearns: Will handle by making it explicit contain:paint applies?
  florian: Not sure how I'll rephrase but the answer is it applies and
           we'll fix the sentence
  vmpstr: Maybe remove the sentence?
  florian: Possibly. It's 3am so I'm not awake enough to draft the
           sentence on the fly.
  fantasai: Can't remove the sentence because it doesn't apply to most
            elements. Some clipping effects it applies and some where
            it doesn't

CSS Sizing

Expected size of replaced element with aspect-ratio but width/height
  github: https://github.com/w3c/csswg-drafts/issues/5721

  fantasai: cbiesinger brought up case of image with intrinsic size.
            Set aspect-ratio that's not that of the image. Previously
            not possible. Question is what is this supposed to do?
            Have a jpeg that's 200x100, set aspect-ratio as 1-1. What
            does it render
  fantasai: No clear answers. leaverou made a poll with inconclusive
            results. We need an answer. Looking for opinions and ideas
            about why it should be an answer
  TabAtkins: I have a preferred answer here. The aspect-ratio property
             by virtue of it being explicit it should be honored and
             then we round sizing as normal. Use ratio determining,
             take natural size, process through spec aspect-ratio and
             use it. Added a comment on GH
  TabAtkins: In the jpeg example of 1x1 aspect-ratio we set width to
             natural width and then we make it square. You asked for
             it to be square so I think people would expect that
  iank: I agree with TabAtkins' analysis
  <fremy> LGTM too
  <fantasai> wfm
  astearns: Some consensus. Might be easiest to get a good answer by
            declaring an answer and use the get an answer by saying
            something wrong and getting people to say why wrong

  astearns: Proposal: Take TabAtkins's last comment in GH and resolve
            on that
  cbiesinger: Takes writing mode into account?
  TabAtkins: Yeah, ratio determining for axis takes writing mode into

  RESOLVED: Take TabAtkins's last comment in GH

  [Comment from GH

    1. No explicit sizes means it uses the automatic sizes of the
    2. For replaced elements the automatic sizes are the natural sizes.
    3. When 'aspect-ratio' is in play the automatic size in the
        ratio-dependent axis is instead calculated from the size in
        the ratio-determining axis + aspect-ratio
    4. Since both 'width' and 'height' are using automatic sizes, the
        ratio-dependent axis is the block axis by default.

  astearns: Thank you everybody

Received on Thursday, 21 January 2021 00:11:13 UTC