- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 14 Feb 2024 22:25:39 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-pseudo-4] Enabling carousel design patterns in CSS`, and agreed to the following: * `RESOLVED: Start overflow-5 draft, editors elika, florian, rob, move the fragmentation appendix from overflow-4 into it, work on addressing paginated overflow and scroll markers` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> flackr: i've been xploring how to help devs make better carousels, because they're very common<br> <TabAtkins> flackr: but people do it in all sorts of ways, and they're often inaccessible or just don't feel like native features<br> <TabAtkins> flackr: so i've been exploring what we can do to help that<br> <TabAtkins> flackr: [shows a demo site]<br> <TabAtkins> flackr: i think there's a small set of new features that would enable implementing the main set of carousel styles<br> <TabAtkins> flackr: wanna go thru these and discuss them in whole, then break them into independent issues<br> <TabAtkins> flackr: first is stylable fragmentation<br> <TabAtkins> flackr: ::fragment, probably border and other layout-inducing properties aren't allowed<br> <TabAtkins> flackr: important thing is alignment working<br> <TabAtkins> flackr: you'll notice the dev hasn't decided how many items fit on a page here, the UA has, so as you resize it changes<br> <TabAtkins> flackr: this also works in more complex cases, like arbitrarily flowing content between pages<br> <TabAtkins> flackr: a common pattern is you want content in your scroller tha you create nav entry points to<br> <TabAtkins> flackr: in here the HTML is a list of sections, and we have a new pseudo-element on the section called ::scroll-marker<br> <TabAtkins> flackr: this automatically flows into a size-contained area adjacent to the scroller<br> <TabAtkins> flackr: the "scroll markers area", i've put in a specific grid area to the side<br> <bkardell_> q+<br> <astearns> zakim, open queue<br> <Zakim> ok, astearns, the speaker queue is open<br> <TabAtkins> flackr: and given each a counter so it numbers the sections<br> <bkardell_> q+<br> <TabAtkins> flackr: this is probably the most advanced of the features, it requires the markers to be focused, and requires tab-panel navigation features so you can arrow between them<br> <TabAtkins> flackr: another feature is grid-flow, which is useful when you have content where you want to flow multiple elements into a single grid area, consecutively<br> <TabAtkins> flackr: this demo is a tabbed display. the tabs get flowed into a single grid area<br> <TabAtkins> flackr: Tab has a longer description, the short version is you can only flow into your grid parent, so it doesn't change the hierarchy of the DOM<br> <TabAtkins> flackr: and in this exapmle i had anchor links to cause them to scroll to the associated section<br> <TabAtkins> flackr: last, in many times you want to create affordances to cause scrolling, like buttons to scroll up or down<br> <TabAtkins> flackr: proposing we allow this via a pseudo so you don't have to change the semantics of your content<br> <TabAtkins> flackr: here yoru content is just a scroller, and there are pseudo-element buttons that cause scrolling up and down, and turn off autoamtically when you can't scroll<br> <TabAtkins> flackr: put all these together, and you see you get a nice little carousel<br> <TabAtkins> flackr: the nice thing is the actual semantic content is just a list of items<br> <florian> q+<br> <TabAtkins> flackr: styles are what makes it a rich scrolling carousel, which we should be able to make accessible to match your current input modality<br> <TabAtkins> flackr: I have one more example showing scroll markers showing thumbnails<br> <TabAtkins> flackr: Here using a variable for your image, and since the ::scroll-marker inherits from the element it's annotating, it can pick up that variable<br> <TabAtkins> flackr: In a future version where you can do attr() as url, we can pull the href directly<br> <TabAtkins> flackr: so that's a very quick walkthru about how we could turn a simple list of content into a usable carousel<br> <TabAtkins> flackr: i want to figure out what the best next steps are<br> <emilio> q+<br> <TabAtkins> flackr: figure out where to do the individual features, and do proposals?<br> <TabAtkins> flackr: is anything missing? hopefully my github explainer is sufficient<br> <TabAtkins> bkardell_: lots of positive things<br> <astearns> explainer: https://github.com/flackr/carousel/<br> <TabAtkins> bkardell_: this gets close to a bunch of things iv'e been interested in for a while<br> <TabAtkins> bkardell_: i have some issues to ask about, like identifying somethin in the DOM with a scroll marker, or some qs about grid-flow<br> <TabAtkins> bkardell_: but i woudln't expect everything to be crystal clear at this stage<br> <TabAtkins> bkardell_: I just like it<br> <florian> q?<br> <bramus> +1 to that<br> <TabAtkins> florian: i like it, one quick note on fragment pseudo<br> <TabAtkins> florian: we had an attempt at this, it was broader because it was also doing layout-affecting properties<br> <TabAtkins> florian: one note tho was the design wasn't fragment, it's ::nth-fragment() so you could style them differently<br> <TabAtkins> fantasai: I think it's a litle different<br> <TabAtkins> iank_: big thing we care about is getting scroll-snap-align to snap to columns rather than elements<br> <TabAtkins> fantasai: there's a ::column pseudo designed to help with that<br> <TabAtkins> flackr: there's a few things I want to improve about columns, and maybe make this vertical as well so it's kinda paged<br> <fantasai> Ah we never specced it, but see https://github.com/w3c/csswg-drafts/issues/6017<br> <TabAtkins> florian: my point wasn't about how to craete the fragments, the pseudo that lets you target them, if this ::fragment is differnt from the older ::nth-fragment, I'm not sure what the difference would be<br> <rachelandrew> https://www.w3.org/TR/css-overflow-4/#fragment-styling is the nth-fragment spec<br> <TabAtkins> florian: but we don't need to reoslve that now, this is good ideas, we might need to reconcile things<br> <TabAtkins> iank_: ::nth-fragment is strictly more complex<br> <TabAtkins> fantasai: i think you're not fragmenting the element, you're fragmenting the content into pages<br> <TabAtkins> fantasai: those fragments are anonymous<br> <TabAtkins> fantasai: in ::nth-fragment you take an element, tell it to fragment, and now you have three block boxes<br> <TabAtkins> emilio: how is that different?<br> <TabAtkins> iank_: the multicol is anonymous here<br> <TabAtkins> emilio: we have pseudo-elements targetting anonymous boxes of the element<br> <TabAtkins> iank_: right that's the ::column pseudo that fantasai is talking about<br> <nicole__> q+<br> <TabAtkins> florian: so my comment doesn't need resolution, and might be wrong since elika sounds right. we might need to coalesce in the future, but +1 for now<br> <TabAtkins> emilio: there's also a section in the explainer about inert, do we need to go thru that<br> <iank_> I suspect the `::column` pseudo would suffice here.<br> <TabAtkins> flackr: it's still an important feature - most single-item-at-a-time carousels want offscreen content to be inert<br> <TabAtkins> flackr: right now that's only thru script tho<br> <TabAtkins> flackr: if we want authors to be able to do this without needing script, we'll need css-controlled inertness<br> <TabAtkins> flackr: I have a very loose proposal on this<br> <TabAtkins> flackr: I think this could be useful for some popover cases too<br> <TabAtkins> emilio: the weird thing about inert is some things need to escape inertness<br> <TabAtkins> emilio: allowing CSS to change the semantics of that...<br> <TabAtkins> emilio: in a fullscreen context, letting the non-fullscreen not be inert if CSS overrides seems weird<br> <TabAtkins> emilio: another question, about scroll-markers<br> <TabAtkins> emilio: I'm not clear on how that works<br> <TabAtkins> emilio: the scrolling box generates the markers<br> <TabAtkins> flackr: no the marker is on the child elements, and they're auto-flowed into a special zone on the nearest scroller<br> <TabAtkins> iank_: in practice there will be a step after layout which will go explicitly insert these things into a size-contained area<br> <TabAtkins> emilio: so if you do *::scroll-marker, then everything generates markers that stash on the root scroller?<br> <TabAtkins> emilio: you'd need to add pseudo-element resolution once per element...<br> <TabAtkins> emilio: the overhead when you're not using it seems not ideal<br> <TabAtkins> emilio: just concerned about adding more ::before/after/marker<br> <TabAtkins> emilio: more unconditional pseudos can add overhead to pages that don't use the feature<br> <TabAtkins> flackr: I think we could completely skip them if there's not a scrollmarkers area<br> <TabAtkins> flackr: In my example there's a separate pseudo-element on the container that says it accepts the markers<br> <TabAtkins> emilio: right, but you'd do this.... i guess you could do all these after layout somehow, i guess that's what Ian is suggesting<br> <TabAtkins> emilio: it does mean you need to resolve the scroll-markers pseudo on all scrollers<br> <TabAtkins> emilio: and what triggers the :scroll-markers pseudo?<br> <TabAtkins> emilio: I don't see a 'content' property<br> <TabAtkins> flackr: that's a good question, i'd have to clarify<br> <TabAtkins> TabAtkins: I expect either a 'content' value, or a new property opting the scroller into it<br> <TabAtkins> emilio: yeah i think a property would make sense, so you don't need a second pass to find out what elements are supposed to generate a pseudo<br> <TabAtkins> emilio: i guess the ::scroll-marker pseudo is created for any element in the flat tree for which that scroller is its nearest scroll container?<br> <TabAtkins> flackr: yeah<br> <TabAtkins> emilio: ok, i think it's a bit complicated but it could be made to work if you don't force an extra style reoslution<br> <TabAtkins> emilio: if we could control this in a simpler way<br> <fantasai> TabAtkins: If both of these were generated only when a new property were set, would that solve the concern?<br> <TabAtkins> emilio: it would help yes<br> <TabAtkins> emilio: if people set it on the root tho you could still get a lot<br> <TabAtkins> TabAtkins: yeah but don't do bad things<br> <TabAtkins> emilio: people do tho ^_^<br> <TabAtkins> emilio: also a question about how this interacts with root scroller. maybe we just say it doesn't work?<br> <TabAtkins> flackr: yeah that might make sense. i could imagine it working, but we can see<br> <TabAtkins> nicole__: yeah like a slide deck. but this isn't trying to solve that, it's a more narrow use-cases<br> <TabAtkins> emilio: for elements not otherwise scrollable by the user, would that still work<br> <TabAtkins> emilio: the automatic scrolling buttons, like on an overflow:hidden<br> <TabAtkins> TabAtkins: you can link to things in a hidden overflow, or use scrollTo()<br> <TabAtkins> flackr: there are def carousels where devs make it so you can only scroll with the buttons, not otherwise. whether that's good or not is a decision we can make, maybe we don't generate the buttons unless there's a scrollbar<br> <TabAtkins> emilio: and similarly, more pseudo-element checks to see if any scroller needs to generate these scroller button pseudos<br> <TabAtkins> emilio: scrollbars already generate some overhead<br> <TabAtkins> emilio: but maybe similar solution to previous<br> <TabAtkins> emilio: otherwise tho seems workable, was a bit surprised to see multicol here<br> <TabAtkins> q+<br> <TabAtkins> emilio: feels a bit funky for something that isn't columns<br> <fantasai> TabAtkins: can't do carousels with multicol rn<br> <TabAtkins> nicole__: i think there's a bunch of stuff here that's hard for devs to do on their own<br> <TabAtkins> nicole__: when you think about a carousel it seems straightforward, but then responsive, and columns that can hide and show, and items can change their size...<br> <TabAtkins> nicole__: quite difficult calculations actually<br> <TabAtkins> nicole__: so anything we can do to support that would be interesting to consider<br> <TabAtkins> nicole__: last bit, expanding on what emilio said<br> <TabAtkins> nicole__: lots of use-cases for carousel in commerce. product details pages often have 6-8 carousels: previously looked at, paired products, images, etc<br> <TabAtkins> nicole__: it's probably good for the web to make commerce pages easier and better<br> <TabAtkins> fantasai: great exploation, couple of concerns<br> <TabAtkins> fantasai: for scroll markers, you're focusing on auto-generated stuff<br> <TabAtkins> fantasai: i think the first step, rather than auto-genning, shoudl be - what if the author builds a lot of elements, how can we make them act like scroll markers<br> <TabAtkins> fantasai: so my first step, rather than make a bunch of magic pseudos, is okay, we have a scroller, it has content,<br> <TabAtkins> fantasai: (like ToC in specs, wouldn't it be great to highlight the section you're in)<br> <TabAtkins> fantasai: so explore what we need to make that work<br> <TabAtkins> fantasai: and on pagination, before we dive too deeply into pagination buttons, how do we create a widget that has the correct behavior and can trigger it via js<br> <nicole__> q+<br> <TabAtkins> fantasai: if i made a button, how do i make it do the scrolls in straightforward way<br> <TabAtkins> fantasai: so my first suggestion is can we built up the affordances so someone can create the UI in the DOM, and then hook into this behavior in an easy way<br> <TabAtkins> fantasai: and then from there, can look into pseudo-elements because you don't always want content in the dom since it's presentational<br> <TabAtkins> fantasai: in terms of prior art, there was a previous proposal for overflow:paged which was implemented in opera<br> <TabAtkins> fantasai: never really made it because it didn't solve the problem of controls<br> <TabAtkins> fantasai: authors want to create controls in all kinds of ways, sometimes in the scroller, or outside<br> <TabAtkins> fantasai: miht not want the controls to be so tightly adjacent in the tree structure<br> <TabAtkins> fantasai: so autogen is nice, but we need to let authors do what they want<br> <TabAtkins> fantasai: and then when we generate pseudos, we'll have a good idea of what limitations to palce on them<br> <florian> q?<br> <TabAtkins> fantasai: wrt multicol vs dedicated overflow, latter would let you control whethe ryou want a dedicated pgup/pgdn<br> <TabAtkins> fantasai: but people do other transitions<br> <TabAtkins> fantasai: if you're flipping between cards in your carousel, is scrolling what you want? or do we need other ways to style the transition. are scroll animations enough?<br> <TabAtkins> fantasai: those are my thoughts. in terms of what to work on, i think (1) how do we want to create a pagination mode that has easy API for manipulating it<br> <TabAtkins> fantasai: and allows authors to easily build UI that will do the correct thing<br> <TabAtkins> fantasai: and on scroll marker side, how to have the behavior where it knows it's the active thing and scrolls to the correct position<br> <TabAtkins> fantasai: can we do that in a way so the interaction between them is more declarative and straightforward than it is now<br> <TabAtkins> fantasai: maybe a fully declarative binding would make things a lot easier<br> <TabAtkins> fantasai: and then from there the auto-generating part... it's a little too tied to grid at the moment<br> <bradk> q+<br> <TabAtkins> flackr: i don't think any of the stuff is tied to grid except grid-flow. you can create most bits without grid<br> <Zakim> fantasai, you wanted to comment on in-DOM scroll markers vs decorative<br> <TabAtkins> flackr: for dedicated elements, one thing that pseudos are hugely advantageous for is establihsing that link with what it does<br> <TabAtkins> flackr: a scroll button needs a way to refer to what scroller it's touching<br> <TabAtkins> flackr: which i'm open to, but we need ways to repeat it on the page so you don't need to generate unique identifiers<br> <dholbert> TabAtkins (IRC): I agree with fantasai (IRC) that whatever functionality we do here shouldn't be magically tied just to the pseudos<br> <dholbert> TabAtkins (IRC): need to have some way to invoke them from JS. Flackr mentioned getting the button from the scroller; that could be a property, or linked in the DOM<br> <dholbert> TabAtkins (IRC): having the pseudos being the only way to get the "magical" hookup is probably reasonable. we can play in that space and see if real DOM can also get a magical thing too<br> <dholbert> TabAtkins (IRC): flackr, you were talking about multicol for pagination in your examples. Is that the only pagination mechanic?<br> <dholbert> flackr (IRC): there was an idea of tying this to flex-wrap also. But there are many use-cases where the content is reflowing, and columns does everything that you want to there<br> <dholbert> flackr (IRC): I do call out in the explainer that columns doesn't address everything; e.g. you can't reserve some space to peak into space beyond current area<br> <dholbert> TabAtkins (IRC): so your big final demo, each section is filling one column, with a column-break after each one?<br> <dholbert> iank_ (IRC): expanding on the flex thing: you could imagine a flexbox row that wraps. Doesn't stack in the cross axis, but stacks in the main axis<br> <dholbert> iank_ (IRC): then, you'd need something like scroll-snap-align to target individual flex lines which don't generate fragments today<br> <dholbert> iank_ (IRC): that's *a* path, potentially<br> <dholbert> TabAtkins (IRC): in this example with 3 items visible at a time, what causes these 3 columns to be a page?<br> <dholbert> flackr (IRC): the fact that we've told them to flow them to columns. that creates an anonymous fragmented container<br> <dholbert> TabAtkins (IRC): I see `columns:1`; I'm confused about where the column fragmenting is happening<br> <dholbert> flackr (IRC): [brings up a simpler example with One | Two | Three]<br> <dholbert> florian (IRC): `columns:1` isn't "no columns". It's start with one column, and then autogenerate more<br> <dholbert> flackr (IRC): if I do `columns:2`, then it's fitting 2 per area and snapping<br> <dholbert> TabAtkins (IRC): the thing I was missing is that the 3 children are 3 inline-blocks filling a single column horizontally. Not individual columns<br> <flackr> Example is at https://flackr.github.io/carousel/examples/fragmentation/<br> <TabAtkins> nicole__: elika, sounded like starting from a version where the dev provides the markup, how would they know the number of markers?<br> <TabAtkins> fantasai: for some examples, the number of pages is dicated by content, not layout concerns. lots of carousels that are one per page<br> <TabAtkins> fantasai: we have a similar issue in specs - the ToC scrolls to the part of the spec. we don't have a binding in the other direction. when i scroll to a new section in the spec, or my carousel, i want the correct section/marker to get highlighted<br> <TabAtkins> fantasai: no connection back to the navigation<br> <TabAtkins> nicole__: like in teh bootstrap docs?<br> <TabAtkins> fantasai: yes, it's real common, but it's complicated<br> <TabAtkins> fantasai: so it would be nice to create this association, as long as you have elements that are in view<br> <TabAtkins> fantasai: so you could style the markers appropriately, and also make them clickable<br> <bkardell_> this is why I mentioned the element thing as desirable -- this is I think the same challenge with the tabs looking one I think, currently<br> <TabAtkins> fantasai: the case where you have something paginating based on how much content fits, then you might want page markers rather than content markers, we'd want to auto-gen those<br> <TabAtkins> fantasai: but on the way to that i want to make sure elements in the dom can work<br> <bramus> Note that the scrollspy pattern became easier to do thanks to scroll-driven animations.<br> <TabAtkins> fantasai: it doesn't require us to figure out nearly as much stuff before we can start helping authors<br> <TabAtkins> nicole__: I think there's a bit of danger becuase it's hard to say what's a carousel and waht isn't<br> <TabAtkins> nicole__: boundaries have blurred<br> <TabAtkins> nicole__: so figuring out which use-cases are in and which are out is good<br> <TabAtkins> fantasai: maybe, but i don't want to limit us to such a specialized use-case that you can't do more things with it<br> <TabAtkins> fantasai: building up pseudo-elements that have a very simple relationship to their originating element - kinda a pain in the ass but still relatively simple<br> <TabAtkins> fantasai: but doing more complicated things where they lay out in a way that's not directly associated with the alyout tree, that's a lot more complicated<br> <TabAtkins> nicole__: i sort of hate the way this works in form controls, with IDs and such where you need unique ids to hook them all together<br> <TabAtkins> fantasai: we've been doing bindings with scoped names in various things in CSS<br> <florian> q?<br> <TabAtkins> fantasai: but you might also want to pick up DOM relationships that are already there, using IDs or the like<br> <TabAtkins> fantasai: but i just want to see - you won't need nearly as much JS with a bunch of these abilities<br> <TabAtkins> fantasai: they can generate a few elements, and then just hook up the properties.<br> <TabAtkins> fantasai: JS is hard, if it's complex authors can screw up accessibility<br> <TabAtkins> fantasai: If we can give all the bheavior and they just have to provide markup, we're already way ahead<br> <TabAtkins> bradk: when i've heard about this, it reminded me of regions, especially the grid-flow<br> <TabAtkins> bradk: is this sorta a subset of that? or superior to that? have we considered synergy with those earlier ideas with regions?<br> <TabAtkins> bramus: even continue:fragments is sorta an alternative to using columsn<br> <fantasai> scribe+<br> <fantasai> s/bramus/bradk/<br> <dholbert> TabAtkins (IRC): I can answer about the grid-flow thing<br> <florian> q+<br> <dholbert> TabAtkins (IRC): for the grid-flow functionality, we're learning some of the lessons from regions<br> <dholbert> TabAtkins (IRC): being too open in what sort of movement you allow across DOM causes issues for layout and a11y<br> <dholbert> TabAtkins (IRC): having things reparented effectively in the DOM tree can be problematic for a11y tools<br> <dholbert> TabAtkins (IRC): for this reason, `grid-flow` in this proposal is very limited<br> <dholbert> TabAtkins (IRC): With this proposal, all the children maintain the same parent-child relationship that they had before. This doesn't change those relationships, very intentionally<br> <dholbert> TabAtkins (IRC): This is trying to avoid the issues that we ran into before<br> <dholbert> bradk (IRC): so looking at a more limited set of problems here?<br> <dholbert> TabAtkins (IRC): yup. Plus, since they're grid items, they'll be block formatting contexts, which are easier to lay out into a new container<br> <dholbert> TabAtkins (IRC): If we were piecing together non-BFC things from different places in the layout tree, there'd be much more complexity<br> <dholbert> TabAtkins (IRC): this avoids complexity, circularity<br> <dholbert> iank_ (IRC): the more we dived into use-cases here, the more we realized that stuff could just be solved by pseudo reparenting<br> <dholbert> florian (IRC): I think the situation with continue:fragment vs. multicol is similar in a way<br> <TabAtkins> florian: you might be able to do them multicol or continue;fragments, but multicol is so much simpler<br> <TabAtkins> florian: we already know how to do the multicol stuff<br> <TabAtkins> florian: and many times multicol is good enough for majority of cases anyway<br> <TabAtkins> florian: when we get to the point where we *do* need more, we can swap into that<br> <TabAtkins> bradk: yeah, was wondering if things like continue:fragments was intended to be a part of this<br> <TabAtkins> florian: I haven't looked deeply into this, but I believe that it should be psosible in the future to swap in a continue-fragments rather than multicol<br> <TabAtkins> flackr: yes<br> <TabAtkins> fantasai: rob, questions?<br> <TabAtkins> flackr: feedback has been great. we outlined a few things it would be nice to work on first, maybe scroll-markers first. what spec would it belong in?<br> <TabAtkins> fantasai: the pseudo-elements, or the scrolling binding?<br> <TabAtkins> flackr: both/either<br> <TabAtkins> fantasai: hmm, unsure. maybe scroll-snap is closest?<br> <TabAtkins> TabAtkins: yeah scroll snap 2 has some similar ideas<br> <TabAtkins> TabAtkins: but chrome has an impl trying to stabilize a few of these ideas<br> <TabAtkins> fantasai: overflow 5?<br> <TabAtkins> florian: yeah that might work<br> <TabAtkins> fantasai: it would let us centralize all the overflowing things together<br> <TabAtkins> fantasai: so i think proposal is to start overflow 5 draft, to explore paginating overflow, and scroll markers, and move appendix stuff into it<br> <TabAtkins> florian: Rob as a co-editor?<br> <TabAtkins> fantasai: yes definitely<br> <TabAtkins> fantasai: editors would be me, florian, rob<br> <TabAtkins> fantasai: comments? objections?<br> <TabAtkins> RESOLVED: Start overflow-5 draft, editors elika, florian, rob, move the fragmentation appendix from overflow-4 into it, work on addressing paginated overflow and scroll markers<br> <TabAtkins> TabAtkins: do we want to resolve about starting on ::grid-flow?<br> <TabAtkins> fantasai: maybe a separate discussion<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9745#issuecomment-1944824869 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 14 February 2024 22:25:43 UTC