Re: [csswg-drafts] [css-overflow-5] Scroll button pseudo-elements (#10722)

The CSS Working Group just discussed `[css-overflow-5] Scroll button pseudo-elements`.

<details><summary>The full IRC log of that discussion</summary>
&lt;TabAtkins> flackr: scroll buttons are conceptually simialr to scroll markers<br>
&lt;TabAtkins> flackr: they are focusable, they hang off the scroll container<br>
&lt;TabAtkins> flackr: and they scroll that element in the indicated direction, as specified by their selector<br>
&lt;TabAtkins> flackr: here i used ::scroll-down-button, but we have syntax alternatives like ::scroll-button(down), this would better let authors specify logical or physical directions, dpeneding on which is appropraite<br>
&lt;ntim> WebKit does want to move away from the PseudoElement class that extends Element<br>
&lt;flackr> https://flackr.github.io/carousel/examples/scroll-button/<br>
&lt;TabAtkins> flackr: so i have a demo built on the polyfill - you also saw them in the Canary live demo<br>
&lt;TabAtkins> flackr: Here's a terms of service agreement or something, page down buttons to go down<br>
&lt;ntim> WebKit only uses that for ::before / ::after. The other pseudos that generate boxes are hooked to render tree building<br>
&lt;TabAtkins> flackr: they should implicitly become inactive when you can't scroll further<br>
&lt;TabAtkins> flackr: and they scroll equivalent to one page, like pressing PgDn<br>
&lt;TabAtkins> smfr: is that the equivalent of a smooth programmatic scroll<br>
&lt;bkardell_> q+<br>
&lt;TabAtkins> TabAtkins: I assume it's basically a PgDn press (possibly in other directions)<br>
&lt;bkardell_> q-<br>
&lt;TabAtkins> smaug: maybe a little tricky, maybe not scrolling a full view of height<br>
&lt;TabAtkins> flackr: my understanding is most browsers scroll 85% of the optimal viewing region of the scroller<br>
&lt;TabAtkins> flackr: so you can still see osme of the previous content<br>
&lt;TabAtkins> flackr: of course, with snap areas it'll align as necessary<br>
&lt;TabAtkins> dbaron: I think some may avoid letting the overlap get too big relative to the default font size, you don't want too many lines repeated<br>
&lt;TabAtkins> smfr: so this is independent from carousels, right? basically a generic "fake scroller" control<br>
&lt;TabAtkins> flackr: yes<br>
&lt;TabAtkins> smfr: and you could have one for the root scroller?<br>
&lt;TabAtkins> flackr: yes<br>
&lt;TabAtkins> dbaron: is it problematic for pseudos to be focusable?<br>
&lt;TabAtkins> flackr: i don't think so<br>
&lt;smfr> q+<br>
&lt;flackr> TabAtkins: we presumably want to make psuedos focusable<br>
&lt;flackr> TabAtkins: i hope it's fine<br>
&lt;TabAtkins> dbaron: I think there's a bunch of things taht assume the curently focused thing is an Element<br>
&lt;TabAtkins> flackr: my thinking is that .activeElement<br>
&lt;jarhar> q?<br>
&lt;TabAtkins> dbaron: that's one of the pieces, yes<br>
&lt;TabAtkins> flackr: it'd give you an actual element, in the case of these buttons its the scroll container<br>
&lt;TabAtkins> flackr: this is similar to having focus in a shadow dom, the host element is the activeElement<br>
&lt;TabAtkins> dbaron: that seems like a reasonable model<br>
&lt;TabAtkins> dbaron: it does need to define tab order and such<br>
&lt;TabAtkins> bkardell_: what's the role?<br>
&lt;TabAtkins> flackr: depends on the pseudo, but needs to be well-defined for each.<br>
&lt;TabAtkins> flackr: for scroll buttons, presumably a button<br>
&lt;TabAtkins> flackr: i definitely want feedback on things like "what is the focus order"<br>
&lt;TabAtkins> flackr: i think general guidance is buttons for navigating should be together in a group, so they hit the buttons, then into the contents<br>
&lt;TabAtkins> bkardell_: right now scrollers don't have focus behavior, right? you focus the area.<br>
&lt;TabAtkins> ??: it depends!<br>
&lt;TabAtkins> flackr: notaby this is not reproducing the scrollbar, it's adding new scrolling affordances<br>
&lt;TabAtkins> hdv: is there a precedent for gencontent to have their own roles<br>
&lt;flackr> TabAtkins: there hasn't been yet as so far they haven't been given focusability<br>
&lt;smfr> q-<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10722#issuecomment-2375368992 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 25 September 2024 22:20:45 UTC