Re: [CSSWG] Minutes Telecon 2023-09-27 [css-text] [css-view-transitions] [css-contain]

Not that it matters a lot, but i was at this meeting too 😊

On Wed, Sep 27, 2023, 7:30 PM Dael Jackson <daelcss@gmail.com> wrote:

> =========================================
>   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
>               it)
>
> 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)
>
> ===== FULL MEETING MINUTES ======
>
> Agenda: https://lists.w3.org/Archives/Public/www-style/2023Sep/0026.html
>
> Present:
>   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
>
> Regrets:
>   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?
>   (silence)
>
> 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
>            text-wrap-mode
>   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
>           avoid
>   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
>            buckets
>   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
>           that?
>   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
>                feedback:
> https://front-end.social/@jensimmons/111138016628140950
>
> 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
>          navigation
>   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?
>   (silence)
>
>   RESOLVED: animate backdrop-filter for view transitions similar to
>             transform/size
>
> 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
>          presentational
>   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
>          sense
>
>   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?
>
>   (silence)
>
>   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
>             understand
>   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
>            document
>   florian: Updating a subtree shouldn't dirty the whole page, was the
>            goal
>   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
>             difficulty?
>   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
>              style-scoped
>   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
>            list
>   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?
>   (silence)
>
>   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
>           different
>   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
>            reset
>   fantasai: I agree it's confusing and we shouldn't do it
>   astearns: I'm slightly against the cloning proposal from an authoring
>             perspective
>   astearns: David, if you want to pursue further, you could open an
>             issue
>   fantasai: I object to going that direction
>   florian: If we were to consider it, we need to assess compatibility
>            baggage
>   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
>
>