W3C home > Mailing lists > Public > www-style@w3.org > September 2020

[CSSWG] Minutes Telecon 2020-09-30 [css-ui] [accent-color] [css-scroll-snap] [css-scroll-anchoring] [css-content] [css-color-adjust] [css-text] [css-overflow]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 30 Sep 2020 19:30:22 -0400
Message-ID: <CADhPm3v_jdYM0t9X0F0NOcr5n6nXArnU7vwRd2kTDy9a4VdUJw@mail.gmail.com>
To: www-style@w3.org
  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.


  - The request in issue #5480 (Should interoperability be a goal for
      the `accent-color` spec?) is to select between two approaches:
      - Option A: The proposal for Option A is the full proposal. This
          includes the normative section, the Motivation and Intent
          section, and the non-normative examples section. Link to
          full proposal:
      - Option B: The proposal for Option B is just the normative
          section, with the 4th paragraph referring to "interop"
  - There was also another proposal put forward in issue #5544 (make
      accent-color: <color>+ a list of alternatives, not complements)
      which didn't slot neatly into either Option A or Option B,
      though it was a bit closer to Option B.
  - On the call there wasn't clear agreement between Option A and
      Option B. Some of this was due to the new proposal and some due
      to a general desire to not be too vague or too specific but
      finding that hard to fit desire into the current binary choice.
  - Discussion will continue on GitHub to further clarify that the
      Option A and Option B are not final selection of language but
      instead a general direction as well as how issue #5544 should be
      considered in this discussion.

CSS Scroll Snap and Scroll Anchoring

  - RESOLVED: scroll-snap overrides scroll-anchoring for behavior
              heuristics (Issue #4830: Clarify the interaction between
              snapping and scroll anchoring)

Scroll Snap

  - RESOLVED: Close no change based on reasoning in
              (Compat between webkit and blink/gecko regarding
              "implicit" scroll boundary snap positions)

