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

fantasai: we updated it, if you have EN as main lang, you want to use the lang of the select
… the proposal is to use the flip keyrowd
… down side we won't have the fallback of these keywords
… the main downside is the potential compat impact, flipping of margin and paddings etc
… this will give better behavior, more like the author wants

astearns: hopefully this won't have web compat issues?

fantasai: yes

fantasai: I think it's the right direction, would like to hear more

TabAtkins: I agree that flip keyword would be better, not sure about compat issues
… I think it's the right way

<bramus> +1 on what Tab said

<davidjmarland> +1 for flip. I imagine people would be fighting it at present

<vmpstr> are there use counters?

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

astearns: other comments?

PROPOSED: change the position try fallbacks for select to what's described in issue

RESOLUTION: change the position try fallbacks for select to what's described in issue

astearns: any issues on the self keyword we want to use?

fantasai: I'll file one

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

[css-scroll-snap-2] Better snap physics and customization?

<github-bot> OK, I'll post this discussion to w3c/csswg-drafts#8549

flackr: for a long time we've had devs had to implement their on touch handling because snap didn't do it just right
… I've worked on proposal to narrow to 2 things we want to change according to large portion of issues
… 1. how fast it flings near snap point
… 2. how strong snap points attract scroll
… I've outlined a set of values that will let you implement 3 of major issues, including issues from devs
… would like to proceed with specifying

astearns: have not read it all yet... the combination of these work for 3 main problems, could we have one property instead of 2?

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
… existing scroll-snap-stop feels like a strength, feels like we could change it

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?

flackr: in both I have length as a possibility, if we want to be cuatous we could specify just keywords and not arbitrary lengths

smfr: I imagine you have some marh given a decimation point and destianation, you'd have the math to compute that?

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

smfr: so that length is sort of influence?

flackr: yes

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

TabAtkins: questions of smfr answered my questions.
… what is before?

flackr: when we start fling, you have to drag beyond that point

TabAtkins: so there's no going beyond that point?

flackr: yes

TabAtkins: still satisfies my concerns so not arbitrary overriding OS setttings, so in favor

bramus: just to confirm use-cases, like carousel you want to fling, and only then it passes, this solves it

<emilio> ydaniv: a though about what astearns suggested

<emilio> ... maybe this could be two snap props or a single physics-related shorthand?

<emilio> ... just a thought

flackr: yeah we could define later if we think about one
… it's possible

smfr: want to remind that needs to work well with clicky wheels etc.

flackr: yes, the intention is this can gracefully fallback to scrolling methods that don't have momentum

smfr: like arrow keys?

flackr: yep
… would not have effect on arrow key nav

astearns: aside from the case where the lengths don't line up and you have to choose, are there combinations that aren't sensible

flackr: not aware of any. designed these to be orthogonal
… should work separately

astearns: other comments/questions?

fantasai: still going over it
… before keyword looks not clear to me

astearns: would you need more time? or can we resolve for now?

fantasai: defer to smfr

smfr: I think it's ok as a starting point

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
… would be happy to resolve for now

PROPOSED: accept the proposal in last comment of issue

astearns: objectsions?

RESOLUTION: accept the proposal in last comment of issue

fantasai: one concern, if author is tuning the length this should work cross-platform
… another thing is relationship of scrolling behavior of size of items you wanted to scroll ... is that gonna give us the robustness we want?

fantasai: I'd be against the resolved size of the item

<bramus> or a `normal` keyword?

flackr: for the 1st point it won't be the issue, every browser agree that for some position you find the nearest snap point
… would be consistent acrross browsers

<fantasai> SUMMARY: Follow up points: a) bikeshedding b) sizing relative to items

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

[css-link-params] What's the point of ommitting the value?

<github-bot> OK, I'll post this discussion to w3c/csswg-drafts#13767

emilio: I wasn't sure the point on having empty link params
… TabAtkins commented it's technically different and will cause the env to fallback

TabAtkins: passing an empty param explicitly, it's to define an empty var to be replaced with nothing, it's allowed
… the param function is defined to work gramatically same to var()

<lea> Note that in var() we have whitespace values (which don't trigger fallback) and actual empty values (which do). Both are useful

TabAtkins: because it's optional, like var() I don't feel strongly about making it, you would specify it to get a fallback
… I'm fine with removing the explicit empty

emilio: that would be generally less confusing

<kizu> +1 for it to be always 2-param

<TabAtkins> param(--foo) vs param(--foo,)

emilio: if we come up with some other semantics we can add in future

TabAtkins: yep

astearns: seeing +1's

astearns: lea with concerns

TabAtkins: I think lea's comment is not relevant in this context

<lea> no strong opinion, just adding context :)

TabAtkins: in this context using a , means nothing,

<kbabbitt> we would still be able to distinguish between param(--foo,) and param(--foo, ) [without space vs with space]

TabAtkins: there's no good reason here to provide this extra flexibility

<TabAtkins> Yes to kbabbitt, those are different values (but both valid)

PROPOSED: there is no point, we will require 2 values

astearns: objections?

RESOLUTION: require at least 2 values in the param function

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

[css-logical] Add `block-start` and `block-end` to `caption-side`

<github-bot> OK, I'll post this discussion to w3c/csswg-drafts#9623

oriol: if caption side prop in CSS2 it had to and bottom keywords, some impls had left and right
… top and bottom were refined to use logic
… and line-left and line-right to use logic as well
… Sebastian suggested [missed]
… 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
… 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

<TabAtkins> (I'm a little confused about the use-case for caption-side's left/right being line-relative anyway.)

