[CSSWG] Minutes Telecon 2023-09-27 [css-text] [css-view-transitions] [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.

CSS Text

  - Nobody was enthusiastic about text-wrap-mode as the property name
      in issue #9102 (Move "balance | stable | pretty" out of
      text-wrap), and there was some concern about it being too similar
      to text-wrap-style to be easily distinguishable, but nobody had a
      clearly better idea. Discussion will continue in github for one
      more week before a final decision will be made.

View Transitions

  - RESOLVED: animate backdrop-filter for view transitions similar to
              transform/size (Issue #9358: Animate backdrop-filter for
              named elements)
  - RESOLVED: Add accessibility non-treatment agreed up on at TPAC to
              the spec, stating the view transition pseudos are
              presentational and have no special accessibility needs
              (Issue #9365: Add a11y text to specify how VT works with

CSS Contain

  - RESOLVED: Fix the example and re-affirm the one-way containment of
              counters by instantiation of new counters (Issue #9212:
              Style containment for counters)
  - RESOLVED: Add a clarifying note about the counter function and
              review the WPT tests (Issue #9212)


Agenda: https://lists.w3.org/Archives/Public/www-style/2023Sep/0026.html

  Rachel Andrew
  Adam Argyle
  David Baron
  Oriol Brufau
  Emilio Cobos Álvarez
  Yehonatan Daniv
  Elika Etemad
  Simran Gill
  Paul Grenier
  Chris Harrelson
  Jonathan Kew
  Vladimir Levin
  Peter Linss
  Alison Maher
  Eric Meyer
  Khushal Sagar
  Jen Simmons
  Alan Stearns
  Miriam Suzanne
  Bramus Van Damme
  Lea Verou

  Chris Lilley

Chair: astearns

Scribe: emeyer

  astearns: Despite progress at TPAC, we have a lot of Agenda+ issues,
            so we'll probably need some breakouts
  astearns: If you have anything you'd like to be a breakout, please
            propose to me or Rossen

  astearns: We're looking to organize the next face to face meetings
  astearns: If there are any things that don't need discussion time and
            can be resolved async, please let me know
  astearns: Any changes to the agenda other than skipping #10?

CSS Text

Move "balance | stable | pretty" out of text-wrap
  github: https://github.com/w3c/csswg-drafts/issues/9102#issuecomment-1735801461

  florian: We discussed the shorthand and longhand relationship between
           white-space and text-wrap
  florian: We only used placeholder names for the longhand properties
  florian: One which is text-wrap-style, and another called
  florian: These two are both longhands of text-wrap, but
           text-wrap-mode (not -style) is a longhand of white-space as
           well (and other things)
  florian: We had discussed that mechanism last time, but
           text-wrap-mode is a placeholder
  florian: It might be fine, but if we want to change it, that needs to
           be discussed
  florian: So change it now, or hold your silence (wink)

  astearns: Where are the text-wrap-mode haters?
  fantasai: To be clear, all of the longhands here are not shipping,
            also any of them could change
  astearns: So you're saying the bikeshedding is not that urgent?
  fantasai: It is because in the previous discussion, we didn't want
            balance, pretty, stable to all be longhands of white-space
            because they get reset every time you change whites-space
  <lea> Ideas: text-wrap-allow: allow | avoid; text-wrap-policy: auto |
        never; text-wrap-mode is not terrible either
  florian: The original placeholder was text-wrap-onoff
  emilio: You would be able to say text-wrap: wrap and white-space:
          nowrap and whichever is latest would win?
  emilio: I mean, it's fine, but it's a bit yucky
  fantasai: Yes, exactly
  jensimmons: As an author, I like what's being proposed because
              white-space is a weird world of “I don't know what's
              going on”
  jensimmons: I think this is the right direction
  jensimmons: A lot of authors could just ignore white-space entirely
  <lea> It would be nice to be able to be consistent with flexbox and
        have it be something-wrap: wrap | nowrap; but obviously we
        can't have text-wrap-wrap :P
  <fantasai> lea, yes exactly :)

  florian: So did we pick the right name?
  jensimmons: We could bikeshed “mode”
  lea: I don't think any is particularly great, but maybe they'll
       inspire others
  lea: I don't think -mode is too bad, but we need to answer whether
       there's ever a chance we'd want to expand the value set
  lea: Is this always going to be either wrapping is on or off? Is it
       always going to be a switch?
  lea: I think it will help guide the design if these are the only
       values that will ever be
  florian: I think it's extremely unlikely here
  florian: -style might get more, sure, but -mode probably not
  florian: So I think probably it will always be two values
  <lea> more ideas: text-wrap-enabled

  astearns: I'm not hearing significant enthusiasm for -mode, but
            nobody seems against it either
  <fantasai> text-wrap-onoff ftw
  <lea> +1 to gsnedders , yes
  jfkthame: It does sound a little close to -style
  astearns: Lea has suggested text-wrap-enable, which I like
  plinss: -enabled does sound like a binary switch, which we try to
  florian: We could have yes|no|auto
  plinss: In general, our whitespace and breaking controls are a mess
          for historical reasons
  plinss: I'm wondering if this is leading us down the path to
          something better
  florian: It's trying to do that by extracting parts of the mess into
  plinss: The naming of all these controls is confusing for many
          people, but if we envisioned a world where we were doing this
          over, what would it look like, and are we working towards
  florian: I suspect we are
  emilio: I would have chosen text-wrap if we were starting from
          scratch, something like Jonathan suggested
  emilio: Lacking that, -mode seems not terrible
  <lea> we did decide against needing to start with the shorthand name
        as a general design principle, so it doesn't *actually* need to
        start with text-wrap-
  <lea> (Not to mention it's a longhand of two shorthands here)
  <lea> white-space-wrap: wrap | nowrap 😃

  astearns: I think we've spent enough time on this for today
  astearns: I would suggest we keep -mode enabled for now, maybe add a
            note that it's still under discussion
  fantasai: We do need to press people to implement and ship, and we
            need to undo some already-shipping connections
  florian: I think we have made worse naming mistakes than this
  fantasai: We should resolve next week if we don't resolve today, we
            can't let this drag on
  astearns: Let's take it back to the issue and leave the Agenda+ tag on

  <jensimmons> I just wrote a Mastodon question to get a bit of

View Transitions

Animate backdrop-filter for named elements
  github: https://github.com/w3c/csswg-drafts/issues/9358

  khush: There was a case where the author has put a backdrop filter on
         a transition with a name
  khush: This ran into the mix blend problem
  khush: During view transitions, the property gets dropped on the floor
  khush: It doesn't get applied
  khush: The proposal is to treat it similar to mix-blend-mode, where
         the computed value of the backdrop filter gets copied to its
         group pseudo
  khush: Just like anything else, authors can override it
  khush: See the issue for visual examples of what this looks like
  khush: A complicated problem is in the context of cross-document
  khush: Cross-origin restrictions can create problems
  khush: If we serialize the state and transition to another document,
         if they have different policies, it gets blocked, which is
         fine from a security perspective
  khush: The alternative is to transfer resources across, which could
         leak information
  khush: Proposed resolution: animate backdrop-filter for view
         transition similar to transform/size

  emilio: Why is this not a problem with mix-blend-mode?
  khush: We came up with a similar solution there, but it's not
         interpolatable so it just switches over
  khush: In this case, I'm proposing we set up an animation
  astearns: Any concerns with adding backdrop-filter to the list of
            things that get copied over? Any objections?

  RESOLVED: animate backdrop-filter for view transitions similar to

Add a11y text to specify how VT works with it
  github: https://github.com/w3c/csswg-drafts/issues/9365

  vmpstr: We talked at TPAC about how the view tree is not exposed to
          the a11y tree in any way
  vmpstr: We would like to make changes to the spec so we have things
          written down
  vmpstr: During the spec edits, we refactored to say the underlying
          element is invisible, but that's not the correct term
  vmpstr: We would need a different term that means it's visually
          hidden but exposed to a11y

  khush: There is spec text that was in before we changed it, which
         said “invisible boxes”
  khush: I think that's closer to what we want
  khush: It did miss talking about pseudo-elements being skipped by
         screen readers and so on
  PaulG: One of the reason I didn't go back to APA because this seemed
  PaulG: Presentational content is not lifted into the AX tree
  PaulG: Unless these pseudo-elements can carry additional information
         the way ::before and ::after can, I don't see a reason to push
         for this
  vmpstr: Can you clarify? The proposal is that we'll skip the AX tree
  <fantasai> it sounds like y'all are agreeing
  PaulG: Ah, okay, I thought the proposal was to augment. We're
         aligned, thank you
  PaulG: I think presentational will mean something to a11y folks and
         they'll start to understand this has no mapped role
  PaulG: I think presentational is the term that will make the most

  fantasai: Seems like we all agree on the behavior
  fantasai: Is the question how we describe that in the spec, or what's
            the open question?
  vmpstr: It's just about the spec text
  astearns: We could resolve to update the spec to take the feedback we
            received at TPAC
  PaulG: Not sure if you need to tag for horizontal review, but I would
         take it to APA to make sure they don't have a problem
  astearns: So, we add text saying the pseudos are not special and
            don't need to be treated differently
  <fantasai> Something like "The view transition pseudo tree is only
             used for visual rendering, and is not exposed to other
             media or to the accessibility tree" ?
  astearns: Any objections?


  RESOLVED: Add accessibility non-treatment agreed up on at TPAC to the
            spec, stating the view transition pseudos are
            presentational and have no special accessibility needs

CSS Contain

Style containment for counters
  github: https://github.com/w3c/csswg-drafts/issues/9212

  astearns: I assume the resolution we want here is “yes”?
  ntim: Right now, I found style container behavior for counters to be
        quite un-intuitive
  ntim: Spec says you should scope counter-increment to the subtree
        that is contained
  ntim: Further effects are unclear

  fantasai: At a higher level, it brings up the question of what style
            containers are useful for
  fantasai: There's two ways to look at it
  fantasai: One is that style containment prevents stuff inside a
            subtree from affecting stuff outside it
  fantasai: Another is that the protection goes both ways, so that also
            stuff outside can't affect things inside the subtree
  fantasai: I think the two-way is a little easier for authors to
  fantasai: I'm not sure if there were good reasons to have one-way
            containment or not

  oriol: This was discussed in 2018 in Berlin; then the idea was that
         we should allow content inside containment should not read
         values from the outside
  oriol: I think this is reasonable; with things like size containment,
         we prevent the size of the element from depending on (missed)
  oriol: Having containment work both ways doesn't seem needed for
         container queries
  oriol: I guess it's reasonable for an author to use a counter in the
         headers of different sections, and maybe they want a section
         to be a container query
  oriol: I think it would be strange to no longer be able to use those
         as counters
  oriol: I think the current way this is specified may be better
  oriol: If people want to have the containment work both ways, that's
         also a possibility, but maybe too restrictive
  TabAtkins: I don't have a strong opinion, but Oriol's summary of my
             reasoning is correct
  <miriam> +1 I don't like making cq-required containment *more
           invasive* than necessary

  florian: Containment in general is meant to be one way
  florian: So, not designed to deliberately isolate parts of the
  florian: Updating a subtree shouldn't dirty the whole page, was the
  florian: As Oriol said, if you aren't using counters, it makes sense
           for them to update into the subtree

  vmpstr: Content-visibility: auto allows to skip styling and rendering
          updates if not needed
  vmpstr: I would like this to remain a one-way barrier

  ntim: I could go either way, but the one-way containment is harder to
        implement than two-way
  ntim: What's important is use cases: if we were to expand style
        containment beyond making container queries work, if we were to
        use for names of anchor position, which behavior would make
        more sense?
  astearns: Oriol, you mentioned if we go with one-way containment, the
            spec would need changes to make that more clear?
  oriol: Yes, right now when counters are modified, they create a new
         instance of the counter
  oriol: The question is where the counter get instantiated
  oriol: Browsers make the new instance in the element that tries to
         modify the counter, which I agree with
  oriol: In complex cases, browsers have several bugs, but in simple
         cases they all agree that new instances are created
  TabAtkins: The example I wrote is just wrong

  astearns: I hear a slight preference for one-way containment
  fantasai: I think Oriol was fairly convincing
  <florian> my pref is rather strong…
  astearns: Tim, would you be okay despite the implementation
  ntim: I guess it's okay
  <dbaron> (I suppose the other option is that the inside of the
           container essentially operates on a clone of the counter
           state as of its start.)
  <fantasai> dbaron, I think that would be more confusing
  <chrishtr> I think one-way is better for authors

  astearns: So this is a “no change to spec, fix example” situation;
            are there tests that need to be updated?
  TabAtkins: I need to check them either way and update if necessary
  ntim: I would want the spec to be more clear
  ntim: Right now it says the scoped property is as if scoped to its
        own document
  ntim: It's unclear the extent of the effects of the property
  ntim: If it's like you isolate the counters in their own document,
        they would all be zero
  TabAtkins: The counter-* properties are scoped, but the counter()
             function is not scoped
  TabAtkins: Using the counter() function does not interact with style
             scoping in any way
  TabAtkins: So it should not be zeroed just because an ancestor was
  astearns: Explicitly saying in normative text that counter() is not
            affected, then
  florian: The spec says what's affected, and counter() is not on the
  astearns: Fair

  sakhapov: I think the problem is counter-increment acts as if the
            named counter is set to zero
  TabAtkins: Yeah, the example is wrong and I need to fix that
  sakhapov: But the HTML code is correct, so maybe move this

  dbaron: I want to mention a slightly different model for one-way
          containment, which is essentially you could do the
          containment by acting as though the counter state gets cloned
          into the contained subtree
  dbaron: That way, an increment inside the subtree would happen in
          ways that wouldn't leak back out

  fantasai: I thought that was the original proposal and it's terribly
            confusing, let's not do that
  fantasai: I like the suggestion that you instantiate a new counter,
            so inside the subtree you can do your own thing
  astearns: Let's resolve to fix the example and re-affirm the one-way
            containment of counters
  astearns: Objections?

  RESOLVED: Fix the example and re-affirm the one-way containment of
            counters by instantiation of new counters

  <ntim> florian, TabAtkins: "the effects of the property on that
         element" is confusing, because counter-increment does affect
         what's read from the counter() function
  <ntim> Hoping the wording can be clarified a bit for that.

  astearns: Are we taking David's suggestion?
  sakhapov: I don't see how different from the current behavior that
            would be
  dbaron: Counter resets would act the same, but increments would be
  dbaron: If you were using the counters() function, and you
          incremented both outside and inside the subtree, the
          difference is that one would give you 3.1 and the other would
          give you 4
  sakhapov: Each counter reset creates a new counter?
  dbaron: The idea is that the clone operation wouldn't be deep, you'd
          only need to clone the most-nested counter
  sakhapov: Do you inherit the reset?
  dbaron: Either way, the counters() function would look all the way up?
  TabAtkins: David's proposal means things inside the subtree won't
             modify counters outside the subtree
  florian: This is maybe more convenient and less confusing
  florian: David's proposal leads to people asking why counters seem to
  fantasai: I agree it's confusing and we shouldn't do it
  astearns: I'm slightly against the cloning proposal from an authoring
  astearns: David, if you want to pursue further, you could open an
  fantasai: I object to going that direction
  florian: If we were to consider it, we need to assess compatibility
  astearns: We should resolve on whether we need to add a note, and
            update the WPT

  RESOLVED: Add a clarifying note about the counter function and review
            the WPT tests

Received on Wednesday, 27 September 2023 23:27:30 UTC