W3C home > Mailing lists > Public > www-style@w3.org > May 2022

[CSSWG] Minutes Telecon 2022-05-11 [css-values][css-backgrounds][css-animations][css-transitions][fill-stroke][css-overflow-3][css-pseudo][filter-effects-2][css-lists]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 11 May 2022 19:16:29 -0400
Message-ID: <CADhPm3twB4fJ99uqdeJo31tvvX7mUK7tWAZL-9UOnQWaC+Rs1g@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.
=========================================


CSS Backgrounds
---------------

  - RESOLVED: thin, medium, and thick will be defined as 1px, 3px, and
              5px respectively. (Issue #7254: Specify exact pixel
              values for border-width: thin, medium, thick)

Values, Backgrounds, Animations, Transitions, fill-stroke
---------------------------------------------------------

  - More research needs to be done on current behavior and complexity
      to change implementations prior to reaching a decision on issue
      7164 (How to handle linked list-valued properties?)

CSS Overflow
------------

  - RESOLVED: Always require inline-end padding to be added against the
              inline-end alignment edge for block/flow layout when it's
              a scroll container, thus matching the tests. (Issue #129:
              Clarify padding in overflow content)

CSS Pseudo
----------

  - RESOLVED: Accept the proposed PR. [
https://github.com/w3c/csswg-drafts/pull/7222 ]
              (Issue #7101: Highlight pseudos and emphasis/underline
              properties)

Filter Effects 2
----------------

  - More testing is required around filter and backdrop-filter to
      determine a resolution for issue #455 (backdrop-filter and
      visibility)

CSS Lists
---------

  - The Safari and Blink teams need to investigate the web compat of
      solving issue #7227 (counter-reset in UA sheet causing some
      compat issues) without magic

===== FULL MEETING MINUTES ======

Agenda: https://lists.w3.org/Archives/Public/www-style/2022May/0004.html

Present:
  Rachel Andrew
  Tab Atkins Bittner
  Delan Azabani
  David Baron
  Oriol Brufau
  Tantek Çelik
  Daniel Clark
  Elika Etemad
  Robert Flack
  Simon Fraser
  Jonathan Kew
  Chris Lilley
  Peter Linss
  Alison Maher
  Ben Mathwig
  Eric Meyer
  François Remy
  Jen Simmons
  Alan Stearns
  Miriam Suzanne
  Bramus Van Damme
  Lea Verou

Regrets:
  Chris Harrelson

Scribe: emeyer

CSS Backgrounds
===============

Specify exact pixel values for border-width: thin, medium, thick
----------------------------------------------------------------
  Github: https://github.com/w3c/csswg-drafts/issues/7254

  TabAtkins: Was noticed that we still leave the keyword thicknesses
             undefined. But all browsers agree on widths at 1px, 3px,
             5px.
  TabAtkins: Not sure of the exact history, but absent that, the widths
             are very consistent and don't see a good reason to leave
             them undefined.
  fantasai: Maybe it was that these were like font-size keywords and
            left open to interpretation. We should maybe recommend but
            not require specific widths.
  <fantasai> My suggested wording was “For Web compatibility, it is
             recommended that these keywords be mapped to 1px, 3px, and
             5px, respectively.”
  TabAtkins: On the other hand, we specify a lot of things that could
             be adjusted by e-readers. I don't know that this needs to
             be left undefined.
  TabAtkins: I argue we should go stronger than suggested.
  dbaron: This is one of those things that was left up in the air in
          CSS1, and I don't remember a proposal to define more
          precisely. I support the precise definition.
  fantasai: If everyone else agrees, that's fine.

  RESOLVED: thin, medium, and thick will be defined as 1px, 3px, and
            5px respectively.

Values, Backgrounds, Animations, Transitions, fill-stroke
=========================================================

