[css-overflow-5] scroll-marker-group on root scroller?

[flackr]

Should we allow scroll-marker-group: before | after on the root element? E.g.

:root {
  scroll-marker-group: before;
}
:root::scroll-marker-group {
  position: fixed; 
  top: 8px;
}

This seems like reasonable behavior to me but would be slightly different than on typical overflow divs. In particular, the ::scroll-marker-group can't be a sibling to the content, but will be more like a ::before or ::after pseudo-element being a regular child.

[css-meeting-bot]

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)

The full IRC log of that discussion

<TabAtkins> flackr: we defined how ::scroll-marker worked for overflow:scroll conktinaers
<fantasai> flackr: Question on whether to apply to the root element
<fantasai> flackr: This makes sense, but would require a slight change in behavior
<TabAtkins> florian: with overflow scrollers, the layout box for the scroll marker group is outside the scrolling container
<TabAtkins> s/florian/flackr/
<TabAtkins> flackr: but theres' nothing outside the root scroller
<TabAtkins> flackr: so the beahvior would be that they're like ::before or ::after on the root, before/after the first/last child
<TabAtkins> flackr: so they would be moved by scrolls unless you used fixpos to prevent that
<TabAtkins> flackr: otherwise everything works the same
<TabAtkins> astearns: that sounds reasonable, but do we have to?
<TabAtkins> flackr: many sites like usign the root scrolling because it works better with the address bar.
<TabAtkins> flackr: and you can create ToC-like thing with scroll markers
<emilio> q+
<TabAtkins> astearns: makes sense, i just hadn't seen a description fo th euse-case
<astearns> ack emilio
<TabAtkins> emilio: why can't it be a sibling? some things like top layer are alreayd defined to be like siblings of the root
<TabAtkins> flackr: it couldn't reserve space in a way taht meaningfully interacts with the scorlling content...
<TabAtkins> flackr: but we could psoition is similar to top-layer items
<TabAtkins> flackr: i think i'd find it a bit surprising, but...
<TabAtkins> flackr: i'd rather have authors treat them as fixpos
<TabAtkins> emilio: a fixpos element is not within the scroller either
<TabAtkins> emilio: so i'm not sure why making them a fixpos element wouldn't work
<TabAtkins> flackr: that's what i'm proposing authors do - make them fixpos
<TabAtkins> emilio: do we need to make themc hildren, tho? why the exception?
<TabAtkins> flackr: there are implications with how you navigate thru focusable content
<TabAtkins> flackr: like scroll-marker-gorup:after focuses after the scroller content. making it last child works naturally
<TabAtkins> flackr: but i suppose it could be defined to work like that
<TabAtkins> emilio: right, you need to define that for top-layer things anyway.
<TabAtkins> emilio: VTs are siblings of the root but they're not focusable
<TabAtkins> flackr: and i don't think it maeks sense to be implicitly on top of all the content
<TabAtkins> emilio: they don't need to be?
<TabAtkins> flackr: then i don't understand the behavior proposal
<TabAtkins> emilio: do these inherit from their originating element even tho they're siblings?
<TabAtkins> flackr: yesah
<TabAtkins> emilio: then i guess it doesn't really matter too much
<TabAtkins> emilio: difference is if they're statically possitioned, they're inside or outside the root scroller
<TabAtkins> emilio: i was just a bit conderned about inheritance, but i guess that doesn't change
<TabAtkins> emilio: so i just wonder when this would be observable
<TabAtkins> emilio: so only if they're statically positioned
<TabAtkins> flackr: yeah, they'd act like the first/last children of the document
<TabAtkins> emilio: i guess if that difference would be useful... i guess id on't object to making them children
<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
<TabAtkins> q+
<TabAtkins> flackr: yeah, i'm thinking it would be less of a special case
<astearns> ack TabAtkins
<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?
<fantasai> TabAtkins: e.g. if you wanted to set up a table-of-contents
<fantasai> flackr: I think it could participate in the grid established by the root element...
<emilio> q+
<astearns> ack emilio
<TabAtkins> emilio: yeah i guess that's a case where making it a sibling of the root would be annoying
<TabAtkins> fantasai: wouldn't that be consistent with the *toher* cases tho?
<TabAtkins> fantasai: and do we really want to develop scroll markers to the point where they can be a full ToC?
<TabAtkins> TabAtkins: they're already pretty much there
<TabAtkins> flackr: there's also cases already for full-page carousel dots
<astearns> s/toher/other/
<TabAtkins> fantasai: i guess you do still have access to the body as a wrapper
<fantasai> s/body/parent/
<TabAtkins> flackr: yeah, if it's a sibling of root you don't ahve access to the overall container
<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
<TabAtkins> fantasai: taking tab's example of making a page grid
<TabAtkins> fantasai: and the rest of the content was in the main section of the grid, markers in the side
<TabAtkins> fantasai: in that case the scrolling element is no longer the root scroller, which is kinda what you want, isn't it
<TabAtkins> fantasai: you still want the page to scroll via the root scroller
<TabAtkins> fantasai: so this might tie into another issue - can the page propagate its root scroller
<TabAtkins> flackr: i think the way it works is you just end up with a really tall grid, so you're still scrolling
<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
<TabAtkins> TabAtkins: [discuss example]
<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
<TabAtkins> flackr: skip the overflow-scroll, just let the grid get big
<TabAtkins> fantasai: but then your marker group scrolls off the screen
<TabAtkins> TabAtkins: then you use stickypos
<TabAtkins> astearns: does your qeustion modify the resolution we were tying to take?
<TabAtkins> fantasai: not sure. probably not?
<fantasai> TabAtkins: we definitely still want to address the scroll delegation, but not required to do reasonable things here
<TabAtkins> astearns: so again, any objections?\
<TabAtkins> RESOLVED: allow ::scroll-marker-group on the root, except it's a child of the root (first or last)
<TabAtkins> TabAtkins: is this inside or outside the ::before/after pseudos?
<TabAtkins> flackr: prefer outside, that's more consistent with the other cases where it's a sibling