- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 16 Dec 2020 17:59:49 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-scroll-snap-1] Snap area trapping behavior of non scrollable elements`, and agreed to the following: * `RESOLVED: Mark this property at-risk` <details><summary>The full IRC log of that discussion</summary> <dael> Topic: [css-scroll-snap-1] Snap area trapping behavior of non scrollable elements<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/4496<br> <dael> fantasai: Added b/c we had original set up scroll-snap-type where if it's non-inital it traps snaps. If elements inside asking for snap position we ignore. scroll cotnainers have to trap. Added additional behavior for scroll-snap-type so if someone wants to say in this area ignore a snap position they could do so<br> <dael> fantasai: Seems this is difficult to impl for Blink. Do we want to not have the behavior? Would mean only way to prevent contents from having snap behavior is put in a scroll container<br> <dael> Rossen_: It's a hack. The hack will work. People will hate the hack. It'll probably end up in css hacks books.<br> <fantasai> https://github.com/w3c/csswg-drafts/issues/4496#issuecomment-706333521<br> <dael> Rossen_: Is it really that difficult that we should go to that extent.<br> <dael> fantasai: Here's comment from impl ^<br> <dael> fantasai: I'm not aware of any requests for the behavior<br> <dael> Rossen_: non-Blink impl with opinion?<br> <dael> smfr: My hunch is it doesn't make sense for non-scrollable things to trap snapping<br> <dael> fantasai: Within that element we don't track snap position<br> <dael> Rossen_: Image in a carosel scenario?<br> <dael> fantasai: No. a section and in that section there's properties setting snap points, you can turn that off. You can say this element ignore the snap positions. We can just not have that behavior and see if someone complaints<br> <fantasai> s/positions/positions inside/<br> <dael> Rossen_: In interest of time we can resolve here. If there are no strong arguments for keeping it I'm fine with that<br> <dael> smfr: Looked at WK and would be easy to impl<br> <dael> Rossen_: Argument for reverting doesn't seem to be a problem for WK<br> <dael> Rossen_: What if we keep issue open and when we get to actual impl and get experience I think that's when we come back and decide<br> <dael> fantasai: Mark at-risk?<br> <dael> Rossen_: Sensible<br> <dael> Rossen_: Objections?<br> <dael> RESOLVED: Mark this property at-risk<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4496#issuecomment-746735816 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 16 December 2020 17:59:50 UTC