- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 03 Feb 2022 01:00:52 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-overflow] Proposing scroll-start: allowing overflow scroll to not always start at 0 on 1st layout pass`, and agreed to the following: * `RESOLVED: Accept the proposal for scroll-start and add to scroll snap L2` * `RESOLVED: Add argyle as a co-editor of scroll snap L2` <details><summary>The full IRC log of that discussion</summary> <dael> Topic: [css-overflow] Proposing scroll-start: allowing overflow scroll to not always start at 0 on 1st layout pass<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/6986<br> <dael> argyle: Goal, we did survey asking devs about experience in scroll. Starting to write explainers<br> <dael> argyle: Scroll-start has overlap with frag navigation conceptually. But that is more magical b/c has more work to do and integrations to things like page refresh<br> <smfr> q+<br> <dael> argyle: This wants to bring a portion of that power to move someone. Example is tabs to swipe between and want tos tart on a midway tab so it laysout at that tab<br> <dael> argyle: All solutions to do this now take extra time and additional work<br> <dael> argyle: Tucking a search bar above the fold is common. Spotify does this where you don't see search until you scroll up<br> <dael> argyle: Proposal is advocating for way to do that in css using links as default. scroll-start 20px from top. Could also use %<br> <dael> argyle: This would only apply if frag nav isn't used and user hasn't interacted with scroll. Waiting for checks listed in explainer to make sure it's untouched<br> <dael> argyle: If so on first layout layout at this position<br> <dael> argyle: Adds scroll-start:target which is where you can have a child as a target for scroll. Akin to scroll-snap where you can snap on first layout. But after that you can't scroll anywhere<br> <dael> argyle: People hack around this by setting a keyframe. Have a snap child, wait a keyframe, and then remove an animation to remove the snap so you can move<br> <dael> argyle: Offering something simple for this<br> <dael> argyle: Property on the child where child in scroll container says snap to me if user hasn't ineracted with page<br> <Rossen_> q?<br> <dael> argyle: Additional details int he proposal, but how is that for a first pass?<br> <dael> smfr: I like proposal. Useful functionality. Like that it's element-based target<br> <dael> smfr: question is if we can define first layout pass. If page toggles display none and then goes back does that trigger first layout? If the layout tree is distroyed is that first layout?<br> <dael> argyle: Nice. I hadn't articulated the proper timing. Makes sense as a request for the explainer. Thank you<br> <Rossen_> ack smfr<br> <Rossen_> ack fantasai<br> <dael> fantasai: I think the idea of doing this makes a lot of sense.<br> <dael> fantasai: Being able to choose and element and have it be focus makes sense<br> <heycam> q+<br> <dael> fantasai: Agree with TabAtkins should be property on element not scroll container<br> <dael> fantasai: Have a similar problem with baseline alignment and alining to child. 1339 issue<br> <dael> fantasai: Should make them consistent in how they lookup<br> <dael> fantasai: Makes sense overall and I support working on it<br> <flackr> q+<br> <dael> argyle: So in favor of child property but don't agree with scroll port property of scroll-start?<br> <dael> fantasai: NOt sure if we need opt in for scroller, but scroller shouldn't pick position<br> <dael> argyle: Absolutely<br> <dael> fantasai: In terms of figuring out how element aligns in port we should reuse snap. I think alignment question is handled by scrollsnap. You do h ave question of first or last element that qualifies<br> <dael> fantasai: Another interaction, content alignment can effect initial scroll position. Have to figure out how that interacts<br> <dael> argyle: Thank you. Taken notes<br> <dael> argyle: In explainer does say if parent and child both have or multiple children have snap target it has how to resolve. Currenlty first in dom<br> <dael> fantasai: Good answer. First in dom makes a lot of sense. Want to think about if an element can block it's children from participating in that<br> <dael> argyle: Thank you<br> <Rossen_> ack heycam<br> <dael> heycam: Wondering what should happen when the page is loading slowly or content is added to scroll container and first layout happens before target offset is reached. Keep reevaluating to determine if we do a scroll until condition is met?<br> <dbaron> Not just lazy addition from script, but also a large page that does the first layout of the container when only some of its content has been loaded.<br> <dael> argyle: Current mentality is this is easy to interrupt. It's a request. In case of something being lazy I would assume...say it's scroll-start:left 200px. If it did first layout and nothing has happened I would say if a scroll-start shows up later it's ignored. Scroll position is set<br> <dael> heycam: A little worried authors would test on fast connection, get desired behavior, and then publish and scroll position isn't updated so looks weird<br> <Rossen_> q<br> <dael> fantasai: I think we should use logic for [missed] and this would be the feature for how that works<br> <Rossen_> ack fantasai<br> <Zakim> fantasai, you wanted to reply to that<br> <dbaron> The logic for scrolling to targeted elements isn't very good -- I really wanted to try to improve it about 15 years ago but never got around to it. :-/<br> <fantasai> s/[missed]/scrolling to :target/<br> <dael> TabAtkins: Going to say the same<br> <chrishtr> q+<br> <dael> argyle: And point of this is prevent janka nd be there first. Misses it's mark if containing scroll port has been created and there's no children.<br> <fantasai> s/feature for/feature defining/<br> <dael> argyle: I'm assuming Java is appending, but maybe even a really long document. I'm inclined to say trying to prevent jank and we want to do it all before a user sees it<br> <dael> iank_: It's possible that your html can slowly trickle in. I think that's heycam slow connection<br> <Rossen_> ack flackr<br> <dael> flackr: I wanted to reply to smfr and heycam points. In my mind see this as substitute for assumed 0 defaults scroll. So should reapply any time we would start at position 0. Probably not same as fragmenetion because that waits<br> <dael> flackr: For css any time something introduced with scroll it shouldn't jump<br> <dael> flackr: When an element becomes a scroll container we should look for this and jump to that unless doing other frag navigation<br> <Rossen_> q?<br> <fantasai> s/fragmenetion/fragment navigation/<br> <TabAtkins> +1 to flackr's points<br> <Rossen_> ack dbaron<br> <dael> dbaron: Related to flackr just said. My opinion is frag navigation is not very good. Had plan to fix around 2007 but kept postponing<br> <dael> dbaron: Thing that happened 3 or 4 years ago that had some improvements. I would have liked to see frag nav try to scroll to frag more frequently and have astate to say if it should keep trying<br> <dael> dbaron: Not what happened and might not be web compat<br> <dael> dbaron: Maybe doing same as frag nav is okay, but I think it's not that great and could be better for users<br> <Rossen_> ack chrishtr<br> <fantasai> +1 to not specifying an offset; should choose an element, and align it based on properties in css-scroll-snap<br> <dael> chrishtr: Had a thought similar to flackr and others. What if instead of spec some default offset you spec what scroll anchor target is at the beginning. And that remains until user does something. If page takes a while to load browser knows what target should be and as it loads browser centers it on screen<br> <dael> argyle: Sounds interesting. Sound like overlap with scroll start target. Maybe target should behave as desc<br> <dael> fantasai: I think if we go with idea that scroll-snap-target aligns the same as scroll snap properties. Scroll padding and margin and align can determine the position. I think that should handle the offsets. Not sure there's a use case for offset at start not being the same as if you were targetting to the element<br> <iank_> What about for a large <canvas> within a scroller where you don't have an element to target?<br> <dael> argyle: Hearing advocacy for scroll-start:target and no scroll-start b/c in general want to scroll an item into view<br> <dael> argyle: There are people that wanted keywords or end and center that are 100% or 50%<br> <Rossen_> q?<br> <dael> argyle: See what you're saying that length would be less used.<br> <TabAtkins> Agree we *sometimes* want an explicit offset.<br> <dael> argyle: Does seem like ti should be an offering. Like i know by hearder is 50 px and what to be under that<br> <smfr> maybe this should also cover the “always scrolled to the bottom“ case for chats etc<br> <dael> fantasai: You want to target the thing under the heading so that you can change the font on your heading and have it still work<br> <dael> fantasai: You can already to top of bottom with align content<br> <dael> TabAtkins: There's a use case in chat where you can't do offset. Large canvas in a scroller<br> <dael> fantasai: Can see that. Can also see if doing fancy with canvas you want to define snap areas. more to be done with canvas<br> <chrishtr> Re large canvas: there should be a way to specify a position relative to that element<br> <dael> argyle: Another is shopping where image takes up show screen. Start with that in center and then you can pan.<br> <Rossen_> q?<br> <dael> fantasai: I believe align content is defined to do that<br> <fantasai> https://www.w3.org/TR/css-align-3/#overflow-scroll-position<br> <dael> Rossen_: Seems like have positive consensus to adopt this proposal<br> <dael> Rossen_: Sure there are details to work out<br> <dael> Rossen_: I see smfr is adding some of those to the issue<br> <dael> Rossen_: Assuming you're looking for resolution to adopt?<br> <dael> argyle: Correct. Want way forward to prototype. Have demos and stuff for scrollsnap we're hoping to add scroll start<br> <dael> fantasai: rec to draft this as level 2. it's going to work closely with properties to determine position<br> <fantasai> s/level 2/scroll snap level 2/<br> <dael> Rossen_: Prop 1: Accept hte proposal for scroll-start and add to scroll snap L2<br> <dael> Rossen_: Objections?<br> <dael> fantasai: No obj but would like to hold off on adding the offset and start with the element. Should look at use cases<br> <dael> Rossen_: If we have this in its own draft much easier to tease out issues<br> <dael> Rossen_: Didn't hear objections<br> <dael> RESOLVED: Accept the proposal for scroll-start and add to scroll snap L2<br> <dael> Rossen_: Question 2, who will do this? Do we need to add argyle as an editor?<br> <dael> TabAtkins: Good idea if he's okay<br> <dael> argyle: Happy to join in<br> <dael> Rossen_: Obj to add argyle as a co-editor of scroll snap l2<br> <dael> RESOLVED: Add argyle as a co-editor of scroll snap L2<br> <dael> argyle: Plenty more to come<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6986#issuecomment-1028503857 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 3 February 2022 01:00:54 UTC