- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 27 Sep 2023 19:26:56 -0400
- 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 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
Received on Wednesday, 27 September 2023 23:27:30 UTC