- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 28 Aug 2024 19:59:21 -0400
- To: www-style@w3.org
========================================= These are the official CSSWG minutes. Unless you're correcting the minutes, Please respond by starting a new thread with an appropriate subject line. ========================================= CSS Overflow ------------ - flackr went over the current explainer for scroll markers (issue #10720) looking for support of the general direction. The group discussed some feedback and history of the issue and was broadly supportive of the direction. Any issues with the explainer can be opened separately in github for further discussion. - There was no clear winner between the options to address scroll snap on content such as auto paginated fragments (Issue #10715: Snapping and generating scroll-marker pseudo-elements from fragments). flackr will write up a third option that was raised on the call and fantasai will add comments to the issue. - Issue #10722 (Scroll button pseudo-elements) is a problem space the group is interested in solving. The current proposal would benefit from more documentation of in and out of scope use cases as well as additional details in the proposal. - RESOLVED: Blockification of -webkit-box happens at computed value time (Issue #10435: When does the blockification of -webkit-box occur?) ===== FULL MEETING MINUTES ====== Agenda: https://lists.w3.org/Archives/Public/www-style/2024Aug/0017.html Present: Rachel Andrew Adam Argyle Tab Atkins-Bittner Kevin Babbitt Oriol Brufau Emilio Cobos Álvarez Yehonatan Daniv Elika Etemad Robert Flack Daniel Holbert Jonathan Kew Roman Komarov David Leininger Alison Maher Cassondra Roberts Miriam Suzanne Alan Stearns Brandon Stewart Josh Tumath Bramus Van Damme Sebastian Zartner Regrets: Chris Lilley Lea Verou Scribe: bramus Admin ===== astearns: Changes to agenda? bts: Can we defer grid-gap discussion? astearns: I noticed Elika and Oriol aren't here yet, so was planning on skipping over anyway <dbaron> but I'd like to discuss css-values-5 publication <dbaron> we resolved 2 weeks ago <dbaron> to publish FPWD <dbaron> Chris thought that fantasai was going to send the transition request <dbaron> but I'm not entirely sure <dbaron> so I'd like to know who will send the transition request and if I should astearns: I will follow up with Chris and Elika on that to make sure someone sends a request CSS Overflow ============ Scroll Markers -------------- github: https://github.com/w3c/csswg-drafts/issues/10720 flackr: We previously discussed the issue of a broad set of ways to make it easy for devs to author carousels with css flackr: This is one of the features of that flackr: Goals is to have a simple way for devs to create nav markers. Typically dots in carousels flackr: but also useful for TOCs flackr: or tabbing mechanism when you have a scrollable tab container flackr: have written up a spec in css-overflow-5 as previously resolved. flackr: Idea is that scroll markers behave as anchor links flackr: but they have one main additional component is that you can track which one is the active one flackr: so for a group there is an extra style that applies to the “current one” flackr: you can also create the groups as pseudos automatically for pagination scenarios based on fragmentation flackr: Issue is here to get attention on this and to bring everyone up to speed flackr: How this could work with regular elements ??? by having groups of links flackr: Is focus group the right thing or should we have a group name (for a later discussion) flackr: Already have 1 proposal in the spec and want consensus on the direction <TabAtkins> +1 from me, I'm very happy with this. Still some work to do but I think the current approach and syntax is good kizu: Left a comment, like the idea kizu: There is a lot of things with related issues kizu: One aspect that I think could be quick win kizu: to split off highlighting of currently applied marker kizu: For all TOCs this would be useful kizu: Had a lot of need for this recently kizu: TOC, tab list, etc kizu: need JS for that now with IO kizu: can also use SDA but that's a hack kizu: This one thing could be useful to split off flackr: Hadn't got chance to respond on issue yet flackr: In order to do auto selection it requires to have a grouping mechanism flackr: because active item needs to know which group it is in flackr: so that TOC doesn't interfere with set of inline links flackr: I don't think that auto creation adds a whole bunch of complexity flackr: if we just focused on active state, then we might forget to allow auto creation flackr: You also mentioned you would like template instantiation flackr: Feels like a good thing for filling in content for pseudo elements generally flackr: something that could be augmented later for markers (and ::before, ::after, etc) flackr: It's not mutually exclusive to have pseudos for this now flackr: having whole thing in spec also doesn't mean vendor has to implement the whole thing flackr: do see value in having it all specced out now florian: Way back in the day opera had tried (for fragmentation use case) to have these markers be auto generated or to have an API for devs to suppress that florian: As far as I remember there was no pseudo element florian: not saying we should be doing anything like this <florian> https://www.wiumlie.no/2011/reader/ florian: Want to raise awareness about that effort florian: could give some ideas flackr: Wasn't aware of that specific case but have feedback that authors don't want to write JS to create stuff like this flackr: Do see value in purely declarative setup for this florian: Absolutely florian: Link I shared is either fully automatic or JS florian: JS override might be nice florian: For context: broader thing back then was to be able to opt in to pagination as an alternative to scrolling florian: they wanted that feature in that context florian: Again, purely sharing for awareness reasons and back-history astearns: Where are you with other bits of the process? astearns: Implementing things? sending intents? is this getting TAG review? flackr: Of course it will go through TAG and what not flackr: Have a partial experimental thing in Chrome flackr: to prove that we can have focusable pseudos flackr: and that it supports these use cases flackr: Should add a few links with concrete demos in the issue flackr: That's where we are at flackr: Want to get consensus on specific shape to push this forward flackr: make sure everyone is happy astearns: Other questions or comments? fantasai: Great ? to to work on. Spec needs a bit more explanation. fantasai: Makes sense to have ability to have an existing anchor to be both a scroll marker and also having the pseudo fantasai: spec doesn't do a good job of pulling this together in coherent model fantasai: (editorial criticism) fantasai: Makes sense to pursue this direction fantasai: with a little bit of work on the editorial side this would be a reasonable FPWD astearns: Cool astearns: What else do you want for this issue, rob? flackr: Please open individual issues on the proposal flackr: will make work of editorial work astearns: So you don't need resolutions? flackr: We already have a resolution to work on this (back in February) Snapping and generating scroll-marker pseudo-elements from fragments -------------------------------------------------------------------- github: https://github.com/w3c/csswg-drafts/issues/10715 flackr: One of the things that came up how devs can author content around auto paginated fragments (cols or page fragments in the future) is how do you actually attach scroll markers or snap styling? flackr: or other things? flackr: There is three general directions flackr: The overflow spec already has mention of styling fragments flackr: has an nth-fragment selector but there are internal concerns about it flackr: One option to have a fragment selector that applies to all fragments flackr: Second option to make the individual properties fragment aware flackr: already have issue for scroll-snap-align flackr: (firefox and and chrome differ) flackr: Could decide that this is a nice way to turn fragments into snap areas or markers flackr: Third option is a different syntax to make the property aware of fragments flackr: (code in issue) flackr: Second option is nice and simple flackr: at least for snap areas: snap areas per fragment box flackr: Can do same for scroll markers but feels weird flackr: Maybe can go for something different? flackr: This is the way to go or should be pursue fragment styling? <TabAtkins> I don't have a strong opinion on this, but I support the use-case. <TabAtkins> Doing it via a non-numbered ::fragment, to avoid implying different styling on fragments, seems useful astearns: Also support the use case like but don't have feedback on choosing astearns: Anyone with better opinion? fantasai: I think a generic ::fragment representing column in multicol is confusing fantasai: because we have several different ideas about fragmentation and multicol as one type of thing that creates fragments in a container fantasai: I think ?? set scroll-snap-align on column makes sens but should do that with column pseudo element <rachelandrew> +1 for scroll snapping on columns, we have issues for that. fantasai: One of the discussions in overflow spec was to have nth-fragment pseudo element fantasai: it represents instances of the block through which the content fragments fantasai: Very different concept from multicol cols which are boxes fantasai: inside the ?? <astearns> (discussing the overflow: fragment proposal) fantasai: Don't think scroll snap align should target column when you set it on multicol fantasai: should target the col that allows the snap property on ?? flackr: That is not what is listed in the issue flackr: for option 2 it is saying that if you set scroll snap align on the in the multicol flackr: then should it generate are snap area per generated box fantasai: Don't have good answer to that flackr: To be clear: not to set scroll snap align on the thing establishing the multicol flackr: Question is whether setting those should have an effect per fragment flackr: Could be per property fantasai: Yes, transforms and borders for example differ flackr: Brought it up as one possible way flackr: if you want to snap align, you can wrap everything in multicol and then have scroll snap align fantasai: It would be better to set scroll snapping on the columns themselves fantasai: on last col it would be kinda weird fantasai: as content could be shorter than the others flackr: Yes, so vertical center would align differently iank: There are use cases for if you have a fragmented box somewhere within multicol to generate a snap area per fragment iank: so that would still be useful iank: Option 2 if we agree that generating snap are per fragment is strictly better behavior (like firefox) … could resolve on that iank: other prior art is box-decoration-break iank: Don't think that makes … could explore that route iank: producing snap area per ? might be better behavior flackr: Would solve the snap problem, flackr: also need to decide on scroll markers astearns: So proposal to resolve on option 2 for snap areas astearns: which would be in line with how firefox behaves flackr: Yes <fantasai> I'm not sure, in a multicol it might make sense to use the bounding box as the snap area astearns: any concerns with that? or more time needed? astearns: do you mean bounding box of all of the fragments, elika? <fantasai> yes <fantasai> if you imagine for example the use case of highlighting something <fantasai> and then snapping to that highlighted section astearns: (chair hat off) Agree with Ian that there are use cases for snapping 2 fragments individually astearns: So Elika I think you’d rather not resolve and take it back to issue? fantasai: Yeah, not sure what to … e.g. article inside scroller and highlighting function to highlight things … would you expect to snap to each one individually or the whole region? not sure fantasai: Don't have objection to resolve on ?? flackr: A thing I heard is that you would be happy with something like option 1 if we had a selector based on columns instead of fragment? flackr: Is that correct? flackr: Would be happy to take that as a direction to pursue <fantasai> I think we should solve the column-snapping problem directly <fantasai> and for fragments within the columns, address them also directly <fantasai> not as a proxy for the column-snapping iank: Don't think that solves all the use cases like snap align flackr: Agree, there is a separate issue for snap areas flackr: Could continue to pursue for fragmented snap area boxes flackr: I think we can solve a lot of the use cases that I am trying to address with orig issue by having a ::column selector for example flackr: to create some style for the area bramus: Heard requests for grid on that bramus: Would that also work there, or only for fragmentation? iank: No, probably not iank: Other thing: iank: If we agree that both cases are useful for scroll snap align, then proposal 3 where we say scroll-snap-stop per fragment vs not iank: Need to decided on default behavior for scroll marker ?? iank: because one thing here is that if we go with ::column that would initially only be valid on scroll marker group and scroll snap align (?) astearns: So hearing all three options are still in play astearns: let's take back to issue astearns: can you add comments to all options, fantasai? ACTION: fantasai to comment on the options astearns: because there are some unanswered questions ACTION: rob to write up ::column option Scroll button pseudo-elements ----------------------------- github: https://github.com/w3c/csswg-drafts/issues/10722 flackr: Other major UI component frequent in carousels is having buttons that scroll you through the content flackr: also in scrollers in general sometimes flackr: next/prev page, scroll up/down, … flackr: Proposal is to allow devs to create these with a pseudo-element <TabAtkins> Big +1 on this, with the only caveat being that we super need this ability captured in a property *as well* which we can put on normal elements (with some suitable restrictions for a11y/usability) flackr: few options for what that might look like flackr: and many open questions flackr: e.g. focus order flackr: seen examples of many different way of setting up these buttons flackr: Want to get some attention on this to figure out if we would be happy to pursue this flackr: and also some thoughts on specific questions florian: Feedback on general idea: on the one hand yes, people do add these buttons florian: proposal goes much broader florian: For scroll buttons, reminds me of something that I wanted to do when overlay scrollbars were new florian: because those scrollbars hide themselves, I wanted to add styles on the element so that users could see that it was scrollable florian: gave up because I was fighting the UI florian: Similarly the trend is no longer to have scroll up/down buttons ... these are useful and users can bring them back (OS setting) or is this a feature devs should bring back? florian: Feel that is is unfortunate that we are fighting back through author space on features that UAs have removed, then again it is useful flackr: In most cases where authors these, they look nothing like the thing the UA provides flackr: Main use case is to recreate native scrollbars flackr: probably are cases that do that, but mostly site specific things florian: Fact that they look different is not necessarily diagnostic florian: what I used to do back in the day also looked very different from the removed browser UI, I wouldn't have done that if browser kept original UI TabAtkins: Like it, dropped syntax nit suggestion in the issue TabAtkins: The ability to trigger scrolls in whatever direction should be dropped onto a property so that we can put these on real elements too TabAtkins: having pseudos makes sense too TabAtkins: Figuring out restrictions is a little bit more complicated on those elements, so having only pseudos is fine too flackr: Can do this with invoke action on buttons TabAtkins: Sounds reasonable SebastianZ: Also am reminded of the popover approach SebastianZ: fits more to HTML so that we could introduce HTML attrs that would trigger scroll and then those elements could be style in any way astearns: Want to address q3: absolutely astearns: should design so authors can use scroll-start and scroll-end bramus: Addressing florian's remark bramus: where he wanted to recreate classic scrollbars, think that's part of another discussion we already have an issue for bramus: where authors want control over overlay vs classic scrollbars bramus: so maybe something to discuss in that issue florian: I wasn't so much pointing out that authors want to recreate classic scrollbars, but rather react to scrollbars being less useful as time goes by fantasai: I understand the desire to create these buttons using css fantasai: Proposal is probably way too simplistic fantasai: How much are you going to scroll by? fragment? page? part of page? section? next scroll marker? fantasai: lot of different amounts fantasai: Question about relation to each other and what order to they appear compared to other pseudos? fantasai: lot of option questions fantasai: proposal for 2 pseudos with page-up/down is a bit too simple to address problem space fantasai: Don't have a good solution do we want to make this more complicated now or? – don't know what makes sense here fantasai: but see a lot of variation of what users want to do and think we need to capture those needs flackr: Did mention everything you mentioned as a list of open questions flackr: definitely underspecified at this moment flackr: question is not to resolve, but for me to go formulate answers to all those questions and then take it back astearns: I suggest yes: work on the questions and need to figure out the details florian: Do think it is worth exploring this, authors will do this anyway, and it'll be more robust if we provide features in that space that help florian: also UAs, make scrollbars useful please astearns: We not only need the questions astearns: we need the group of usecases that we are trying to solve astearns: maybe a group of usecases that is out of scope astearns: discussing things in terms of what the author wants to do flackr: excellent feedback astearns: so we take this back? When does the blockification of -webkit-box occur? -------------------------------------------------- github: https://github.com/w3c/csswg-drafts/issues/10435 emilio: About -webkit-line-clamp right? emilio: turned that into -webkit-box emilio: if you have right set of conditions then ?? BFC, but should that blockification happen? emilio: At what time? ?? time or computed value time? emilio: Main argument for doing at computed value time is that it is more consistent with things like display block emilio: it makes gCS not lie iank: Looked into why we did it like that iank: Result of us being conservative because we did it first iank: so emilio you haven't had any compat issue due to doing it at this time? emilio: Never iank: Would be fine to changing at computed value time with caveat that we don't run into issue PROPOSED RESOLUTION: blockification of -webkit-box happens at computed value time astearns: Objections? RESOLVED: blockification of -webkit-box happens at computed value time
Received on Wednesday, 28 August 2024 23:59:54 UTC