– DRAFT –
Cascading Style Sheets (CSS) Working Group Teleconference

<TabAtkins> Can't scribe for the first few

github-bot, take up w3c/csswg-drafts#10526

[css-anchor-position] When does anchor-scope "match" a name?

<github-bot> OK, I'll post this discussion to 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)

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)

github-bot, take up w3c/csswg-drafts#10525

[css-anchor-position] anchor-scope and part descendant styling

<github-bot> OK, I'll post this discussion to 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

RESOLUTION: the 'all' keyword is tree-scoped

github-bot, take up w3c/csswg-drafts#10774

[css-scroll-snap-2] How should competing scroll-start-targets be resolved?

<github-bot> OK, I'll post this discussion to 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

RESOLUTION: 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

github-bot, take up w3c/csswg-drafts#1198

[css-text-decor] text-underline-position auto in vertical text

<github-bot> OK, I'll post this discussion to 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 flippinng

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> https://drafts.csswg.org/css-text-decor-3/#default-stylesheet

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://www.w3.org/TR/css-text-decor-4/#text-emphasis-position-property

fantasai: propose that we keep the spec as-is

<fantasai> https://www.w3.org/TR/css-text-decor-4/#text-underline-position-property

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/ (in jfkthame's minutes above) 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: option a: keep spec as-is, update gecko & chromium to match. option b: change spec, change webkit to match.

<fantasai> B) Introduce auto to text-emphasis-position and use it in both text-emphasis-position and text-underline-position to effect language switches

<ntim> Option b requires changing text-emphasis-position in all browsers too

<fantasai> C) Adopt inconsistent behavior: text-underline-position uses 'auto' and text-emphasis-position uses UA stylesheet

<TabAtkins> abstain, no opinion

<emilio> B

<fantasai> POLL: A, B, or C?

<vmpstr> abstain

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

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

End