16:07:42 <RRSAgent> RRSAgent has joined #css
16:07:47 <RRSAgent> logging to https://www.w3.org/2026/06/17-css-irc
16:07:47 <ydaniv> fantasai: we updated it, if you have EN as main lang, you want to use the lang of the select
16:07:47 <Zakim> RRSAgent, make logs Public
16:07:48 <Zakim> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
16:07:56 <ydaniv> ... the proposal is to use the flip keyrowd
16:08:10 <vitorroriz> present+
16:08:11 <ydaniv> ... down side we won't have the fallback of these keywords
16:08:33 <ydaniv> ... the main downside is the potential [missed], flipping of margin and paddings etc
16:08:46 <ydaniv> ... this will give better behavior, more like the author wants
16:08:47 <kbabbitt> s/[missed]/compat impact/
16:08:57 <ydaniv> astearns: hopefully this won't have web compat issues?
16:08:59 <ydaniv> fantasai: yes
16:09:11 <ydaniv> fantasai: I think it's the right direction, would like to hear more
16:09:15 <astearns> ack TabAtkins
16:09:24 <ydaniv> TabAtkins: I agree that flip keyword would be better, not sure about compat issues
16:09:30 <ydaniv> ... I think it's the right way
16:09:34 <bramus> +1 on what Tab said
16:09:37 <davidjmarland> +1 for flip. I imagine people would be fighting it at present
16:09:38 <vmpstr> are there use counters?
16:10:18 <ydaniv> jarhar: I tried these yesterday, testing basic cases, seems to work according to old values, one test is failing but maybe not related, support it
16:10:22 <ydaniv> astearns: other comments?
16:10:41 <ydaniv> PROPOSED: change the position try fallbacks for select to what's described in issue
16:10:52 <ydaniv> RESOLVED: change the position try fallbacks for select to what's described in issue
16:11:07 <ydaniv> astearns: any issues on the self keyword we want to use?
16:11:11 <ydaniv> fantasai: I'll file one
16:11:27 <ydaniv> github-bot, take up https://github.com/w3c/csswg-drafts/issues/8549
16:11:27 <github-bot> Topic: [css-scroll-snap-2] Better snap physics and customization?
16:11:27 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/8549
16:12:04 <ydaniv> flackr: for a long time we've had devs had to implement their on touch handling because snap didn't do it just right
16:12:27 <ydaniv> ... I've worked on proposal to narrow to 2 things we want to change according to large portion of issues
16:12:41 <ydaniv> ... 1. how fast it flings near snap point
16:13:12 <ydaniv> ... 2. how strong snap points attract scroll
16:13:36 <ydaniv> ... I've outlined a set of values that will let you implement 3 of major issues, including issues from devs
16:13:43 <astearns> q+
16:13:45 <ydaniv> ...  would like to proceed with specifying
16:14:29 <ydaniv> astearns: have not read it all yet... the combination of these work for 3 main problems, could we have one property instead of 2?
16:14:43 <smfr> q+
16:14:50 <astearns> ack astearns
16:14:50 <TabAtkins> q+
16:15:00 <ydaniv> flackr: 1 property is about how it flings next to a stop, and to me it feels differently of how strong it holds scroll near snap point
16:15:18 <ydaniv> ... existing scroll-snap-stop feels like a strength, feels like we could change it
16:15:46 <ydaniv> astearns: feels like, if it's a pair of things where one is the push and other is the pull, perhaps these should have a single relationship?
16:16:24 <astearns> ack smfr
16:16:26 <ydaniv> flackr: in both I have length as a possibility, if we want to be cuatous we could specify arbitrary [missed]
16:17:03 <ydaniv> smfr: I imagine you have some marh given a decimation point and destianation, you'd have the math to compute that?
16:17:32 <kbabbitt> s/specify arbitrary [missed]/specify just keywords and not arbitrary lengths/
16:17:39 <ydaniv> flackr: 2 benefits to length, 1. it has specific meaning to proximity; 2. is added value of actively attrarcting when you're near the point
16:17:49 <ydaniv> smfr: so that length is sort of influence?
16:17:52 <ydaniv> flackr: yes
16:17:57 <bramus> q+
16:18:01 <ydaniv> q+
16:18:35 <ydaniv> flackr: there is a specific proposal in the issue about the math. You take the length on both sides and according to values make some snapping decision
16:18:49 <astearns> ack TabAtkins
16:19:08 <ydaniv> TabAtkins: questions of smfr answered my questions.
16:19:23 <ydaniv> ... [missed question]
16:19:37 <sgill> sgill has joined #css
16:19:43 <sgill> present+
16:19:45 <ydaniv> flackr: when we start fling, you have to drag beyond that point
16:19:54 <smfr> q+
16:19:56 <astearns> s/[missed question]/what is before?
16:19:59 <ydaniv> TabAtkins: so there's no going beyond that point?
16:20:01 <ydaniv> flackr: yes
16:20:33 <astearns> ack bramus
16:20:35 <ydaniv> TabAtkins: still satisfies my concerns so not arbitrary overriding OS setttings, so in favor
16:21:00 <ydaniv> bramus: just to confirm use-cases, like carousel you want to fling, and only then it passes, this solves it
16:21:06 <astearns> ack ydaniv
16:21:16 <emilio> ydaniv: a though about what astearns suggested
16:21:28 <emilio> ... maybe this could be two snap props or a single physics-related shorthand?
16:21:32 <emilio> ... just a thought
16:21:47 <astearns> q+
16:21:54 <ydaniv> flackr: yeah we could define later if we think about one
16:21:58 <ydaniv> ... it's possible
16:22:06 <astearns> ack smfr
16:22:12 <ydaniv> smfr: want to remind that needs to work well with clicky wheels etc.
16:22:31 <ydaniv> flackr: yes, the intention is this can gracefully fallback to scrolling methods that don't have momentum
16:22:38 <ydaniv> smfr: like arrow keys?
16:22:41 <ydaniv> flackr: yep
16:22:52 <ydaniv> ... would not have effect on arrow key nav
16:22:55 <astearns> ack astearns
16:23:17 <ydaniv> astearns: aside from the case where the lengths don't line up and you have to choose, are there combinations that aren't sensible
16:23:38 <ydaniv> flackr: not aware of any. designed these to be orthogonal
16:23:45 <ydaniv> ... should work separately
16:23:51 <ydaniv> astearns: other comments/questions?
16:24:00 <ydaniv> fantasai: still going over it
16:24:11 <ydaniv> ... before keyword looks not clear to me
16:24:22 <ydaniv> astearns: would you need more time? or can we resolve for now?
16:24:26 <vitorroriz> vitorroriz has joined #css
16:24:29 <ydaniv> fantasai: defer to smfr
16:24:41 <ydaniv> smfr: I think it's ok as a starting point
16:25:10 <ydaniv> astearns: we could resolve on the proposal as it is, and if anyone is concerned about the charataristics of the length we could raise later
16:25:20 <ydaniv> ...  would be happy to resolve for now
16:25:33 <ydaniv> PROPOSED: accept the proposal in last comment of issue
16:25:38 <ydaniv> astearns: objectsions?
16:25:46 <ydaniv> RESOLVED: accept the proposal in last comment of issue
16:26:09 <ydaniv> fantasai: one concern, if author is tuning the length this should work cross-platform
16:26:53 <ydaniv> ... another thing is relationship of scrolling behavior of size of items you wanted to scroll ... is that gonna give us the robustness we want?
16:27:21 <ydaniv> fantasai: I'd be against the resolved size of the item
16:27:25 <bramus> or a `normal` keyword?
16:27:50 <ydaniv> flackr: for the 1st point it won't be the issue, every browser agree that for some position you find the nearest snap point
16:28:08 <ydaniv> ... would be consistent acrross browsers
16:28:20 <fantasai> SUMMARY: Follow up points: a) bikeshedding b) sizing relative to items
16:28:21 <ydaniv> github-bot, take up https://github.com/w3c/csswg-drafts/issues/13767
16:28:21 <github-bot> Topic: [css-link-params] What's the point of ommitting the value?
16:28:21 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/13767
16:29:04 <ydaniv> emilio: I wasn't sure the point on having empty link params
16:29:23 <ydaniv> ... TabAtkins commented it's technically different and will cause the env to fallback
16:29:46 <ydaniv> TabAtkins: passing an empty param explicitly, it's to define an empty var to be replaced with nothing, it's allowed
16:30:00 <ydaniv> ... the param function is defined to work gramatically same to var()
16:30:14 <lea> Note that in var() we have whitespace values (which don't trigger fallback) and actual empty values (which do). Both are useful
16:30:34 <ydaniv> ... because it's optional, like var() I don't feel strongly about making it, you would specify it to get a fallback
16:30:51 <ydaniv> ... I'm fine with removing the explicit empty
16:31:01 <ydaniv> emilio: that would be generally less confusing
16:31:04 <kizu> +1 for it to be always 2-param
16:31:10 <TabAtkins> param(--foo) vs param(--foo,)
16:31:21 <ydaniv> ... if we come up with some other semantics we can add in future
16:31:24 <ydaniv> TabAtkins: yep
16:31:31 <ydaniv> astearns: seeing +1's
16:31:40 <ydaniv> astearns: lea with concerns
16:31:58 <ydaniv> TabAtkins: I think lea's comment is not relevant in this context
16:32:02 <lea> no strong opinion, just adding context :)
16:32:17 <ydaniv> ... in this context using a , means nothing,
16:32:19 <kbabbitt> we would still be able to distinguish between param(--foo,) and param(--foo, ) [without space vs with space]
16:32:42 <ydaniv> ... there's no good reason here to provide this extra flexibility
16:32:58 <TabAtkins> Yes to kbabbitt, those are different values (but both valid)
16:33:09 <ydaniv> PROPOSED: there is no point, we will require 2 values
16:33:13 <ydaniv> astearns: objections?
16:33:28 <ydaniv> RESOLVED: require at least 2 values in the param function
16:33:42 <ydaniv> github-bot, take up https://github.com/w3c/csswg-drafts/issues/9623
16:33:42 <github-bot> Topic: [css-logical] Add `block-start` and `block-end` to `caption-side`
16:33:42 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/9623
16:34:47 <ydaniv> oriol: if caption side prop in CSS2 it had to and bottom keywords, some impls had left and right
16:35:03 <ydaniv> ...  top and bottom were refined to use logic
16:35:24 <ydaniv> ... and line-left and line-right to use logic as well
16:35:35 <ydaniv> ... Sebastian suggested [missed]
16:36:19 <ydaniv> ... situation is inconsistent with flow-relative, so we could define top/bottom to line-above and line-under and provide different keywrods for flow relative
16:37:05 <ydaniv> ... I'm fine with not doing what I proposed, we could add block-start and block-end as aliases, or keep as is, which will not behave as physical but in flow-relative
16:37:18 <TabAtkins> (I'm a little confused about the use-case for caption-side's left/right being line-relative anyway.)
16:37:20 <ydaniv> fantasai: I'm in favor to adding the aliases, which would be more consistent
16:37:25 <TabAtkins> (Is this about inline-table?)
16:37:28 <romain> +1 to adding the aliases
16:37:35 <ydaniv> ... maybe in the future we could do something more interesting
16:37:38 <TabAtkins> +1 to block-start/end tho
16:38:22 <kurt> Should this apply to the other properties in https://drafts.csswg.org/css-logical (e.g. https://drafts.csswg.org/css-logical/#float-clear)?
16:38:22 <ydaniv> fantasai: the left and right alignment and the start left/right text begins is the line-left side, so it would be line-relative, since top/bottom are line-relative
16:38:33 <fantasai> s/line-relative/logical
16:38:36 <ydaniv> ... perhaps if physical to begin with would work to make it physical
16:38:48 <fantasai> s/physical to/we had all 4 directions to/
16:39:19 <TabAtkins> (ohhhhhh right i forgot what exactly line-relative meant. writing-mode responsive, just left/right in some way in the inline axis)
16:39:30 <ydaniv> fantasai: currently only top/bottom supported, we had to make them logical/physical
16:40:20 <ydaniv> fantasai: float don't have these issues since these are line-relative
16:41:11 <ydaniv> astearns: so not aliases, but equivelant keywords?
16:41:13 <ydaniv> fantasai: yes
16:41:29 <ydaniv> fantasai: maybe we'll find there's not enough content...
16:41:42 <ydaniv> oriol: so they compute to how much...
16:41:54 <ydaniv> fantasai: they're independent
16:42:21 <ydaniv> PROPOSED: add the block-start and block-end to the caption-side property and to behave as top and bottom respectively
16:42:27 <ydaniv> astearns: objections?
16:42:38 <ydaniv> RESOLVED: add the block-start and block-end to the caption-side property and to behave as top and bottom respectively
16:42:55 <ydaniv> github-bot, take up https://github.com/w3c/csswg-drafts/pull/10270
16:42:56 <github-bot> Topic: [css-spec-viewport-1] updated the values for zoom property
16:42:56 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/pull/10270
16:43:24 <alisonmaher4> alisonmaher4 has joined #css
16:43:29 <ydaniv> emilio: I think it's fine to add normal, I think it resolves to number
16:43:32 <sgill> sgill has joined #css
16:43:56 <ydaniv> emilio: checking browser behavior with normal
16:44:23 <ydaniv> ... I think at some point Safari supported it with effectively reset with keyword but not anymore
16:44:29 <ydaniv> ... so normal seems fine
16:44:35 <ydaniv> astearns: normal computing to 1?
16:44:43 <schenney> q+
16:44:49 <ydaniv> emilio: to what's interoperable but 1 otherwise is fine
16:44:57 <schenney> q-
16:45:06 <ydaniv> ... it turns into a 1 in parse time
16:45:14 <ydaniv> fantasai: I think it's weird
16:45:22 <TabAtkins> zoom is the gift that keeps on giving
16:45:23 <ydaniv> emilio: I know but not the first
16:45:27 <TabAtkins> (it's giving *trash*)
16:45:36 <ydaniv> fantasai: I think we should compute to 1 if that's the case
16:45:50 <ydaniv> emilio: the 0 thing is required
16:46:07 <ydaniv> astearns: so we can resolve compute to 1 unless we see we have compat issue?
16:46:32 <ntim> ntim has joined #css
16:46:38 <ydaniv> ... can we resolve on a normal and have it compute to 1 and have you look if needs adjustment?
16:46:51 <ydaniv> emilio: we do keep it as keyword and compute to 1
16:46:56 <ydaniv> ... seems fine
16:47:01 <fantasai> PROPOSED: Add zoom: normal, computing to 1
16:47:20 <ydaniv> astearns: objections?
16:47:22 <kbabbitt> kbabbitt: looks like Blink does the same thing, normal keyword computes to 1
16:47:30 <ydaniv> RESOLVED: Add zoom: normal, computing to 1
16:47:48 <ydaniv> github-bot, take up https://github.com/w3c/csswg-drafts/issues/13673
16:47:48 <github-bot> Topic: [css-scroll-snap-1][interop-2026] Clarify how to handle the snap target having the focused element
16:47:48 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/13673
16:48:15 <TabAtkins> agree, seems uncontroversial to me, +1
16:48:28 <ydaniv> emilio: the selecting between multiple lines snap areas,
16:48:38 <fantasai> +1
16:48:43 <flackr> +1
16:49:21 <smfr> "focused element"
16:49:27 <dholbert> dholbert has joined #css
16:49:59 <dholbert> present+
16:50:02 <JohnJansen> I'm very impressed by your English.
16:50:04 <JohnJansen> present+
16:50:14 <ydaniv> ... the spec says remove the focused element, and instead check nested snap areas etc
16:50:28 <flackr> q+
16:50:35 <ydaniv> ... the proposal is to change spec to say if it contains a box that's focused or it's decendants
16:50:40 <Psychpsyo_Cameron> (What is "present+"?)
16:50:45 <astearns> ack flackr
16:51:07 <flackr> https://github.com/w3c/csswg-drafts/issues/9917
16:51:14 <ydaniv> flackr: I completely agree this is the intent, would happy to change, threre's a related issue we agreed on
16:51:15 <Psychpsyo_Cameron> present+
16:51:37 <ydaniv> flackr: support of updating the algo to make that the case
16:51:56 <ydaniv> astearns: concerns?
16:52:19 <ydaniv> fantasai: I need details, looking at spec there's stuff about focused box and targeted box, we do on both?
16:52:20 <ydaniv> flackr: yes
16:52:37 <ydaniv> fantasai: another thing in spec, if we have both, do we have prioritization?
16:52:46 <ydaniv> TabAtkins: scroll snaps are always siblings, no?
16:52:49 <ydaniv> fantasai: no
16:52:56 <ydaniv> emilio: probably by distance
16:52:58 <TabAtkins> oh right, i'm being silly
16:52:58 <Joanne> Joanne has joined #css
16:53:07 <Joanne> present+
16:53:18 <ydaniv> fantasai: so probably focused or targeted and prioritize on nearest, and clarify that
16:53:31 <ydaniv> flackr: I think you want nearest the specifies a target
16:53:48 <ydaniv> fantasai: has to be in the list
16:53:48 <smfr> q+
16:53:52 <ydaniv> flackr: yes
16:53:59 <astearns> ack smfr
16:54:11 <astearns> ack fantasai
16:54:11 <Zakim> fantasai, you wanted to ask about target
16:54:17 <ydaniv> smfr: about the issue flackr listed, is that going to be an issue in interop?
16:54:32 <ydaniv> flackr: don't know
16:54:44 <ydaniv> emilio: current issue is covered by interop
16:55:03 <ydaniv> ... I don't think the other one is scoped by the Interop26 tests, need to check again
16:55:15 <ydaniv> ... unless it changes probably answer is no
16:55:43 <ydaniv> astearns: so nees test vetting as well as tests needed
16:56:38 <ydaniv> astearns: so we'll change tests and ask Interop folks, who can summarize?
16:57:03 <fantasai>      1. Let |inline| be the set of boxes whose [=scroll snap areas=] are aligned at this |scroll position| in the inline axis.
16:57:06 <fantasai>      1. Let |block| be the set of boxes whose [=scroll snap areas=] are aligned at this |scroll position| in the block axis.
16:57:09 <fantasai>      1. For each |list| of |block| and |inline|:
16:57:11 <fantasai> -        1. If |list| contains the focused box, remove all other boxes from |list|.
16:57:14 <fantasai> -        1. If |list| contains the targeted box, remove all other boxes from |list|.
16:57:17 <fantasai> +        1. If |list| contains a focused box,
16:57:20 <fantasai> +            remove all other boxes from |list|.
16:57:22 <fantasai> +            Otherwise if it contains a box that contains a focused box,
16:57:25 <fantasai> +            remove all but that which is its closest ancestor.
16:57:27 <fantasai> +        1. If |list| contains a targetted box,
16:57:30 <fantasai> +            remove all other boxes from |list|.
16:57:32 <fantasai> +            Otherwise if it contains a box that contains a targetted box,
16:57:35 <fantasai> +            remove all but that which is its closest ancestor.
16:57:37 <fantasai>          1. For each |box| in |list|:
16:57:40 <fantasai>              1. Remove any box from |list| which is an ancestor of |box|.
16:57:42 <fantasai>      1. If |inline| and |block| are overlapping sets:
16:57:45 <fantasai> ...
16:57:55 <ydaniv> astearns: I think fantasai argued against algos in spec, but looks like an algo
16:58:06 <ydaniv> fantasai: yes but that's what's currently there, in some cases we need them
16:58:26 <DavidA> DavidA has joined #css
16:58:30 <schenney> schenney has joined #css
16:58:34 <ydaniv> astearns: more comments?
16:58:57 <ydaniv> emilio: to we want to prioritize targeted or focused?
16:59:08 <dholbert_> dholbert_ has joined #css
16:59:22 <ydaniv> fantasai: focused
17:00:03 <ydaniv> PROPOSED: apply the suggested diff
17:00:24 <ydaniv> emilio: might be simpler to do priority sorting, but otherwise fine
17:00:35 <ydaniv> astearns: objections?
17:00:56 <ydaniv> RESOLVED: addd the equivelant to the suggested diff
17:01:14 <astearns> zakim, end meeting
17:01:14 <Zakim> As of this point the attendees have been emeyer, vitorroriz, sgill, dholbert, JohnJansen, Psychpsyo_Cameron, Joanne
17:01:16 <Zakim> RRSAgent, please draft minutes v2
17:01:18 <RRSAgent> I have made the request to generate https://www.w3.org/2026/06/17-css-minutes.html Zakim
17:01:25 <Zakim> I am happy to have been of service, astearns; please remember to excuse RRSAgent.  Goodbye
17:01:25 <Zakim> Zakim has left #css
17:03:11 <dholbert__> dholbert__ has joined #css
17:05:11 <fantasai> emilio, TabAtkins - alternative diff
17:05:20 <fantasai> diff --git a/css-scroll-snap-1/Overview.bs b/css-scroll-snap-1/Overview.bs
17:05:20 <fantasai> index ed31955e9..97662e9a6 100644
17:05:20 <fantasai> --- a/css-scroll-snap-1/Overview.bs
17:05:20 <fantasai> +++ b/css-scroll-snap-1/Overview.bs
17:05:20 <fantasai> @@ -1146,8 +1146,12 @@ Choosing Snap Positions {#choosing}
17:05:23 <fantasai>      1. Let |inline| be the set of boxes whose [=scroll snap areas=] are aligned at this |scroll position| in the inline axis.
17:05:26 <fantasai>      1. Let |block| be the set of boxes whose [=scroll snap areas=] are aligned at this |scroll position| in the block axis.
17:05:29 <fantasai>      1. For each |list| of |block| and |inline|:
17:05:31 <fantasai> -        1. If |list| contains the focused box, remove all other boxes from |list|.
17:05:34 <fantasai> -        1. If |list| contains the targeted box, remove all other boxes from |list|.
17:05:37 <fantasai> +        1. If |list| contains one or more boxes
17:05:39 <fantasai> +            that are focused or have a focused descendant,
17:05:42 <fantasai> +            remove all other boxes from |list|
17:05:44 <fantasai> +        1. Else if |list| contains one or more boxes
17:05:47 <fantasai> +            that are targetted or have a targetted descendant,
17:05:49 <fantasai> +            remove all other boxes from |list|.
17:05:52 <fantasai>          1. For each |box| in |list|:
17:05:54 <fantasai>              1. Remove any box from |list| which is an ancestor of |box|.
17:05:57 <fantasai>      1. If |inline| and |block| are overlapping sets:
17:06:37 <dholbert__> dholbert__ has joined #css
17:09:39 <dholbert_> dholbert_ has joined #css
17:11:32 <fantasai> Made a PR: https://github.com/w3c/csswg-drafts/pull/14064/changes emilio / TabAtkins feel free to merge if it looks good
17:16:39 <a> a has joined #css
17:16:58 <a> a has left #css
17:25:00 <emilio> fantasai: lgtm!