- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 03 Aug 2022 15:29:21 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `ViewTimeline insets`, and agreed to the following:
* `RESOLVED: view-timeline-inset takes a comma-separated list of 1 or 2 values, being autos or length-percentage`
<details><summary>The full IRC log of that discussion</summary>
<TabAtkins> Topic: ViewTimeline insets<br>
<TabAtkins> github: https://github.com/w3c/csswg-drafts/issues/7243<br>
<TabAtkins> bramus: the syntax for view timleine insets is you can have auto or 1-4 insets<br>
<TabAtkins> bramus: but for view timlines you only need 2, basically<br>
<TabAtkins> bramus: what ??? suggested in the issue is to only have two values<br>
<TabAtkins> bramus: so auto, 1 value, or 2 values<br>
<flackr> s/???/kevers<br>
<TabAtkins> bramus: if you only have 2 values, really easy to change the axis<br>
<TabAtkins> bramus: don't need to update the insets<br>
<flackr> q+<br>
<TabAtkins> bramus: it'll always be from beginning to end of targeted axis<br>
<astearns> ack flackr<br>
<TabAtkins> flackr: so for simpliciation i think this is more convenient<br>
<TabAtkins> flackr: but if you had more than one viewtimeline, i wonder if it's convenient to specify the insets in terms of block and inline, and not worry about whether each timeline was block or inline direction<br>
<TabAtkins> flackr: bc just having two values, we'd reinterpret based on direction of the timeline<br>
<TabAtkins> bramus: suggesting diff properties based on axis?<br>
<TabAtkins> flackr: It's already targeting axises, not timeline axis<br>
<TabAtkins> flackr: so no change would do it<br>
<TabAtkins> fantasai: two ways<br>
<TabAtkins> fantasai: 1) treat like scroll timeline, doesn't matter what direction, one set of padding that applies to everything<br>
<TabAtkins> fantasai: should probably rename to view-timeline-padding in that case<br>
<TabAtkins> fantasai: 2) separate set of insets per timeline, comma-separated of start/end insets<br>
<TabAtkins> fantasai: could have four insets per thing, and only two would apply to a timeline<br>
<TabAtkins> fantasai: seems excessive<br>
<TabAtkins> fantasai: not sure what's more ergonomic for authors<br>
<TabAtkins> fantasai: insets per timleine, or padding that applies to everything at once<br>
<TabAtkins> fantasai: one of the values is auto, where we just copy the value from scroll-padding<br>
<TabAtkins> fantasai: being able to flip that on and off easily is probably useful<br>
<TabAtkins> fantasai: but as for which direction is better overall, dunno<br>
<flackr> qq+<br>
<TabAtkins> fantasai: might require some amount of experience using this feature to know what's better<br>
<astearns> ack flackr<br>
<Zakim> flackr, you wanted to react to flackr<br>
<TabAtkins> flackr: given you can copy scroll padding, which is 4-axis, i'd propose doing a 2-axis specific to the timeline is most ergonomic<br>
<TabAtkins> flackr: If you wanna specify something that applies to all you can use scroll-padding, and this allows you to do a specific override<br>
<TabAtkins> fantasai: scroll-padding has many effects tho<br>
<TabAtkins> flackr: right, but if these are things that conceptually apply to all elements (including scrolling timelines), it should apply<br>
<TabAtkins> fantasai: hm unsure of initial value - do we think people want them to start in the scroll padding, or when visible on page? initial should maybe be zero<br>
<TabAtkins> flackr: I'd think scroll-padding is for if somethin's obscuring the top of the screen<br>
<astearns> initial value 0? https://drafts.csswg.org/scroll-animations-1/#view-timeline-inset<br>
<TabAtkins> fantasai: one use, but not all - might want a #target to have some breathing room, or PgDn to have some overlap<br>
<TabAtkins> fantasai: so defualt in browsers is to include some overlap; scroll-padding lets your control it<br>
<TabAtkins> fantasai: so many uess other than sidebar<br>
<TabAtkins> fantasai: can also use it for the sidebar, because you want similar reasons<br>
<TabAtkins> flackr: I think the overlap use-case is an important separate use-case, but i guess that's a different discussion<br>
<TabAtkins> flackr: but i'm okay with the default not including scroll-padding<br>
<TabAtkins> fantasai: yeah so that's the current initial value<br>
<flackr> For example intersection observer might want to care about sidebar obscured content<br>
<TabAtkins> fantasai: so what's more ergonomic for the author - something analogous to scroll-padding that sets all four edges, or separate insets per timeline, so ti's a comma-separated list<br>
<TabAtkins> fantasai: can see either direction<br>
<TabAtkins> flackr: I think per-timeline is more flexible<br>
<TabAtkins> flackr: might be cases where different animations want different insets<br>
<fantasai> TabAtkins: summary seems to be that view-timeline-inset should be a comma-separate inset of pairs<br>
<fantasai> s/inset of/list of/<br>
<fantasai> flackr: can be single value<br>
<fantasai> TabAtkins: yeah, singles get duplicated<br>
<fantasai> https://github.com/w3c/csswg-drafts/issues/7243#issuecomment-1157679915<br>
<fantasai> view-timeline-inset: 10% 10%, auto, 25% 25%;<br>
<TabAtkins> astearns: would that still allow the escape hatch that bramus mentioned, of making a shorthand that gives start/end in four values<br>
<TabAtkins> fantasai: We could do longhands but I seriously doubt people want them to cascade independent<br>
<TabAtkins> astearns: so auto/1/2 values now, can do 4 values later<br>
<TabAtkins> bramus: or add longhands<br>
<TabAtkins> astearns: that's the distinction, we can do longhands *or* more values<br>
<TabAtkins> flackr: wait we coudln't do 4 values, that would be inconsistent<br>
<TabAtkins> TabAtkins: right, 2 vs 4 wouldn't expand in the normal way<br>
<TabAtkins> astearns: so we're okay with auto/1/2 for now?<br>
<TabAtkins> astearns: so proposed resolution is view-timeline-inset to accept [auto | <length-percentage> ]{1,2}<br>
<TabAtkins> fantasai: and scroll-padding is copied over if you say auto, no change from current<br>
<TabAtkins> RESOLVED: view-timeline-inset takes a comma-separated list of 1 or 2 values, being autos or length-percentage<br>
<TabAtkins> flackr: relatedly we might want to do view-timeline-margin at some point<br>
<TabAtkins> bramus: and whether %s are against the scroller or the element<br>
<TabAtkins> bramus: that's a separate issue<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7243#issuecomment-1204110117 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 3 August 2022 15:29:23 UTC