- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 02 Apr 2025 15:46:29 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-overflow-5] scroll-marker-group on root scroller?`, and agreed to the following: * `RESOLVED: allow ::scroll-marker-group on the root, except it's a child of the root (first or last)` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> flackr: we defined how ::scroll-marker worked for overflow:scroll conktinaers<br> <fantasai> flackr: Question on whether to apply to the root element<br> <fantasai> flackr: This makes sense, but would require a slight change in behavior<br> <TabAtkins> florian: with overflow scrollers, the layout box for the scroll marker group is outside the scrolling container<br> <TabAtkins> s/florian/flackr/<br> <TabAtkins> flackr: but theres' nothing outside the root scroller<br> <TabAtkins> flackr: so the beahvior would be that they're like ::before or ::after on the root, before/after the first/last child<br> <TabAtkins> flackr: so they would be moved by scrolls unless you used fixpos to prevent that<br> <TabAtkins> flackr: otherwise everything works the same<br> <TabAtkins> astearns: that sounds reasonable, but do we have to?<br> <TabAtkins> flackr: many sites like usign the root scrolling because it works better with the address bar.<br> <TabAtkins> flackr: and you can create ToC-like thing with scroll markers<br> <emilio> q+<br> <TabAtkins> astearns: makes sense, i just hadn't seen a description fo th euse-case<br> <astearns> ack emilio<br> <TabAtkins> emilio: why can't it be a sibling? some things like top layer are alreayd defined to be like siblings of the root<br> <TabAtkins> flackr: it couldn't reserve space in a way taht meaningfully interacts with the scorlling content...<br> <TabAtkins> flackr: but we could psoition is similar to top-layer items<br> <TabAtkins> flackr: i think i'd find it a bit surprising, but...<br> <TabAtkins> flackr: i'd rather have authors treat them as fixpos<br> <TabAtkins> emilio: a fixpos element is not within the scroller either<br> <TabAtkins> emilio: so i'm not sure why making them a fixpos element wouldn't work<br> <TabAtkins> flackr: that's what i'm proposing authors do - make them fixpos<br> <TabAtkins> emilio: do we need to make themc hildren, tho? why the exception?<br> <TabAtkins> flackr: there are implications with how you navigate thru focusable content<br> <TabAtkins> flackr: like scroll-marker-gorup:after focuses after the scroller content. making it last child works naturally<br> <TabAtkins> flackr: but i suppose it could be defined to work like that<br> <TabAtkins> emilio: right, you need to define that for top-layer things anyway.<br> <TabAtkins> emilio: VTs are siblings of the root but they're not focusable<br> <TabAtkins> flackr: and i don't think it maeks sense to be implicitly on top of all the content<br> <TabAtkins> emilio: they don't need to be?<br> <TabAtkins> flackr: then i don't understand the behavior proposal<br> <TabAtkins> emilio: do these inherit from their originating element even tho they're siblings?<br> <TabAtkins> flackr: yesah<br> <TabAtkins> emilio: then i guess it doesn't really matter too much<br> <TabAtkins> emilio: difference is if they're statically possitioned, they're inside or outside the root scroller<br> <TabAtkins> emilio: i was just a bit conderned about inheritance, but i guess that doesn't change<br> <TabAtkins> emilio: so i just wonder when this would be observable<br> <TabAtkins> emilio: so only if they're statically positioned<br> <TabAtkins> flackr: yeah, they'd act like the first/last children of the document<br> <TabAtkins> emilio: i guess if that difference would be useful... i guess id on't object to making them children<br> <TabAtkins> emilio: at least DOM-wise i don't see a need for the exception, but it's useful to not ahve in-flow content outside the root scroller<br> <TabAtkins> q+<br> <TabAtkins> flackr: yeah, i'm thinking it would be less of a special case<br> <astearns> ack TabAtkins<br> <fantasai> TabAtkins: One question. How difficult would this make it to, say, put your scroll group in one cell of a page-defining grid, and the rest of your content in the other cell of the grid?<br> <fantasai> TabAtkins: e.g. if you wanted to set up a table-of-contents<br> <fantasai> flackr: I think it could participate in the grid established by the root element...<br> <emilio> q+<br> <astearns> ack emilio<br> <TabAtkins> emilio: yeah i guess that's a case where making it a sibling of the root would be annoying<br> <TabAtkins> fantasai: wouldn't that be consistent with the *toher* cases tho?<br> <TabAtkins> fantasai: and do we really want to develop scroll markers to the point where they can be a full ToC?<br> <TabAtkins> TabAtkins: they're already pretty much there<br> <TabAtkins> flackr: there's also cases already for full-page carousel dots<br> <astearns> s/toher/other/<br> <TabAtkins> fantasai: i guess you do still have access to the body as a wrapper<br> <fantasai> s/body/parent/<br> <TabAtkins> flackr: yeah, if it's a sibling of root you don't ahve access to the overall container<br> <TabAtkins> astearns: so proposed is that scroll-marker-group on the root is treated as being a child of the root instead of a sibling<br> <TabAtkins> fantasai: taking tab's example of making a page grid<br> <TabAtkins> fantasai: and the rest of the content was in the main section of the grid, markers in the side<br> <TabAtkins> fantasai: in that case the scrolling element is no longer the root scroller, which is kinda what you want, isn't it<br> <TabAtkins> fantasai: you still want the page to scroll via the root scroller<br> <TabAtkins> fantasai: so this might tie into another issue - can the page propagate its root scroller<br> <TabAtkins> flackr: i think the way it works is you just end up with a really tall grid, so you're still scrolling<br> <TabAtkins> fantasai: but then since it's not the root scroller why not set the grid o nthe html element, and make the body your scroll container<br> <TabAtkins> TabAtkins: [discuss example]<br> <TabAtkins> fantasai: so html is a big grid, body in the right slot, scroll-marker-group on the left slot, overflow:scroll on the body<br> <TabAtkins> flackr: skip the overflow-scroll, just let the grid get big<br> <TabAtkins> fantasai: but then your marker group scrolls off the screen<br> <TabAtkins> TabAtkins: then you use stickypos<br> <TabAtkins> astearns: does your qeustion modify the resolution we were tying to take?<br> <TabAtkins> fantasai: not sure. probably not?<br> <fantasai> TabAtkins: we definitely still want to address the scroll delegation, but not required to do reasonable things here<br> <TabAtkins> astearns: so again, any objections?\<br> <TabAtkins> RESOLVED: allow ::scroll-marker-group on the root, except it's a child of the root (first or last)<br> <TabAtkins> TabAtkins: is this inside or outside the ::before/after pseudos?<br> <TabAtkins> flackr: prefer outside, that's more consistent with the other cases where it's a sibling<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11802#issuecomment-2773010804 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 2 April 2025 15:46:30 UTC