15:53:14 <RRSAgent> RRSAgent has joined #css
15:53:18 <RRSAgent> logging to https://www.w3.org/2024/09/18-css-irc
15:53:18 <Zakim> RRSAgent, make logs Public
15:53:19 <Zakim> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
15:56:25 <PaulG> PaulG has joined #css
16:00:25 <DavidA> DavidA has joined #css
16:00:28 <kizu> kizu has joined #css
16:00:59 <flackr> flackr has joined #css
16:01:03 <flackr> present+
16:01:29 <schenney> schenney has joined #css
16:01:34 <schenney> present+
16:01:38 <khush> khush has joined #css
16:01:48 <kbabbitt> kbabbitt has joined #css
16:01:52 <kbabbitt> present+
16:01:56 <khush> present+
16:02:05 <Rossen3> present+
16:02:32 <dholbert> dholbert has joined #css
16:02:43 <TabAtkins> Can't scribe for the first few
16:02:44 <andruud> andruud has joined #css
16:02:53 <andruud> present+
16:02:59 <rachelandrew> present+
16:03:23 <argyle> present+
16:03:29 <ydaniv> ydaniv has joined #css
16:03:38 <chrishtr> present+
16:03:47 <ydaniv> present+
16:03:58 <oriol> present+
16:04:03 <jfkthame> jfkthame has joined #css
16:04:54 <dholbert> present+
16:05:00 <jfkthame> present+
16:05:03 <chrishtr> github-bot, take up https://github.com/w3c/csswg-drafts/issues/10526
16:05:04 <github-bot> Topic: [css-anchor-position] When does anchor-scope "match" a name?
16:05:04 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10526.
16:05:25 <miriam> present+
16:05:28 <emeyer> emeyer has joined #css
16:05:32 <kizu> present+
16:05:53 <emeyer> present+
16:05:56 <bradk> bradk has joined #css
16:06:18 <chrishtr> tabatkins: in anchor positioning, anchor names and references are tree scoped
16:06:28 <bradk> present+
16:06:31 <chrishtr> tabatkins: the anchor-scope property that scopes, does not say whether the names are tree scoped or not
16:06:36 <emilio> present+
16:06:41 <chrishtr> tabatkins: question to decide: should they be?
16:06:47 <chrishtr> tabatkins: I think the answer should be yes
16:06:52 <alisonmaher> alisonmaher has joined #css
16:06:58 <alisonmaher> present+
16:07:34 <chrishtr> tabatkins: if you have an anchor in a shadow tree with a part involved, then problems result
16:07:57 <chrishtr> tabatkins: if anchor scopes are not tree scoped
16:08:06 <chrishtr> tabatkins: this is bad, so I think it should be tree scoped
16:08:06 <khush> sounds pretty reasonable
16:08:07 <dbaron> Present+
16:08:09 <Rossen3> q?
16:08:10 <andruud> q+
16:08:16 <fantasai> makes sense to me as far as I can understand it :)
16:08:20 <Rossen3> ack andruud
16:08:34 <chrishtr> andruud: is this the first time we have a tree scoped name on both sides of a comparison, without one being a reference?
16:08:38 <chrishtr> tabatkins: I believe yes
16:08:48 <chrishtr> andruud: should we make a more general design statement then?
16:08:54 <chrishtr> tabatkins: yes I think we should
16:09:22 <chrishtr> andruud: would be good to resolve on that
16:09:36 <chrishtr> tabatkins: I'm good with a broader resolution to set a precedent
16:10:06 <chrishtr> andruud: what about references vs names?
16:10:12 <chrishtr> tabatkins: yeah those are different
16:10:37 <khush> q+
16:11:05 <fantasai> agree that name-matching should probably be tree-scoped
16:11:10 <chrishtr> rossen: it matches the exact match of the ident and tree scope, is that what you were referring to in option 2?
16:11:13 <chrishtr> andruud: yes
16:11:14 <Rossen3> ack khush
16:11:35 <chrishtr> 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
16:12:03 <chrishtr> khush: there is another view transitions feature where I'm not sure if the spec says it's tree scoped
16:12:18 <chrishtr> khush: want to make sure that feature is covered by the more general resolution
16:12:49 <chrishtr> 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)
16:13:02 <noamr> noamr has joined #css
16:13:17 <chrishtr> 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)
16:13:40 <chrishtr> github-bot, take up https://github.com/w3c/csswg-drafts/issues/10525
16:13:40 <github-bot> Topic: [css-anchor-position] anchor-scope and part descendant styling
16:13:40 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10525.
16:14:16 <chrishtr> 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
16:14:33 <chrishtr> tabatkins: proposed resolution: the 'all' keyword is also tree-scoped in the same way
16:14:34 <fantasai> sgtm
16:14:40 <khush> +1, again same pattern with view-transition-group
16:14:45 <chrishtr> RESOLVED: the 'all' keyword is tree-scoped
16:15:01 <chrishtr> github-bot, take up https://github.com/w3c/csswg-drafts/issues/10774
16:15:01 <github-bot> Topic: [css-scroll-snap-2] How should competing scroll-start-targets be resolved?
16:15:01 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10774.
16:16:02 <chrishtr> 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
16:16:18 <chrishtr> DavidA: question is what happens if there are multiple targets
16:16:52 <chrishtr> DavidA: propose to do it in reverse-DOM order,
16:17:04 <chrishtr> DavidA: this would result in the first one applied last and then be on screen
16:17:26 <chrishtr> DavidA: also, should only change the scroll position if you have to
16:17:29 <Rossen3> ack fantasai
16:17:46 <chrishtr> fantasai: several questions. first: why do we need to add a new property rather than re-using scroll-snap-align?
16:18:09 <chrishtr> flackr: setting the scroll alignment for items that don't necessarily become snaps
16:18:25 <chrishtr> flackr: scroll-snap-align would also force the developer to set scroll snap areas
16:18:47 <chrishtr> fantasai: in that case, should there be a relationship between the two properties?
16:18:53 <chrishtr> fantasai: might want to do both behaviors
16:19:08 <chrishtr> flackr: I agree the properties should be strongly linked, possibly with a shorthanding relationship
16:19:22 <chrishtr> fantasai: suggest thinking about this more on the issue
16:19:37 <chrishtr> fantasai: so that we can figure out how the two properties interact
16:19:53 <chrishtr> fantasai: there was a bunch of discussion about regular vs reverse-DOM order. where did we end up and why?
16:20:33 <chrishtr> 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.
16:21:03 <chrishtr> flackr: there is also the issue of nearest...
16:21:13 <chrishtr> fantasai: can you explain nearest?
16:21:20 <chrishtr> flackr: same as scroll into view
16:21:26 <chrishtr> fantasai: ?
16:21:53 <chrishtr> flackr: this is needed with you scroll multiple things into view and want to find a good position (?)
16:22:19 <chrishtr> 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?
16:22:23 <chrishtr> flackr: yes absolutely
16:22:31 <chrishtr> fantasai: otherwise it seems to make sense
16:23:00 <chrishtr> fantasai: have questions in general about the feature but not this issue
16:23:21 <chrishtr> flackr: seems we can resolve that the general thing is good?
16:24:38 <flackr> Proposed resolution: Add scroll-align property to specify scroll alignment without adding a snap area - details TBD
16:25:43 <chrishtr> fantasai: would like to see the interaction with snapping
16:25:56 <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
16:26:09 <emeyer> emeyer has left #css
16:26:30 <chrishtr> rossen: we'll postpone the first resolution until we have more details
16:26:49 <chrishtr> RESOLVED: When scroll-start-target targets multiple elements, scroll to each in reverse DOM order with text to specify priority is the first item
16:27:10 <chrishtr> flackr: third thing: having a nearest align value
16:27:19 <chrishtr> flackr: not sure if we can resolve without details for resolution #1
16:28:15 <chrishtr> rossen: maybe we should wait for more details
16:28:28 <chrishtr> fantasai: suggest a separate issue be filed about the nearest issue
16:28:46 <chrishtr> fantasai: agree we should do something in that direction, just need to figure out all the details
16:29:06 <chrishtr> github-bot, take up https://github.com/w3c/csswg-drafts/issues/1198
16:29:06 <github-bot> Topic: [css-text-decor] text-underline-position auto in vertical text
16:29:06 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/1198.
16:30:25 <chrishtr> 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
16:30:49 <chrishtr> fantasai: auto value is defined in the spec about 'how far down below the text', but doesn't say things about flippinng
16:31:05 <chrishtr> fantasai: the current spec says "at or below"
16:31:37 <chrishtr> 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
16:31:44 <fantasai> https://drafts.csswg.org/css-text-decor-3/#default-stylesheet
16:32:02 <chrishtr> fantasai: a couple of implementations do this
16:32:25 <chrishtr> fantasai: should we change the spec to mention these things?
16:32:43 <chrishtr> fantasai: or should we stick with the UA stylesheet approach?
16:32:55 <fantasai> https://www.w3.org/TR/css-text-decor-4/#text-emphasis-position-property
16:32:56 <chrishtr> fantasai: propose that we keep the spec as-is
16:33:06 <fantasai> https://www.w3.org/TR/css-text-decor-4/#text-underline-position-property
16:33:16 <Rossen3> q?
16:33:31 <chrishtr> fantasai: this would require some implementations to change though
16:33:38 <chrishtr> chrishtr: which implementations would need to change?
16:34:04 <chrishtr> fantasai: chrome and firefox are language-sensitive for auto, and webkit uses the default UA style sheet
16:34:16 <chrishtr> rossen: does this mean that webkit needs to change?
16:34:28 <chrishtr> florian: other way around, it would mean chrome and firefox need to change?
16:35:10 <chrishtr> florian: since the two approaches both exist it seems going either way would be web compatible
16:35:19 <emilio> q+
16:35:22 <chrishtr> rossen: sounds like a low-ROI change
16:35:32 <chrishtr> rossen: is it a problem in practice?
16:35:33 <Rossen3> ack emilio
16:35:44 <chrishtr> emilio: I think we should try to go for the firefox/chrome approach
16:36:08 <chrishtr> emilio: avoids weird styles change in ways that developers might not expect
16:36:18 <chrishtr> emilio: we had the same problem with quotes if I'm remembering correctly
16:36:38 <chrishtr> fantasai: that was the first time we had a language-aware value
16:37:07 <chrishtr> emilio: reusing that mechanism for this makes sense, but don't have a strong opinion
16:37:44 <chrishtr> fantasai: if there is a strong need for these things they we could introduce auto keywords for other things, otherwise UA stylesheet for this case?
16:38:46 <chrishtr> jfkthame: text decoration skip ink does something also, seems to me auto is the cleanest approach
16:38:50 <fantasai> s/other things/text-emphasis-position/
16:38:54 <ntim> ntim has joined #css
16:39:16 <florian> s/and firefox need to change?/and firefox need to change if we keep the spec unchanged?
16:40:17 <chrishtr> 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
16:40:28 <chrishtr> chrishtr: is that true for all browsers?
16:40:34 <chrishtr> fantasai: yes, because there is no auto keyword
16:40:36 <dholbert> s/does something/does something language-specific/ (in jfkthame's minutes above)
16:40:58 <chrishtr> jfkthame: it would make sense to me to add auto to that property also
16:41:07 <chrishtr> florian: that would be a change in all browsers
16:41:16 <chrishtr> jfkthame: yes but that could be an improvement
16:41:42 <chrishtr> ntim: is it a common use case to use the auto value to override a non-default value?
16:41:59 <chrishtr> ntim: if not, then the UA style sheet does the job just fine
16:42:24 <chrishtr> 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
16:43:36 <chrishtr> 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.
16:45:01 <fantasai> A) Keep spec as-is, update Gecko + Blink to match (using UA stylesheet for language switch)
16:45:04 <chrishtr> fantasai: option a: keep spec as-is, update gecko & chromium to match. option b: change spec, change webkit to match.
16:45:28 <fantasai> B) Introduce to text-emphasis-position and use it in both text-emphasis-position and text-underline-position to effect language switches
16:45:37 <ntim> Option b requires changing text-emphasis-position in all browsers too
16:45:50 <fantasai> s/Introduce/Introduce auto/
16:46:09 <ydaniv> ydaniv has joined #css
16:46:30 <fantasai> C) Adopt inconsistent behavior: text-underline-position uses 'auto' and text-emphasis-position uses UA stylesheet
16:47:30 <ntim> present+
16:47:31 <TabAtkins> abstain, no opinion
16:47:33 <emilio> B
16:47:33 <fantasai> POLL: A, B, or C?
16:47:43 <vmpstr> abstain
16:47:44 <chrishtr> B
16:47:49 <jfkthame> B, A, C
16:47:53 <astearns> abstain
16:47:57 <ntim> A, B, C
16:47:59 <fantasai> A, B, C
16:48:00 <ydaniv> abstain
16:48:03 <miriam> abstain
16:48:05 <florian> indifferent between A and B, dislike of C
16:48:07 <dholbert> B, A, C
16:48:08 <schenney> B, A, C
16:48:09 <dbaron> neutral on A vs B, prefer them to C
16:48:20 <oriol> abstain
16:48:20 <rachelandrew> abstain, no strong opinion
16:48:25 <DavidA> abstain
16:48:30 <kizu> abstain
16:48:32 <kbabbitt> abstain
16:49:17 <flackr> abstain
16:53:16 <chrishtr> 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
16:53:36 <florian> wfm
16:54:58 <chrishtr> 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
16:55:07 <emilio> q+
16:55:11 <flackr> q+
16:55:28 <chrishtr> emilio: you have the opposite argument with making initial do the right thing, right?
16:55:38 <chrishtr> emilio: there are arguments in both directions in this dimension
16:55:55 <Rossen3> ack emilio
16:56:04 <chrishtr> emilio: being able to set something reasonable via resets in the style sheet, I mean
16:56:19 <chrishtr> emilio: would expect the initial value to do the right thing - resetting gets rid of UA style sshets
16:56:26 <chrishtr> s/sshets/sheets/
16:56:37 <moonira> moonira has joined #css
16:56:44 <chrishtr> jftkhame: does seem an auto keyword should do the right thing
16:56:53 <Rossen3> ack flackr
16:56:57 <chrishtr> flackr: what would a UA style sheet rule setting this look like?
16:57:05 <fantasai> https://www.w3.org/TR/css-text-decor-4/#default-stylesheet
16:57:17 <chrishtr> fantasai: current default style sheet rules ^^
16:57:20 <florian> :root:lang(zh), [lang|=zh] { text-emphasis-position: under right; }
16:57:20 <florian> [lang|=ja], [lang|=ko]     { text-emphasis-position: over right; }
16:57:37 <chrishtr> flackr: writing direction doesn't affect this?
16:57:46 <chrishtr> fantasai: there are two keywords to set the position
16:58:29 <chrishtr> flackr: Thanks. I'm still in favor of option B
17:00:27 <ntim> I'm not objecting, but I can't give a guarantee we can implement option A anytime soon
17:00:32 <chrishtr> 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
17:01:07 <fantasai> Topic: End
17:01:27 <Zakim> As of this point the attendees have been flackr, schenney, kbabbitt, khush, Rossen, andruud, rachelandrew, argyle, chrishtr, ydaniv, oriol, dholbert, jfkthame, miriam, kizu,
17:01:30 <Zakim> ... emeyer, bradk, emilio, alisonmaher, dbaron, ntim
17:01:30 <Zakim> RRSAgent, please draft minutes v2
17:01:31 <RRSAgent> I have made the request to generate https://www.w3.org/2024/09/18-css-minutes.html Zakim
17:01:38 <Zakim> I am happy to have been of service, fantasai; please remember to excuse RRSAgent.  Goodbye
17:01:38 <Zakim> Zakim has left #css
17:34:15 <dholbert_> dholbert_ has joined #css
19:27:14 <bradk> bradk has joined #css
20:06:02 <jfkthame> jfkthame has joined #css
20:21:28 <jfkthame> jfkthame has joined #css