- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 18 Sep 2024 19:00:34 -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.
=========================================
Anchor Position
---------------
- RESOLVED: Whenever you are comparing names, and at least one is
tree scoped, then both are tree scoped, and the scoping
has to be exact (not subtree) (Issue #10526: When does
anchor-scope "match" a name?)
- RESOLVED: The 'all' keyword is tree-scoped (Issue #10525:
anchor-scope and part descendant styling)
Scroll Snap
-----------
- RESOLVED: When scroll-start-target targets multiple elements,
scroll to each in reverse DOM order with text to specify
priority is the first item (Issue #10774: How should
competing scroll-start-targets be resolved?)
CSS Text Decor
--------------
- RESOLVED: Add auto value for text-emphasis-position, and change the
meaning of text-underline-position: auto to care about
left vs right in vertical text (Issue #1198:
text-underline-position auto in vertical text)
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2024Sep/0016.html
Present:
Rachel Andrew
Adam Argyle
Rossen Atanassov
Tab Atkins-Bittner
David Awogbemila
Kevin Babbitt
David Baron
Oriol Brufau
Stephen Chenney
Emilio Cobos Álvarez
Yehonatan Daniv
Robert Flack
Chris Harrelson
Anders Hartvoll Ruud
Daniel Holbert
Brad Kemper
Jonathan Kew
Roman Komarov
Alison Maher
Eric Meyer
Tim Nguyen
Khushal Sagar
Miriam Suzanne
Regrets:
Josh Tumath
Lea Verou
Chair: Rossen
Scribe: chrishtr
Anchor Position
===============
When does anchor-scope "match" a name?
--------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10526
TabAtkins: In anchor positioning, anchor names and references are
tree scoped
TabAtkins: The anchor-scope property that scopes, does not say
whether the names are tree scoped or not
TabAtkins: Question to decide: should they be?
TabAtkins: I think the answer should be yes
TabAtkins: if you have an anchor in a shadow tree with a part
involved, then problems result
TabAtkins: if anchor scopes are not tree scoped
TabAtkins: This is bad, so I think it should be tree scoped
<khush> sounds pretty reasonable
<fantasai> makes sense to me as far as I can understand it :)
andruud: Is this the first time we have a tree scoped name on both
sides of a comparison, without one being a reference?
TabAtkins: I believe yes
andruud: Should we make a more general design statement then?
TabAtkins: Yes I think we should
andruud: Would be good to resolve on that
TabAtkins: I'm good with a broader resolution to set a precedent
andruud: What about references vs names?
TabAtkins: Yeah those are different
<fantasai> agree that name-matching should probably be tree-scoped
rossen: It matches the exact match of the ident and tree scope, is
that what you were referring to in option 2?
andruud: Yes
khush: Thinking about this in the context of view transitions: in
that API you give names and the tree scope has to be the same
for them to match
khush: There is another view transitions feature where I'm not sure
if the spec says it's tree scoped
khush: Want to make sure that feature is covered by the more general
resolution
TabAtkins: Proposed more general resolution: whenever you are
comparing names, and at least one is tree scoped, then
both are tree scoped, and the scoping has to be exact (not
subtree)
RESOLVED: whenever you are comparing names, and at least one is tree
scoped, then both are tree scoped, and the scoping has to
be exact (not subtree)
anchor-scope and part descendant styling
----------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10525
TabAtkins: anchor-scope, in addition to idents, can take the keyword
'all', which scopes all names. Should this be a
tree-scoped 'all'? (i.e. only applies to the current tree
scope)
TabAtkins: Proposed resolution: the 'all' keyword is also tree-scoped
in the same way
<fantasai> sgtm
<khush> +1, again same pattern with view-transition-group
RESOLVED: the 'all' keyword is tree-scoped
Scroll Snap
===========
How should competing scroll-start-targets be resolved?
------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10774
DavidA: We have a property we're adding called scroll-start-target
that indicates if an element within a scroll container, then
the scroll should start with that element onscreen
DavidA: question is what happens if there are multiple targets
DavidA: Propose to do it in reverse-DOM order,
DavidA: this would result in the first one applied last and then be
on screen
DavidA: also, should only change the scroll position if you have to
fantasai: Several questions. first: why do we need to add a new
property rather than re-using scroll-snap-align?
flackr: Setting the scroll alignment for items that don't necessarily
become snaps
flackr: scroll-snap-align would also force the developer to set
scroll snap areas
fantasai: In that case, should there be a relationship between the
two properties?
fantasai: Might want to do both behaviors
flackr: I agree the properties should be strongly linked, possibly
with a shorthanding relationship
fantasai: Suggest thinking about this more on the issue
fantasai: so that we can figure out how the two properties interact
fantasai: There was a bunch of discussion about regular vs
reverse-DOM order. Where did we end up and why?
flackr: Currently, we expect that it scrolls to the first item in DOM
order. We probably want that to still happen. That is why the
proposal is to scroll to each item in sequence in reverse-DOM
order.
flackr: There is also the issue of nearest...
fantasai: Can you explain nearest?
flackr: Same as scroll into view
fantasai: ?
flackr: This is needed with you scroll multiple things into view and
want to find a good position (?)
fantasai: You scroll in reverse-DOM order...when you add the spec can
you make it really clear that this is the end result of the
algorithm?
flackr: Yes absolutely
fantasai: Otherwise it seems to make sense
fantasai: Have questions in general about the feature but not this
issue
flackr: Seems we can resolve that the general thing is good?
<flackr> Proposed resolution: Add scroll-align property to specify
scroll alignment without adding a snap area - details TBD
fantasai: would like to see the interaction with snapping
<flackr> Proposed resolution 2: When scroll-start-target targets
multiple elements, scroll to each in reverse DOM order with
text to specify priority is the first item
rossen: We'll postpone the first resolution until we have more details
RESOLVED: When scroll-start-target targets multiple elements, scroll
to each in reverse DOM order with text to specify priority
is the first item
flackr: Third thing: having a nearest align value
flackr: Not sure if we can resolve without details for resolution #1
rossen: Maybe we should wait for more details
fantasai: Suggest a separate issue be filed about the nearest issue
fantasai: Agree we should do something in that direction, just need
to figure out all the details
CSS Text Decor
==============
text-underline-position auto in vertical text
---------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1198
fantasai: The initial value of text-underline-position is auto, which
is defined as "find a good place to put the underline".
Three options there: (1) under alphabetical baseline, (2)
fully below text (good for lots-of-descenders cases), (3)
for vertical text on the RHS
fantasai: auto value is defined in the spec about 'how far down below
the text', but doesn't say things about flipping
fantasai: the current spec says "at or below"
fantasai: In order to handle language-specific aspects, there is a
default UA style sheet that for Chinese and Japanese and
Korean there are differences for those languages
fantasai: A couple of implementations do this
fantasai: Should we change the spec to mention these things?
fantasai: Or should we stick with the UA stylesheet approach?
<fantasai> https://drafts.csswg.org/css-text-decor-3/#default-stylesheet
<fantasai> https://www.w3.org/TR/css-text-decor-4/#text-emphasis-position-property
<fantasai> https://www.w3.org/TR/css-text-decor-4/#text-underline-position-property
fantasai: Propose that we keep the spec as-is
fantasai: This would require some implementations to change though
chrishtr: Which implementations would need to change?
fantasai: Chrome and Firefox are language-sensitive for auto, and
webkit uses the default UA style sheet
rossen: Does this mean that webkit needs to change?
florian: Other way around, it would mean Chrome and Firefox need to
change if we keep the spec unchanged?
florian: Since the two approaches both exist it seems going either
way would be web compatible
rossen: Sounds like a low-ROI change
rossen: Is it a problem in practice?
emilio: I think we should try to go for the firefox/chrome approach
emilio: avoids weird styles change in ways that developers might not
expect
emilio: We had the same problem with quotes if I'm remembering
correctly
fantasai: That was the first time we had a language-aware value
emilio: Reusing that mechanism for this makes sense, but don't have a
strong opinion
fantasai: If there is a strong need for these things they we could
introduce auto keywords for text-emphasis-position,
otherwise UA stylesheet for this case?
jfkthame: Text decoration skip ink does something language-specific
also, seems to me auto is the cleanest approach
ntim: Aligning with text-emphasis-position makes sense to me, and it
doesn't have an auto value. i.e. that feature uses UA style
sheet rules
chrishtr: Is that true for all browsers?
fantasai: Yes, because there is no auto keyword
jfkthame: It would make sense to me to add auto to that property also
florian: That would be a change in all browsers
jfkthame: Yes but that could be an improvement
ntim: Is it a common use case to use the auto value to override a
non-default value?
ntim: If not, then the UA style sheet does the job just fine
florian: We can achieve the effect we want with the UA style sheet,
or with auto. Both approaches yield the desired result from
an author point of view
florian: From an author point of view, both work. Agree that it's odd
for two very similar properties to have different
approaches, agree it would be best to be consistent.
<fantasai> A) Keep spec as-is, update Gecko + Blink to match (using
UA stylesheet for language switch)
<fantasai> B) Introduce auto to text-emphasis-position and use it in
both text-emphasis-position and text-underline-position to
effect language switches
<fantasai> C) Adopt inconsistent behavior: text-underline-position
uses 'auto' and text-emphasis-position uses UA stylesheet
<ntim> Option b requires changing text-emphasis-position in all
browsers too
<fantasai> POLL: A, B, or C?
<TabAtkins> abstain, no opinion
<emilio> B
<vmpstr> abstain
<chrishtr> B
<jfkthame> B, A, C
<astearns> abstain
<ntim> A, B, C
<fantasai> A, B, C
<ydaniv> abstain
<miriam> abstain
<florian> indifferent between A and B, dislike of C
<dholbert> B, A, C
<schenney> B, A, C
<dbaron> neutral on A vs B, prefer them to C
<oriol> abstain
<rachelandrew> abstain, no strong opinion
<DavidA> abstain
<kizu> abstain
<kbabbitt> abstain
<flackr> abstain
proposed resolution: add auto value for text-emphasis-position, and
change the meaning of text-underline-position: auto to care about
left vs right in vertical text
<florian> wfm
fantasai: One side effect of the proposed resolution is that the
computed style is less transparent to the developer, vs
inspecting the UA style sheet
emilio: You have the opposite argument with making initial do the
right thing, right?
emilio: There are arguments in both directions in this dimension
emilio: Being able to set something reasonable via resets in the
style sheet, I mean
emilio: Would expect the initial value to do the right thing -
resetting gets rid of UA style sheets
jftkhame: Does seem an auto keyword should do the right thing
flackr: What would a UA style sheet rule setting this look like?
<fantasai> https://www.w3.org/TR/css-text-decor-4/#default-stylesheet
fantasai: current default style sheet rules ^^
<florian> :root:lang(zh), [lang|=zh] { text-emphasis-position: under
right; }
<florian> [lang|=ja], [lang|=ko] { text-emphasis-position: over
right; }
flackr: writing direction doesn't affect this?
fantasai: there are two keywords to set the position
flackr: Thanks. I'm still in favor of option B
<ntim> I'm not objecting, but I can't give a guarantee we can
implement option A anytime soon
RESOLVED: add auto value for text-emphasis-position, and change the
meaning of text-underline-position: auto to care about left
vs right in vertical text
Received on Wednesday, 18 September 2024 23:01:06 UTC