CSS Content

  - RESOLVED: 'auto' value of quote to be based on parent language
              (Issue #5478: Quote character choice must depend on
              surrounding language, not language of the quotation)
  - RESOLVED: Add 'match-parent' keyword [to quote property] (Issue

CSS Color Adjust

  - RESOLVED: Colors assigned due to forced-colors mode are not
              interpolatable (Issue #5419: Clarify expectations re
              forced-color mode, system colors, and transitions)

CSS Text

  - RESOLVED: Defer the behavior of discarding line breaks adjacent to
              ambiguous characters to L4 of css-text (Issue #5017)

CSS Overflow

  - iank is leading an effort to slowly see how much of the currently
      incompatible behavior for scrollable overflow (Issue #129:
      Clarify padding-bottom in overflow content) can be resolved in
      the way authors would expect without causing issues for web
      compatibility. The plan is to make incremental small changes
      over the next few months and then report the results back to the


Agenda: https://lists.w3.org/Archives/Public/www-style/2020Sep/0030.html

  Rachel Andrew
  Adam Argyle
  Tab Atkins-Bittner
  Rossen Atanassov
  Christian Biesinger
  Mike Bremford
  Tantek Çelik
  Daniel Clark
  Emilio Cobos Álvarez
  Elika Etemad
  Brandon Ferrua
  Simon Fraser
  Mason Freed
  Chris Harrelson
  Daniel Hobert
  Dael Jackson
  Brian Kardell
  Jonathan Kew
  Ian Kilpatrick
  Una Kravets
  Daniel Libby
  Peter Linss
  Alison Maher
  Theresa O'Connor
  Anton Prowse
  François Remy
  Melanie Richards
  Florian Rivoal
  Jen Simmons
  Greg Whitworth
  Zheng Xu

  Amelia Bellamy-Royds
  Chris Lilley
  Miriam Suzanne
  Lea Verou

Scribe: dael


Should interoperability be a goal for the `accent-color` spec?
  github: https://github.com/w3c/csswg-drafts/issues/5480

  Rossen: Based on last week's discussion we want to discuss the
          accent-color topic one more time and see if this is
          something we should pursue and how
  Rossen: We're going to cap this to 10 minutes. If we cannot come to
          consensus we'll push back to GH until consensus there.
  Rossen: I want to have chrishtr or masonfreed summerize outcome
          they're looking for and ask group if consensus. If none I
          want clear constructive feedback.

  <masonfreed> https://github.com/w3c/csswg-drafts/issues/5480#issuecomment-697747055
  masonfreed: Make it crisp. Looking for resolution for A or B in link
  masonfreed: Looking for a direction, interop vs hint. Interop is
              full proposal as presented. B is a striped down version
              with no normative text or guidance on how to do
              accent-color. A or B with a link in the thread.
  Rossen: Questions or feedback?

  florian: Seems to be a linked issue from fantasai is a variant C.
           It's closer to B but not identical.
  <fantasai> https://github.com/w3c/csswg-drafts/issues/5544
  florian: That one ^
  florian: If fantasai is on maybe she can explain. It should be part
           of conversation.
  fantasai: We have accent-color list of color but use of colors is
            not clear. Explains primary, tertiary accent colors. If
            you pick a bunch of colors of the rainbow you have no idea
            how they're used. In general noticed platforms have 1
            color so multiple maybe not needed. Do have problem about
            where ever color is we don't know how used with respect to
            background color.
  fantasai: We allow UA to adjust luminance.
  fantasai: My proposal is define accent-color to be a list of
            alternative. You expect to pick a bunch of colors and UA
            picks the one with correct amount of contrast. Rather than
            make it be about different usage but about which has right

  <fantasai> https://github.com/w3c/csswg-drafts/issues/5480#issuecomment-682242811
  fantasai: I think overall my take that TabAtkins comment ^ is the
            key piece of the design
  fantasai: [reads it]
      The goal should be only and exactly enough specification to
        ensure that authors can use the property without
        browser-specific hacks, such that if an author makes it look
        good on one browser, they won't make it unreadable on another.
      Anything more is overly restrictive, anything less means the
        feature is useless.
  fantasai: The idea is the UA should be able to do what it feels is
            appropriate and we shouldn't pin down on how to use the
            color but should make sure there's enough contrast.
  fantasai: I think going in direction of allowing UA to use color in
            what pieces it wants and make multi color be about right
            contrast helps us get there
  masonfreed: I didn't see that other issue, I apologize. Sounds like
              option B-lite. Less interop than option B. For purpose
              of today is that a vote for option B and we go on and
              define option B more concretely if that's as the way
              group wants to go?
  fantasai: Maybe? I think so?

  Rossen: Are we ready to vote out option A? Does anyone want to
          keep A?
  Rossen: Sounds to me like variants of B but if that's what group
          favors lets move on with additional details to break down B
          into more details.
  masonfreed: I should say Chromium favors A. However we really want
              this so we would accept B.

  fantasai: Looking more I think my proposal is a really a different
            thing. Both A and B define accent-color. As to how much
            detail that's a different thing.
  masonfreed: Level of detail is the question for today.
  fantasai: I would go with B for details. A lot of specific cases in
            A should be examples. Here's an example of how you could.
            That makes spec clear on intent without providing
            restricting guidance
  <fantasai> I don't have any objection to adding informative sections
             *as examples*. But Proposal A is written as specific
             guidance, which I don't agree with.
  Rossen: We have 2 more minutes on this. If we can't resolve we'll go
          back to GH

  jensimmons: I can't shake feeling that it seems like 2 things being
              debated. One is should we include a lot of non-normative
              text and an attempt to have a lot of info in spec.
              That's A vs B.
  jensimmons: Title of the issue and some comments feel more like if
              you agree we're putting in non-normative text you also
              agree current text is what we end up with. Then we get
  jensimmons: What TabAtkins described is threading the needle so it's
              not overly descriptive but not useless and
              underspecified. If we're trying to call now to include
              text or not if we can unwind from demand about
              incredibly descriptive...we're getting stuck because
              they're being conflated.

  masonfreed: Let's go back to the issue. Post says they're open for
              discussion and further details but first question is
              large direction of A or B.
  Rossen: sgtm. Don't want to resolve on A or B, just on thread.
  Rossen: Thank you masonfreed

CSS Scroll Snap and Scroll Anchoring

Clarify the interaction between snapping and scroll anchoring
  github: https://github.com/w3c/csswg-drafts/issues/4830

  Rossen: Do we have a proposal? Who wants to introduce?
  fantasai: I think this is a question of what wins between snapping
            and scroll-anchoring. I think scroll-snap wins. Not sure.
            I was looking for feedback from WG.
  Rossen: To make sure I got it, is the question which of the two
          prevails if I have scroll-snapping and scroll-anchoring?
  fantasai: That's my interpretation. emilio filed it.

  argyle: Updating a comment on the thread. Been building with
          scroll-snapping. Should target be similar to anchoring?
          Trying to clarify. Page will scroll to hash in URL?
  smfr: Scroll-anchor is page maintain scroll position in face of
        content changes
  argyle: So similar to scroll-snapping maintaining position on resize
          and things like that.
  smfr: Yes
  argyle: I guess I'm confused as to what this is trying to clarify.
  smfr: Let's have emilio summarize
  emilio: I filed this before we defined for layout to resnap. If we
          always resnap after layout I don't think there's an issue
  argyle: Have an issue where you refresh vs hit page first time what
          wins, target or scroll position. How many nested scrollers
          are restored. Sounds like this is more pointed then that case

  smfr: Question for emilio: Does snapping and anchoring have
        different ends states? If snapping is in place and scrolling
        you snap to something. Does scroll anchoring yank you away?
  emilio: I guess ideally it shouldn't. I wonder if there are edge
          cases where scroll position is collapsed and so on
  emilio: I could have added more details to the issue originally when
          this was in my head

  Rossen: Do we move on at this point? Sounds like there is no issue
  * fantasai proposes resolving that snapping overrides
             scroll-anchoring heuristics and put that in the
             scroll-anchoring spec
  emilio: I'll try and look and reopen if I find something

  <argyle> https://web.dev/snap-after-layout/
  <argyle> https://drafts.csswg.org/css-scroll-snap-1/#re-snap

  Rossen: Back to original question as to which overrides, snapping or
          anchoring. fantasai supposes snapping is favored over
          anchoring. Do we have this explicitly? If not it's good to
          be explicit so there's stable expectations for authors
  Rossen: Are you suggesting this because we don't have it specified?
  fantasai: Seems emilio got confused so might as well clarify
  Rossen: Anyone who believes we should favor anchor? Objections to
          scroll-snap overriding scroll-anchoring for behavior

  RESOLVED: scroll-snap overrides scroll-anchoring for behavior

Scroll Snap

Compat between webkit and blink/gecko regarding "implicit" scroll
    boundary snap positions
  github: https://github.com/w3c/csswg-drafts/issues/4037#issuecomment-590372507

  Rossen: Reopened with additional thoughts
  <fantasai> https://github.com/w3c/csswg-drafts/issues/4037#issuecomment-538060075
  fantasai: Proposal is close no change based on majid's reasoning
            based on ^ comment
  <fantasai> per that comment, close as no change
  fantasai: Means WebKit needs to fix to not have implied start and
            stop points. That's how I propose to close.
  Rossen: I see smfr added a tracking bug?
  smfr: This is on my radar and fine
  Rossen: Objections to close no change?

  RESOLVED: Close no change based on reasoning in

CSS Fonts

@font-face overrides for superscript/subscript metrics
  github: https://github.com/w3c/csswg-drafts/issues/5518

  Rossen: Is this ready or continue in GH based on recent activity?
  fantasai: Defer to myles
  Rossen: myles doesn't seem to be on the call. Given activity in GH I
          suggest we continue there and bring this next week

Resize Observer

Should "resize loop error notification" be a warning instead of
    an error?
  github: https://github.com/w3c/csswg-drafts/issues/5488

  fantasai: I didn't know what to do but seems like we should do
  Rossen: Anyone had a chance to look at this and propose behavior or
          take a stance on warning vs error?
  iank: Not sure downgrading completely to warning is correct. I have
        heard webdev uncover real bugs in production. Requires thought
  iank: I think this requires a little bit of thought about how to
        approach this
  Rossen: Let's continue in the issue then
  Rossen: Once you're ready tag it again and we'll look

CSS Content

Quote character choice must depend on surrounding language, not
    language of the quotation
  github: https://github.com/w3c/csswg-drafts/issues/5478

  fantasai: The question raised is we have an auto keyword for quotes
            property. Richard points out the set of language quotes
            you want to use is the set of the parent, not the
            element's language
  fantasai: Do we want to resolve to define auto value of quote to
            choose based on parent's content language rather then
            element's content language?
  Rossen: Comments?
  <tantek> wow I thought we solved that with the Q element back in the
  <fantasai> tantek, this is how the Q element is implemented
  <fremy> this seems to make sense
  faceless2: Works for me and I see Richard's point. Good issue.
  tantek: Agree as well. I thought we did that in IE5 Mac for Q
          element. We should look at Q element
  fantasai: Q element is defined in CSS terms. So we need to fix our

  Rossen: Objections to resolve auto value of quote to be based on
          parent language?

  RESOLVED: 'auto' value of quote to be based on parent language

  fantasai: Second part of issue
  fantasai: If you have quote within a quote you will typically use
            quotation style of contextual language not immediate
  <fantasai> https://github.com/whatwg/html/issues/3636#issue-316269336
  <fantasai> But Lucy replied: “Embrassez George de ma part et
             dites-lui, ‘Embrouille’”
  fantasai: Previously when didn't have auto some discussion on how to
            do that with selectors and ^ have examples
  fantasai: auto inherits as itself. No way to get that behavior of I
            am using the quotation marks of my context.
  fantasai: Can get the behavior but need keyword like match-parent.
            text-align has that to use same resolved alignment as
  fantasai: We added match-parent which says look at my parent value
            and if it's physical inherit. Logical resolve and inherit
  fantasai: Can do similar here where if my parent value is similar to
            quote inherit. If it's auto, resolve that to a string and
            set my computed value to that string and it inherits

  <AmeliaBR> Quotes already need to keep track of nesting, so can't
             auto have a behavior that if this is a nested quote, use
             the same language quotes as the outer level?

  florian: Would that be what match-parent does? I think you want to
           match style but not string.
  fantasai: Nesting if from open/close quote
  florian: Yes, yes.
  fantasai: Keeping track of nesting we don't have to worry about
            here. Nesting levels is handled by counters built into the
            content property and UA is responsible to choose correct.

  fantasai: Do we want to add a match-parent keyword?
  <florian> I think we do
  Rossen: I see one support on IRC
  Rossen: Other thoughts or reasons why we shouldn't?

  jfkthame: Unclear. Is match-parent in UA stylesheet or authors
            expected to do?
  fantasai: I don't know the answer. If want behavior where using
            quotation language of context it's easy in UA stylesheet.
            q q { quotes: match-parent; } should get correct behavior.
            If we want that in UA stylesheet I'm less sure but I leave
            that to i18n and WhatWG. This makes it possible to do
  florian: Seems that if we want q element to be able to have the
           range of behaviors needed to use it properly we should do
           this. If we believe people don't use q element maybe we can
           skip, but if we want it to be useful we should do this.
  faceless2: Then we should do it. I think it's a useful property

  Rossen: Hearing people leaning toward the optional keyword
  Rossen: Thoughts of objections to adding match-parent keyword?

  RESOLVED: Add 'match-parent' keyword

  <florian> figuring what selectors to use to solve this q problem
            correctly used to be seriously hard. auto and match-parent
            make it so much easier.

CSS Color Adjust

Clarify expectations re forced-color mode, system colors,
    and transitions
  github: https://github.com/w3c/csswg-drafts/issues/5419

  Rossen: I know AmeliaBR sent regrets. Seems consensus on issue.
          alisonmaher can you summarize?
  alisonmaher: General issues are specifically when you change
               forced-color-adjust to auto or none do we trigger
               transition. If to or from are forced we would not
               trigger transitions is the proposal
  <fremy> sounds like the right call to me
  TabAtkins: Simplifies impl and happy to have in spec
  Rossen: Also support. Makes behavior predictable
  <AmeliaBR> no need to wait for me: my opinion was “please pick what
             works best for implementations & spec it!”

  emilio: Other than display is the precedent for such a thing?
  TabAtkins: There's a couple of non-interpolatable properties. Some
             have values that cannot be interpolated though others can.
  emilio: This is different. This isn't about interpolatable but about
          if triggers transitions on other arbitrary properties
  TabAtkins: Yes. If the stuff is forced or not controls if other
             properties can interpolate certain values. That is novel.
             Seems easier on our implementation to handle it.
  emilio: Why?
  TabAtkins: Don't know. Rune would have more details
  emilio: To me seems it would make...this would need to be a special

  Rossen: Implementation aside from user or author PoV which behavior
          would you prefer?
  emilio: If author has specified BG transitions I don't see why it
  Rossen: How about if in middle of transition you go to or from
          forced colors. You're going off a cliff for expected. But
          continuing to transition means some things change. These are
          dissonant to me.
  emilio: To make sure I understand saying that changing forced-color
          adjust stops in progress particular property values?
  TabAtkins: Not quite. Any colors coming from forced-color mode don't
             interpolate. In general it's forced vs not and that's
             outside the property.
  emilio: Agree with Rossen similar that stopping transition when
          element stops making boxes makes sense it does make sense
          when you change to stop animations and transitions. I need
          to look deeper into implications.
  Rossen: We do have a resolution on animations.
  fremy: An example of why don't want to transition colors: When in
         forced-colors the backplate is on top of text. Will disappear
         when set to none. Previous text color contrasts backplate so
         you don't want text color to transition because it's a
         completely different background. Text could disappear for a
         few seconds. I think stopping transitions makes the most sense
  emilio: Could make argument with a bunch of different property
          combos, right? Not just forced-colors.

  Rossen: Is this something you want to object emilio, discuss more?
  emilio: Is the proposal colors from forced-colors and colors don't
  TabAtkins: Proposal: Colors assigned due to forced-colors mode are
             not interpolatable
  emilio: I won't object. I need to look more
  emilio: When you revert a property and it goes to color from UA
          sheet I assume that counts as assigned because forced-color
  emilio: You have forced colors. That can cause you to revert some
          properties to UA level. If you use a color; it's not just
          default colors you assign but also the ones you get when
          revert to a value from UA stylesheet. They shouldn't
          interpolate. But same as if author spec revert
  TabAtkins: Should have been from set of forced system colors so yes
  emilio: I don't know. Feels awkward resolution. I would be curious
          about constraints that simplify this in Chrome
  <TabAtkins> https://github.com/w3c/csswg-drafts/issues/5419#issue-677260327
              lays out some initial thoughts, from Amelia, and
              subsequent comments from Alison and Rune

  emilio: I won't object.
  Rossen: If you have a better proposal and want to re-open please do.
  Rossen: Let's make progress now.

  Rossen: Objections to colors assigned due to forced-colors mode are
          not interpolatable

  RESOLVED: Colors assigned due to forced-colors mode are not

CSS Text

Discarding Line Breaks Adjacent to Ambiguous Characters
  github: https://github.com/w3c/csswg-drafts/issues/5017

  fantasai: Proposal was defer to L4
  Rossen: That's an easy proposal
  Rossen: Any reason not to defer?
  Rossen: Not hearing any reasons
  Rossen: Objections to defer the behavior of Discarding Line Breaks
          Adjacent to Ambiguous Characters to L4?

  RESOLVED: Defer the behavior of Discarding Line Breaks Adjacent to
            Ambiguous Characters to L4 of css-text

  Rossen: Issue has a lot more to discuss so I encourage re-engagement
          on github

CSS Overflow

Clarify padding-bottom in overflow content
  github: https://github.com/w3c/csswg-drafts/issues/129

  iank: Introduction for this
  iank: Broadly we have been investigating scrollable overflow
        problems in blink. Lot of inconsistent tests and inconsistent
  iank: Including child margin plus scrollable padding is what devs
        want, we believe. Inconsistent between layouts and directions
  iank: 2 calculations. You take post transform rectangle of child and
        add to scrollable. This is interoperable. Second is this
        issue. Take pre-transform rectangle and add its inflow bounds.
        Use that to determine where padding edge goes.
  iank: We think the model works. How webcompat is it is the question.
  iank: Think we should aim for what webdevs want but stop when web
        incompat. Prepared to slowly switch on various behaviors to
        get closer and closer. May hit a case where can't go further
        due to compat.

  fantasai: Totally in favor. Great to get to where authors want. Less
            likely to have problems with newer layouts flexbox and
            grid. More problems with older like block where trying not
            to add scrollbars when not necessary. Triggering when
            scrollbars appear is where will find problems
  iank: That's where we expect. We're going to do this slowly over 3-4
        months and can report back success. For block in inline
        direction if there weren't going to be scrollbars previously
        we may not add padding but if there would be we add padding.
        Might end up with that which is a bit strange.

  Rossen: Sounds like a good proposal. Should we resolve for flex and
          grid and think about block more?
  fantasai: I think we resolved on flex and grid
  Rossen: I think so too. Don't want to hold them waiting on block?
  iank: If we agree on direction we can report back on each step what
        was not web-compat. We'll start with flex probably. Report
        back. DO resolution on broad model now and web compat
        resolutions later maybe
  Rossen: Proposal is for flexbox and grid? Want to make sure I'm
          going for right resolution
  <fantasai> current spec - https://www.w3.org/TR/css-overflow-3/#scrollable
  fantasai: Spec requires this for flex and grid, optional for block
            with an issue about web compat
  iank: Leave as is and in a few months I can come back with web
        compat data.
  iank: Tentative agreement we want to go that direction is good
  florian: sgtm. We've been blocked on web compat data so let's get
           the data.
  Rossen: Then this is everything for today

  Rossen: Thanks and next week we're APAC time
Received on Wednesday, 30 September 2020 23:31:23 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:16 UTC