How to handle linked list-valued properties?
--------------------------------------------
  Github: https://github.com/w3c/csswg-drafts/issues/7164

  TabAtkins: Issue 4431 asked to turn box-shadow into a shorthand. Very
             reasonable. Because it's a list-valued property, we'd have
             to make all longhands the same. It was brought up by
             dbaron that whenever you have these groups of longhands
             and have to sync up all the values, it's problematic for
             implementations.
  TabAtkins: What exactly are the reasons, and to what degree should we
             be avoiding them? This touches on some things being
             proposed and probably coming, like Toggles. It would be
             good to know how careful we need to be.
  dbaron: I'm most familiar with an implementation that no longer
          exists, so this may be questionable input, but my experience
          was that it was a LOT of code to implement these.
  dbaron: Given that, it's not a that strong a preference. It's a case
          where you can get properties where 90% of the work is
          parsing, not implementation on the other end.
  <lea> syncing up list-valued longhands is also a problem for authors.
        This does not match a human's mental model about this at all
  TabAtkins: Do you recall if it was a particular type of syncing up,
             or if it was all equally hard.
  dbaron: I think it was they were all equally difficult and yet things
          were sufficiently different that you couldn't coalesce.
  TabAtkins: We should get input from people working on extant
             rendering engines. Anyone on the call that knows about
             that?
  astearns: Doesn't sound like we have current implementation
            experience here on the call. Lea did mention a problem for
            authors.

  lea: When authors think about list-value properties, they think of
       each thing as a unit. They think, I want this image at this size
       in this place, and the syntax forces them to do things in a way
       they don't think about it.
  <fremy> +1 leaverou
  TabAtkins: Agreed.
  lea: Right, this makes sense with single values.
  TabAtkins: We're asking if it's okay to expand for things that are
             list values.
  florian: When used with a single value on the list, it's useful to
           break up. Authors can help by defining custom properties
           that define certain combinations.
  TabAtkins: That's partially true. Authors can work around the present
             situation, and that's good. But forcing them to work
             around a lot when we could take that need away isn't great.
  TabAtkins: If we can avoid this being necessary in common cases, that
             would be great.
  astearns: The issue is whether we're going to more closely specify
            computed values of list values.
  Sebastian: It's not completely defined yet but most or all
             list-valued properties base their logic on the definition
             for background. So they're just referring to that and
             still differ on implementation. Even within one engine.

  astearns: The difference is something we need to address even if
            implementation difficulty is a problem. I'm wondering
            whether we can get to a resolution about that specific
            difference and then people can start implementation to give
            feedback on difficulty.
  TabAtkins: I'd like to have an idea of the matrix of current
             possibilities.
  fantasai: The main question is are the lists truncated or extended at
            compute time or use-value time? Specification says
            use-value. It was suggested this might be easier if compute
            time was used. The difference in behavior will affect
            inheriting, which most of these properties don't do, and
            might affect result of getComputedStyle.
  fantasai: I don't think it would be a problem to switch over to say
            list-matching happens at computed value time, but don't
            know if that would make implementation easier.

  astearns: We need to clarify what the current implementations do, how
            difficult it would be to change, and what we'd like to do
            in general at computed value time. We should take it back
            to the issue.

CSS Overflow
============

Clarify padding in overflow content
-----------------------------------
  Github: https://github.com/w3c/csswg-drafts/issues/129#issuecomment-1113489051

  iank: Browsers have been very inconsistent about when something is a
        scroll container to apply block- or inline-end padding.
  iank: Chrome very slowly has been moving towards end padding in both
        inline and block directions in block layout mode.
  <iank> https://wpt.fyi/results/css/css-overflow/scrollable-overflow-padding.html?label=master&label=experimental&aligned&q=css-overflow
  iank: I added an exhaustive set of tests that's linked in the
        comment. This test creates a zero-area div and then relposed
        out of the way, but that zero area div is used to push padding
        out in either inline or block direction is various writing
        modes.
  iank: As I was reading back through the issue, there was a conception
        that there are two cases that should behave the same. If you've
        got inline content that's very long in a scroll behavior, it
        should behave the same as if it's been wrapped in a div. But
        the div isn't intrinsically sized and won't push parent padding
        out.
  astearns: The test cases you're talking about are supported by spec
            text?
  iank: Yes.
  florian: We have a conceptual agreement that adding the padding would
           be good, but there might be web compatibility issues because
           if scrollbars show up where they didn't used to be, that
           could be a problem.
  iank: The spec text has written down our current behavior. We're
        shipping that behavior now.
  <TabAtkins> spec text: "Including this padding is optional for block
              containers in the inline axis if align-content is
              normal." with a note saying "hopefully this isn't
              optional, we're waiting for web compat"

  fantasai: Do we want to tighten up the spec now, or wait to tighten
            it up once there's field data?
  astearns: Has there been enough time to evaluate web compatibility?
  iank: We think so. We shipped the “scary” behavior a couple of months
        ago and got zero pushback.
  florian: If other implementers are happy with it, would be happy to
           tighten the spec now.
  dholbert: This sounds fine to me, speaking from Firefox's
            perspective. Having the Web-compat concern removed makes
            this pretty straightforward.
  smfr: Seems reasonable.

  RESOLVED: Always require inline-end padding to be added against the
            inline-end alignment edge for block/flow layout when it's a
            scroll container, thus matching the tests.

CSS Pseudo
==========

