- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 28 Aug 2024 16:40:01 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-overflow-5][css-scroll-snap-2] Snapping and generating scroll-marker pseudo-elements from fragments`, and agreed to the following: * `ACTION: fantasai to comment on the options` * `ACTION: rob to write up ::column option` <details><summary>The full IRC log of that discussion</summary> <bramus> flackr: one of the things that came up how devs can author content around auto paginated fragments (cols or page fragments int he future) is how do you actually attach scroll markers or snap styling?<br> <bramus> … or other things?<br> <bramus> … there is three general directions<br> <bramus> … the overflow spec already has mention of styling fragments<br> <bramus> … has an nth-fragment selector but there are internal concerns about it<br> <bramus> … one option to have a fragment selector that applies to all fragments<br> <bramus> … second option to make the indiv properities fragment aware<br> <bramus> … alreadu have issue for scroll-snap-align<br> <bramus> … (firefox and and chrome differ)<br> <bramus> … could decide that this is anice way to turn fragments int snap areas or markers<br> <bramus> … third option is a different syntax to make the property aware of fragments<br> <bramus> … (code in issue)<br> <bramus> … second option is nice and simple<br> <bramus> … at least for snap areas: snap areas per fragment box<br> <bramus> … can do same for scroll markers but feels weird<br> <bramus> … maybe can go for something different?<br> <bramus> … this is the way to go or should be pursue fragment styling?<br> <TabAtkins> I don't have a strong opinion on this, but I support the use-case.<br> <TabAtkins> Doing it via a non-numbered ::fragment, to avoid implying different styling on fragments, seems useful<br> <bramus> astearns: also support the use case like but dont have feedback on choosing<br> <bramus> … anyone with better opinion?<br> <astearns> ack fantasai<br> <bramus> fantasai: i think a generic ::fragment representing column in multicol is confusing<br> <bramus> … bc we have several different ideas about fragmentation and multicol as one type of thing that creates fragments in a container<br> <bramus> … i think ?? set scroll-snap-aling on column makes sens but should do that with pseudo element<br> <rachelandrew> +1 for scrollsnapping on columns, we have issues for that.<br> <bramus> … one of the discussions in overflow spec was to have nth-fragment pseudo element<br> <astearns> s/with pseudo/with column pseudo/<br> <bramus> … it represents instances of the block through wihch the content fragments<br> <bramus> … very different concept from multicol cols which are boxes<br> <bramus> … inside the ??<br> <astearns> (discussing the overflow: fragment proposal)<br> <bramus> … dont think scrollsnapalign should target column when you set it on multicol<br> <bramus> … should target the col that allows the snap property on ??<br> <bramus> flackr: that is not what is listed in the issue<br> <bramus> … for option 2 it is saying tha tif you set ssa on the in the multicol<br> <bramus> … then should it generate are snap area per generated box<br> <bramus> fantasai: dont have good answer to that<br> <bramus> flackr: to be clear: not to set ssa on the thing establishing the multicol<br> <bramus> … q is wheter setting those should have an effect per fragment<br> <bramus> … could be per property<br> <bramus> fantasai: yes, transforms and borders for example differ<br> <bramus> flackr: brought it up as one possible way<br> <bramus> … if you want to snap align, you can wrap everything in multicol and then have sssa<br> <bramus> fantasai: <missed><br> <bramus> … on last col it would be kinda weird<br> <astearns> s/<missed>/it would be better to set scroll snapping on the columns themselves/<br> <bramus> … as content could be shorter than the others<br> <bramus> flackr: yes, so vertical cneter would align differently<br> <bramus> iank_: there are usecases for if you have a fragmented box somehwere within multicol to generate a snap area per fragment<br> <bramus> … so that would still be useful<br> <bramus> … option 2 if we agree that generating snap are per fragment is strictly better behavior (like firefox) … could resolve on that<br> <bramus> … other prior art is box-decoration-break<br> <bramus> … dont think that makes … could explore that route<br> <bramus> … producing snap area per ? might be better behavior<br> <bramus> flackr: would solve the snap proble,<br> <bramus> … also need to decide on scroll markers<br> <bramus> astearns: so proposal to resolve on option 2 for snap areas<br> <bramus> … which would be in line with how firefox behaves<br> <bramus> flackr: yes<br> <fantasai> I'm not sure, in a multicol it might make sense to use the bounding box as the stanp area<br> <bramus> astearns: any concerns with that? or more time needed?<br> <fantasai> s/stanp/snap/<br> <bramus> astearns: do you mean bounding box of all of the fragments, elika?<br> <fantasai> yes<br> <fantasai> if you imagine for example the use case of highlighting something<br> <bramus> astearns: (chair hat off) agree with ian that htere are use cases for snapping 2 fragments individually<br> <fantasai> and then snapping to that highlighted section<br> <bramus> … so elika i think you’d rather not resolve and take it back to issue?<br> <bramus> fantasai: yeah, not sure what to … e.g. article inside scroller and highlighting function to highlight things … would you expec tto snap to each one individually or the whole region? not sure<br> <iank_> q+<br> <bramus> … dont have objection to resolve on ??<br> <bramus> flackr: a thing I heard is that you would be happy with sth like option 1 if we had a selector based on columns instead of fragment?<br> <bramus> … is that correct?<br> <bramus> … would be happy to take that as a direction to pursue<br> <fantasai> I think we should solve the column-snapping problem directly<br> <bramus> iank_: dont think that solves all th euse cases like snap align<br> <fantasai> and for fragments within the columns, address them also directly<br> <bramus> flackr: agree, there is a separate issue for snap areas<br> <fantasai> not as a proxy for the column-snapping<br> <bramus> … could continue to pursue for fragmented snap area boxes<br> <bramus> … I think we can solve a lot of the use cases that i am tring to address with orig issue by having a ::column selector for example<br> <bramus> … to create some style for the area<br> <bramus> bramus: heard requests for grid on that<br> <bramus> … would that also work there, or only for fragmentation?<br> <bramus> iank_: no, probably not<br> <astearns> ack iank_<br> <bramus> … other thing:<br> <bramus> … if we agree that both cases are useful for ssa, then proposal 3 where we say scroll-snap-stop per fragment vs not<br> <bramus> … need to decided on default behavior for scroll marker ??<br> <bramus> … bc one thing here is tha tif we go with ::column that would initially only be valid on scroll marker group and ssa (?)<br> <bramus> astearns: so hearing all three options are sitll in play<br> <bramus> … let’s take back to issue<br> <bramus> … can you add comments to all options, fantasai?<br> <fantasai> ACTION: fantasai to comment on the options<br> <bramus> … bc there are some unanswered questions<br> <bramus> ACTION: rob to write up ::column option<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10715#issuecomment-2315816602 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 28 August 2024 16:40:03 UTC