- 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