- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Mon, 20 Mar 2023 15:03:07 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[scroll-animations-1] Consider initial value of auto for view-timeline-inset`, and agreed to the following: * `RESOLVED: scroll overlap range is in addition to scroll-padding, view-timeline-inset should have an initial value of auto` <details><summary>The full IRC log of that discussion</summary> <emilio> flackr: we discussed this in our previous session and resolved that the initial view-timeline-inset should be 0 based on the assumption that scroll-padding was used to set a margin for page-down operations<br> <emilio> ... but all browsers actually scroll 87% of the remaining area after you remove scroll-padding<br> <emilio> ... so scroll-padding is strictly used for occluding element<br> <emilio> ... and changing that would break sites that use it to exclude occluding elements<br> <Rossen_> q?<br> <emilio> ... so proposal is to have auto which is scrollport minus scroll-padding<br> <emilio> ... to account for invisible elements<br> <emilio> fantasai: one of the goals for scroll-padding was to give the author the ability to control that overlap<br> <emilio> ... or zero, but I understand we have a compat problem but that brings the question of how we want to address that use case<br> <fantasai> s/or zero/or set it to zero/<br> <emilio> flackr: so... the issue is that devs have used it assuming that it's strictly an overlapping-element-region<br> <emilio> ... if we change the interpretation as offset-defining the page region you change page-down behavior<br> <emilio> ... I guess it's complicated wrt view-timeline-inset<br> <emilio> fantasai: I think for view-timeline-inset should just account for padding<br> <emilio> q+<br> <emilio> fantasai: that's what auto would do, it should not pay attention to the absolute amount of scroll<br> <emilio> flackr: developers are using it because we don't use that as the page value<br> <Rossen_> ack emilio<br> <fantasai> emilio: I was going to agree with fantasai<br> <emilio> fantasai: ua should provide some overlap for continuity purposes on top of that<br> <fantasai> s/ua should/then we need to update the scroll-snap spec to say the ua should/<br> <emilio> flackr: [on-the-spot compat check]<br> <fantasai> flackr: Chrome and Safari are using 87.5% of the scroll-padding inset area<br> <emilio> flackr: firefox is not using scroll-padding at all for page amount, webkit/blink have 87% of scroll-padding<br> <fantasai> flackr: Firefox is not using scroll-padding at all<br> <fantasai> emilio: I think scroll-padding should be accounted for<br> <fantasai> emilio: if we don't, it's an oversight<br> <fantasai> emilio: It might be we don't want to define as the whole region<br> <fantasai> emilio: but, we could still not have an auto value<br> <fantasai> emilio: and use zero and have ?? use scroll-padding area<br> <fantasai> emilio: I don't care either way, having a zero start or auto<br> <emilio> flackr: I just remembered the other complication, we use the padding area for how much additional scrolling we need to do to scroll things into view<br> <emilio> ... so the way it's defined it's better suited to define overlapping elements<br> <emilio> ... to me that implies it should be fine to have view-timeline follow that as the default<br> <emilio> fantasai: I think the proposed resolution is: #1, scroll overlap range is in addition to scroll-padding, that requires scroll snap changes<br> <emilio> ... #2 changing view-timeline-inset to have an initial value of auto<br> <emilio> RESOLVED: scroll overlap range is in addition to scroll-padding, view-timeline-inset should have an initial value of auto<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7747#issuecomment-1476397011 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 20 March 2023 15:03:08 UTC