fantasai: I'm in favor to adding the aliases, which would be more consistent

<TabAtkins> (Is this about inline-table?)

<romain> +1 to adding the aliases

fantasai: maybe in the future we could do something more interesting

<TabAtkins> +1 to block-start/end tho

<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)?

fantasai: the left and right alignment and the start left/right text begins is the line-left side, so it would be logical, since top/bottom are line-relative
… perhaps if we had all 4 directions to begin with would work to make it physical

<TabAtkins> (ohhhhhh right i forgot what exactly line-relative meant. writing-mode responsive, just left/right in some way in the inline axis)

fantasai: currently only top/bottom supported, we had to make them logical/physical

fantasai: float don't have these issues since these are line-relative

astearns: so not aliases, but equivelant keywords?

fantasai: yes

fantasai: maybe we'll find there's not enough content...

oriol: so they compute to how much...

fantasai: they're independent

PROPOSED: add the block-start and block-end to the caption-side property and to behave as top and bottom respectively

astearns: objections?

RESOLUTION: add the block-start and block-end to the caption-side property and to behave as top and bottom respectively

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

[css-spec-viewport-1] updated the values for zoom property

<github-bot> OK, I'll post this discussion to w3c/csswg-drafts#10270

emilio: I think it's fine to add normal, I think it resolves to number

emilio: checking browser behavior with normal
… I think at some point Safari supported it with effectively reset with keyword but not anymore
… so normal seems fine

astearns: normal computing to 1?

emilio: to what's interoperable but 1 otherwise is fine
… it turns into a 1 in parse time

fantasai: I think it's weird

<TabAtkins> zoom is the gift that keeps on giving

emilio: I know but not the first

<TabAtkins> (it's giving *trash*)

fantasai: I think we should compute to 1 if that's the case

emilio: the 0 thing is required

astearns: so we can resolve compute to 1 unless we see we have compat issue?
… can we resolve on a normal and have it compute to 1 and have you look if needs adjustment?

emilio: we do keep it as keyword and compute to 1
… seems fine

<fantasai> PROPOSED: Add zoom: normal, computing to 1

astearns: objections?

<kbabbitt> kbabbitt: looks like Blink does the same thing, normal keyword computes to 1

RESOLUTION: Add zoom: normal, computing to 1

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

[css-scroll-snap-1][interop-2026] Clarify how to handle the snap target having the focused element

<github-bot> OK, I'll post this discussion to w3c/csswg-drafts#13673

<TabAtkins> agree, seems uncontroversial to me, +1

emilio: the selecting between multiple lines snap areas,

<fantasai> +1

<flackr> +1

<smfr> "focused element"

<JohnJansen> I'm very impressed by your English.

emilio: the spec says remove the focused element, and instead check nested snap areas etc
… the proposal is to change spec to say if it contains a box that's focused or it's decendants

<Psychpsyo_Cameron> (What is "present+"?)

<flackr> w3c/csswg-drafts#9917

flackr: I completely agree this is the intent, would happy to change, threre's a related issue we agreed on

flackr: support of updating the algo to make that the case

astearns: concerns?

fantasai: I need details, looking at spec there's stuff about focused box and targeted box, we do on both?

flackr: yes

fantasai: another thing in spec, if we have both, do we have prioritization?

TabAtkins: scroll snaps are always siblings, no?

fantasai: no

emilio: probably by distance

<TabAtkins> oh right, i'm being silly

fantasai: so probably focused or targeted and prioritize on nearest, and clarify that

flackr: I think you want nearest the specifies a target

fantasai: has to be in the list

flackr: yes

<Zakim> fantasai, you wanted to ask about target

smfr: about the issue flackr listed, is that going to be an issue in interop?

flackr: don't know

emilio: current issue is covered by interop
… I don't think the other one is scoped by the Interop26 tests, need to check again
… unless it changes probably answer is no

astearns: so nees test vetting as well as tests needed

astearns: so we'll change tests and ask Interop folks, who can summarize?

<fantasai> 1. Let |inline| be the set of boxes whose [=scroll snap areas=] are aligned at this |scroll position| in the inline axis.

<fantasai> 1. Let |block| be the set of boxes whose [=scroll snap areas=] are aligned at this |scroll position| in the block axis.

<fantasai> 1. For each |list| of |block| and |inline|:

<fantasai> - 1. If |list| contains the focused box, remove all other boxes from |list|.

<fantasai> - 1. If |list| contains the targeted box, remove all other boxes from |list|.

<fantasai> + 1. If |list| contains a focused box,

<fantasai> + remove all other boxes from |list|.

<fantasai> + Otherwise if it contains a box that contains a focused box,

<fantasai> + remove all but that which is its closest ancestor.

<fantasai> + 1. If |list| contains a targetted box,

<fantasai> + remove all other boxes from |list|.

<fantasai> + Otherwise if it contains a box that contains a targetted box,

<fantasai> + remove all but that which is its closest ancestor.

<fantasai> 1. For each |box| in |list|:

<fantasai> 1. Remove any box from |list| which is an ancestor of |box|.

<fantasai> 1. If |inline| and |block| are overlapping sets:

<fantasai> ...

astearns: I think fantasai argued against algos in spec, but looks like an algo

fantasai: yes but that's what's currently there, in some cases we need them

astearns: more comments?

emilio: to we want to prioritize targeted or focused?

fantasai: focused

PROPOSED: apply the suggested diff

emilio: might be simpler to do priority sorting, but otherwise fine

astearns: objections?

RESOLUTION: addd the equivelant to the suggested diff