Highlight pseudos and emphasis/underline properties
---------------------------------------------------
  Github: https://github.com/w3c/csswg-drafts/issues/7101

  delan: Highlight pseudos have a restricted subset of applicable
         properties. Not all properties in the text-decoration spec
         start with text-decoration-*. Question originally was, can we
         add those and make them applicable. I initially thought we
         should. fantasai and rego have mentioned most of the
         text-emphasis-* properties shouldn't be applicable.
  delan: Maybe only text-emphasis-color should be applied. That's where
         we are now.
  astearns: I'm a little worried that the proposed patch is still a
            little vague. Should we be very specific about what can be
            applied?
  fantasai: I don't think we should be very specific, because as more
            things are added elsewhere, user agents should be free to
            add them here. I think the proposed wording is good enough
            for now.
  <tantek> +1 fantasai
  delan: In general, we're happy with all the properties related to
         line decorations being applicable?
  fantasai: Right.
  delan: So it's the emphasis marks that are contentious.

  smfr: Are we avoiding properties that can cause ink or layout
        overflow?
  delan: Ink overflow yes, layout overflow no.
  fantasai: Ink overflow doesn't trigger scrollbars. We want to avoid
            anything that could cause scrollbars.
  delan: So actually ink overflow no, layout overflow yes. Sorry, got
         those backwards.
  astearns: Ink overflow is okay, layout overflow is not okay. We could
            have a note in the specification saying that's how we
            determine the list of properties.
  delan: We sort of do say that about the layout, but we could be more
         explicit about ink overflow.
  <iank> changes in layout overflow implicitly effects layout.
  astearns: The bit we have about not affecting overflow layout is
            sufficient, I think.

  RESOLVED: Accept the proposed PR

  <fantasai> fwiw spec says “The highlight pseudo-elements can only be
             styled by a limited set of properties that do not affect
             layout and can be applied performantly in a highly dynamic
             environment—and additionally (to ensure interoperability)
             whose rendering within the required area is not dependent
             on the exact (UA-determined) bounds of the highlight
             overlay.”

Filter Effects 2
================

backdrop-filter and visibility
------------------------------
  Github: https://github.com/w3c/fxtf-drafts/issues/455

  emilio: Browsers are weird and inconsistent about backdrop-filter,
          which we hit when starting our own implementation.
  emilio: We haven't found content with visibility: visible in the
          backdrop in the wild, but we should be clear about what
          should happen.
  smfr: My mental model is that you generated a bitmap the size of the
        element with the filter and render the content. So you end with
        a texture with transparent around the edge and then use that to
        composite with the backdrop.
  smfr: So to my thinking, the Safari behavior looks correct, minus the
        toggle bug.
  emilio: Doesn't that mean you should render the whole thing even when
          the backdrop filter is hidden?
  smfr: That is a bit weird, I guess.
  smfr: I think we'd be willing to change to what you suggest.
  emilio: I think determining the visibility by the element the filter
          is on is simpler, rather than rendering the whole thing.
  emilio: Are there other filters that depend on the background behind
          the element? For most stuff you end up filtering transparent.
  smfr: mix-blend-mode is the only one I can think of.
  smfr: I think the way forward is to test with the filter property and
        maybe propose that visibility hidden will always hide the whole
        backdrop.

  dbaron: For what it's worth, I think of visibility: hidden as a
          paint-time effect. It should be mostly independent of this
          compositing things.
  dbaron: It's sort of inherited and controls whether things are
          painted or not.
  emilio: That's what Gecko did, but breaks sites that are set to have
          backdrops hidden.
  emilio: I'll add some links to examples.
  smfr: To dbaron's point, it's like saying it's basically opacity: 0
        but affects hit testing.
  <emilio> https://bugzil.la/1765862 is the Gecko bug ftr
  astearns: Sounds like we need more information and will need to do
            testing around filter as well as backdrop-filter. Take back
            to the issue?
  <flackr> filter seems to be applied from visibility: hidden element
           in chrome: https://jsbin.com/jegijet/edit?html,css,output
  <dbaron> I was saying I think it's like a middle ground between
           color:transparent and opacity:0
  <dbaron> (I might have been muted when I said it)

CSS Lists
=========

counter-reset in UA sheet causing some compat issues
----------------------------------------------------
  Github: https://github.com/w3c/csswg-drafts/issues/7227

  emilio: This is about pages that do their own counters and adding
          them makes things add oddly. Not many examples of this, but
          we found some.
  emilio: I tend to think there should be a magical reset, which is
          unfortunate, but there are things you wouldn't be able to do
          otherwise.
  TabAtkins: Elika had two objections. 1: this wouldn't be overridable,
             as it is now. If you mention a counter, it gets reset.
             There's no way to do a no-op. But we got lucky here. We
             could allow `none` as a counter-reset value alongside
             integers, which would mean “don't reset the counter”.
  TabAtkins: 2: this triggers on specific HTML elements with no CSS
             reason for it. We'd like to avoid that if possible. I'm
             okay with some weird rules, especially around lists, but
             Elika strongly believes that's a problem.
  fantasai: I think we should avoid it if we can. How strong of a web
            compatibility problem is it?
  <jfkthame> +1 to fantasai
  fantasai: So that's a question for the Safari and Blink teams.
  <iank> I'd need Rune to comment.
  smfr: No info at the moment from the WebKit side.
  astearns: Who should we ping at WebKit?
  smfr: I'll be the conduit.
  <fantasai> Question is, can we get Blink and WebKit to align with
             Firefox on this, or do we really need to introduce this
             magic into the Web platform
  astearns: So we're taking this back to the issue for more information.
  astearns: It might be good to outline the possible ways forward for
            this there as well. If someone could add a summary after
            minutes are posted, that might help.

  <florian> reminder: please go vote for the MQ3 proposed corrections:
            https://www.w3.org/2002/09/wbs/33280/mediaqueries-3-proposedcorrections-2022/
Received on Wednesday, 11 May 2022 23:17:09 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 11 May 2022 23:17:10 UTC