- From: Dael Jackson <[email protected]>
- Date: Wed, 20 Nov 2024 19:34:39 -0500
- To: [email protected]
=========================================
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
------------
- RESOLVED: Go with option 2 and make them siblings (Issue #11125:
Tree structure of scroll container controls)
- RESOLVED: Choose option 2 [Before Markers, Buttons, Content, After
Markers] in the issue (Issue #10912: Focus order of
generated controls)
- RESOLVED: Adopt proposal in
https://github.com/w3c/csswg-drafts/issues/10738#issuecomment-2448204794
to anchor to identified elements (Issue #10738: Allowing
markers to be active even when not scrollable to aligned
position)
- RESOLVED: Use :target-current for the name (Issue #10918: Bikeshed
pseudoclasses for active scroll-marker)
- RESOLVED: Accept flackr's proposal (
https://github.com/w3c/csswg-drafts/issues/11216#issuecomment-2477472607
)
in the issue (Issue #11216: Disabled scroll-button state
and styling)
- RESOLVED: Go with Option 5 [Distribute some amount of the initial
and ending scroll] (Issue #11165: Scrolling to
unreachable scroll aligned marker positions)
- RESOLVED: Publish Overflow 5 as FPWD
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2024Nov/0017.html
Present:
Adam Argyle
Tab Atkins-Bittner
David Baron
Yehonatan Daniv
Elika Etemad
Robert Flack
Roman Komarov
Vladimir Levin
Cassondra Roberts
Alan Stearns
Bramus Van Damme
Scribe: dbaron
CSS Overflow Breakout Meeting
=============================
Tree structure of scroll container controls
-------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/11125
flackr: overflow-5 specs adds a bunch of new pseudos: scroll buttons
and scroll marker group
flackr: We have spec'd that scroll marker group acts like layout
sibling to scroll container. Buttons not spec'd that well.
flackr: I think this matters in terms of how developers can lay
things out that we define this well.
flackr: My proposal is that they are layout siblings to the scroll
container, similar to the scroll maker group
flackr: and that we have a well defined order, informed by the focus
order issue (coming later)
flackr: I want to ensure that if we do this we can still support
querying things about scroll container state.
flackr: futhark said in issue this seems fine
flackr: If making them siblings had prevented querying things on the
scroll container that would (have been/be) a concern
fantasai: I agree it's a better route in general.
fantasai: One issue was inability to use size container queries, not
sure if that would be a problem
flackr: I don't think that's a problem.
astearns: Is the issue with size containers that if they're siblings
then the size containment doesn't consider them?
flackr: I think the size containment algorithm doesn't support using
a size container query on a layout sibling
flackr: I don't think it's a big problem that you can't use size
container queries -- that particular aspect is not super
important.
astearns: fantasai, anything more on this?
fantasai: no, just stating the question.
TabAtkins: I agree this is probably the right model. It's new. I'm
interested in seeing how it works, if it's generalizable,
annoying, or something we need to keep as a special case.
ydaniv: I think big difference between second and third is what's
your container. If you're doing layout of pseudos -- with
option 3 it's the same element but with option 2 it's the
container of all of them.
flackr: I think the container for *style* purposes can still be
the same.
ydaniv: The same element, the scroller?
flackr: Yeah
flackr: In the flat tree they're sort of like descendants -- just in
the generated boxes they're siblings.
ydaniv: You mentioned being able to do grid layout -- in both cases
display:grid is on the same element and you can place them
according to the scroller
flackr: Option 1 and 3 wouldn't support grid layout.
flackr: The idea is that you have display:grid on an immediate
ancestor of the scroller -- the only way you can choose grid
areas from that if they're effectively layout siblings to the
scroller.
fantasai: In general, having them be siblings means they can take up
space in layout area outside the scroller, which is
sometimes what you want.
fantasai: That's the main advantage of making them siblings.
fantasai: The disadvantage is that you can't use size container
queries to change layout of the scroll markers.
astearns: So I'm hearing general agreement that option 2 is the best
of what we've presented so far. Shall we resolve on trying
it and see how it goes?
flackr: sounds good to me
[heads nodding]
Proposed resolution: go with option 2 and make them siblings
RESOLVED: Go with option 2 and make them siblings
astearns: ... knowing that we may come back to this if the size
containment thing or anything else proves unwieldy
Focus order of generated controls
---------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10912
flackr: We need a well defined focus order when you tab through these
generated controls
flackr: aria has guidelines for rough expectation of focus in a
carousel-like experience
flackr: this proposal aligns with that order
flackr: The buttons are together and occur before the contents of the
scroller
flackr: The marker's position is before or after the scrolling
contents depending on the scroll-marker-group property
flackr: My proposal is that the buttons... if the markers are before
they come first, then the buttons, then the content, then the
markers if they come after
flackr: see my last comment in the issue
<TabAtkins> +1 to the Option 2 in the issue
flackr: One additional thing is question of when to focus the scroll
container itself
flackr: I think it still makes sense given the previous resolution
for the container to come before the content.
flackr: so before markers, buttons, container, content, after markers
<fantasai> Seems reasonable
astearns: Haven't thought about this deeply, but the container focus
is not meant to contain the button or markers?
flackr: Right
flackr: Focusing the container is typically done to scroll the
container, so makes sense as a separate item between the
controls
vmpstr: When focusing the content that means tabbing through all the
focus items within the carousel before exiting to the after
markers
<ydaniv> +1
flackr: Correct
fantasai: By before markers and after markers do you mean ::before
and ::after pseudos?
flackr: Referring to whether scroll-marker-group property says before
or after
fantasai: I see
<TabAtkins> ::scroll-marker-group (before), ::scroll-button()s,
scroller, scroller's contents, ::scroll-marker-group
(after)
fantasai: How do we typically lay out the order of a scroll container
and its scrollbars? Is that relevant here?
flackr: The scroll bars are not in the focus order
flackr: I think if they were ???... we're treating generated controls
as siblings of the scroller
fantasai: ... seems fine
flackr: I think with implementation and practice using it we'll see
if it seems right, but this is trying to follow best
practices for these designs
astearns: What's the use of focusing markers?
flackr: User can tab to active marker, and use arrow keys to select
which marker they want
TabAtkins: Markers are links
astearns: I suppose AT could say "tab 2 of 4 is active"
flackr: Exactly
astearns: Sounds like we're converging on option 2, and we'll see how
it goes
RESOLVED: Choose option 2 in the issue
Allowing markers to be active even when not scrollable to aligned
position
-----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10738
flackr: It's easy to create a design where you can't reach the
natural scroll-aligned position of the first or last elements
in your scroller.
flackr: This leads to an odd usability issue that clicking on them
doesn't make the markers active
flackr: We have the same problem today where if you follow an anchor
link to something whose scroll position can't be reached, we
could scroll you away from that link as a result of scroll
anchoring
flackr: My proposal here is that browsers track when the scroll in a
scroll container targeted a particular element, and then use
that element as the targeted item until the user does another
scroll.
flackr: For the purposes of markers this would mean that the marker
is the first marker at or before that targeted element
<TabAtkins> https://github.com/w3c/csswg-drafts/issues/11165
TabAtkins: I was wondering how this would interact with 11165 which
is about indicating markers in the unscrollable region
that you can't reach... but I don't think it does, so I'm
good with what's suggested here.
fantasai: Overall I agree with the direction... one thing is if we've
targeted a particular element that's not the one we'd
select at this scroll position because we're further down
towards the end... the user would have to scroll back up to
shift focus to something else?
flackr: Right
fantasai: So if they continued to scroll down it would not cause it
to recalculate
flackr: They're not changing their scroll position by scrolling down
fantasai: Then this seems fine to me
<dbaron> +1 to element tracking from me to -- something I wanted to
do a very long time ago well before scroll anchoring was a
thing :-)
<fantasai> PROPOSED: Adopt proposal in
https://github.com/w3c/csswg-drafts/issues/10738#issuecomment-2448204794
to anchor to identified elements
Proposed resolution from flackr: each scrolling container tracks the
last element scrolled into view until that container's scroll
position is otherwise changed
RESOLVED: Adopt proposal in
https://github.com/w3c/csswg-drafts/issues/10738#issuecomment-2448204794
to anchor to identified elements
Bikeshed pseudoclasses for active scroll-marker
-----------------------------------------------
Scribe: TabAtkins
github: https://github.com/w3c/csswg-drafts/issues/10918
flackr: :checked is confusing (to use for the active scroll marker in
a group)
flackr: we resolved :current is better, but it also has conflation
with the other meaning of :current, and possibly used in same
context
flackr: so I've proposed we go with :target-current
flackr: this combines the fact that you're referring to the "target"
of the marker, similar to :target pseudo we already have, and
that the target is "current" in the ways we thought made
sense before.
flackr: but as a different pseudo this is separately targetable from
:current
<TabAtkins> (+1 to the name)
<fantasai> +1 to new pseudo-class, :target-* seems like a good idea,
and :target-current seems fine
astearns: You quoted that this has the potential to set precedent for
upcoming specs, do you know what was meant there?
flackr: I don't know if there was a reference to a specific other
decision
astearns: Anyone who thinks :target-current is not the right choice
and would like something else?
<fantasai> I'm also ok with :target-shown
flackr: Suggestions with "shown" or visibility have come up, I'm
shying away from those because several potential targets
might be currently visible. "current" has a stronger notion
of us determining that one is active.
astearns: Proposed to use :target-current
RESOLVED: Use :target-current for the name.
Disabled scroll-button state and styling
----------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/11216
flackr: I don't expect this to be too controversial
flackr: The scroll buttons behavior is to scroll in a direction
flackr: It seems reasonable that if the scroller can't scroll any
more in that direction, the button should be disabled
<fantasai> +1 to the proposal
flackr: Consistent with ARIA recs for prev/first buttons in a
carousel. Not inert, disabled; my understanding is AT treats
them differently.
flackr: And they should apply a disabled style; the UA style will
match the button disabled style
argyle: Agree this is user expectation. not making it inert is good
so it doesn't just disappear.
argyle: [rereads his own comment]
<astearns> https://github.com/w3c/csswg-drafts/issues/11216#issuecomment-2477358595
argyle: Ah, this was in competition with the "cyclical scrolling"
argyle: if you're in netflix or something, they don't stop you, they
cycle back to the other side
argyle: either flipping back, or virtualizing to make it infinite
scroll
argyle: It's nice, but we should follow aria behavior here
argyle: devs can build another behavior if they want it
argyle: Other concern is, the buttons are siblings, so I thought they
couldn't tap into the scroll-state query
argyle: but they can, per Rene
argyle: so that's a healthy default.
flackr: I'm fully supportive of enabling cyclical scrolls, but I
think we need to extend the Overflow model for that
argyle: Agree
<fantasai> +1 flackr, exactly why I was on the queue
<vmpstr> +1
argyle: Maybe if that value was present these buttons didn't disable
flackr: Yes, they'd change behavior because there is no end
TabAtkins: How do you select them when they're in the disabled state?
flackr: :disabled
TabAtkins: Cool
fantasai: Strong +1 to everything rob just said about how looping
scroll should work
argyle: In the UA, is there a scroll-state query, or is this a magic
pseudo-state instead?
argyle: So if I didn't want it disabled on the edges, how do I
opt out?
flackr: You could remove the disabled styling using :disabled
flackr: but they'd still be disabled buttons. Unsure what you'd
expect them to do. In the future we could target them with
event listeners and add custom handling
flackr: but right now you can't listen for events on the buttons
argyle: Gotcha, so for this version, the scroller buttons will
automatically disable at the edges. You can style
differently, but they're still disabled. Until later when we
have other overflow behaviors.
flackr: Or until we start selecting in JS the pseudo-elements, or
some other way of listening to events on pseudos
[some discussion about getComputedStyle()'s pseudo argument)
astearns: I think you can put a listener on the host and check where
the click was...?
flackr: You can't actually tell the click was on the pseudo unless
you determine from the position
argyle: Same as ::backdrop, yeah
dbaron: I was discussing this with Mason a few days ago
flackr: Yeah we should fix it
dbaron: Mason ran into this exact problem last week
flackr: So in a future we fix this you could hook into the buttons
and do something else
argyle: [re-summarizes]
argyle: And it's styled as a button, but with text contents... I
guess that's a different issue
argyle: Sounds good overall, good defaults
astearns: So desired resolution?
flackr: apply the disabled behavior and style when you can't scroll
further in the associated direction
astearns: objections?
RESOLVED: Accept flackr's proposal in the issue.
<dbaron> (I think the discussion I mentioned with Mason was about
https://github.com/whatwg/html/pull/10737 which actually (I
think) ended up putting the click rect check in the spec PR!)
Scrolling to unreachable scroll aligned marker positions
--------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/11165
flackr: This is similar to the earlier issue. I have a demo page with
some options
flackr: It feels bad when you scroll that there are certain markers
you just can't reach
flackr: The best compromise to handle this, short of the developer
choosing to add extra padding, is to hijack the first and
last "some amount" of scrolling (arbitrarily chose 1/8 of the
scrollport width), and distribute that proportionally to the
items before the first reachable scroll position, and same
to end
flackr: so at position 0 you'll have the first marker selected, then
you'll quickly zoom through the unalignable markers, and then
hit the first alignable marker.
argyle: If you're using scroll snap as a selection mechanism, this'll
still be frustrating, but if you're just like browsing and
the dots are highlighting as you scroll, it's not too bad.
argyle: So squishing down and virtualizing the amount of scroll to
hit the remaining snap points seems reasonable
astearns: How does this interact with the previous resolution?
astearns: Through a non-scroll action you've activated the second
item. Is the scroll position now not 0?
flackr: My proposal is this doesn't change, it's still 0. but the
moment you scroll, it'll jump to the first item (via this
issue's calculation)
astearns: So I've navigated to item 2, I scroll to the right, my
expectation is I'll go to item 3
flackr: Yes, but you'll actually go to item 1. Same as previous
issue, several items conceptually at position 0, and as soon
as you do a non-targeted scroll, it does a calculation (based
just on scroll state) to find the active marker
TabAtkins: I do recommend rolling through the demos in flackr's page
TabAtkins: once you play with them and realize how bad the behaviors
all are
TabAtkins: you realize this gives you smooth behavior as you scroll
TabAtkins: it's not a perfect solution, but it's the best by a long
shot
TabAtkins: all the others are actively terrible, just a little
awkward, way better than the others
argyle: At least scroll padding, there's no magic. Maybe there's
extra space, but everything aligns, there's no edge cases, etc
flackr: I fully support guidance to say ideally make all your
positions reachable. but I think it would be extremely
breaking to force extra padding to your scroller.
argyle: It is annoying to add padding; flex and grid do some weird
stuff
flackr: There's a linked issue to make that easier
vmpstr: So if the first two markers aren't reachable, as I approach 0
scroll offset but not at 0, the marker would switch to the
second, then the first...?
vmpstr: Why not then if I click the second marker, it would position
me at an offset that would show the second marker selected?
flackr: That has interactions with other specs
TabAtkins: [explains how scroll snap makes this situation untenable]
TabAtkins: You can't be in-between items when snapping is on
flackr: Unless we did some sign if work with scroll-snap, I think
that would be even weirder
argyle: The goal is to have the perceptual marker match the end of
scrolling... are we sending snap changing events?
argyle: There's like four dots I can't rest at...
TabAtkins: If your thing relies on actually being able to snap to
every item, you need your layout to allow for snapping to
those items
TabAtkins: we can't do anything to make that possible other than
adding padding, which would break things
TabAtkins: There's an unwinnable situation here, need to compromise
somehow
argyle: Okay I'm interacting with them, they all seem to hijack my
scroll in some way, 4 is the first item that snaps...
argyle: Is option 5 everyone's choice for the least evil option?
<bramus> SGTM
<TabAtkins> (yes, for me)
argyle: On mobile does it get really weird?
flackr: My proposal uses a % of the scrollport width so it scales
with the size
argyle: Thanks for the demo page, this experience speaks a thousand
words
argyle: So these wouldn't emit snapchanging?
flackr: Right because they're not snapped
argyle: Okay but they just indicate visually
argyle: Still a little bad but a compromise
flackr: When we support using real elements as markers, you'll also
be able to use this to get those things indicated
astearns: So are we resolving on the least-bad option?
flackr: Proposed is option 5 as the best we can do without breaking
content. If we come up with something better in the future,
we can consider changing it.
flackr: This does currently live in a non-normative part of the spec;
we decided active marker calculation would be non-normative
until we're happy with it. Seems not too hard to change if we
change our minds.
astearns: So proposed resolution is option 5. Objections?
RESOLVED: Go with Option 5
Publication
-----------
github: https://github.com/w3c/csswg-drafts/issues/6900
fantasai: I have a vague recollection we resolved on a FPWd of this,
but we don't have one yet. Am I misremembering?
flackr: I know we talked about it, but I thought we wanted some of
the core issues sorted out first
fantasai: No, I think we just wanted some cleanup in the edits
flackr: I see, I did do those clean-ups
fantasai: The draft should be understandable at FPWD, but doesn't
need all issues solved, that's CR
flackr: Ok. I don't think we actually resolved on a FPWD publication
astearns: So the proposed resolution is we take up FPWD of Overflow 5.
RESOLVED: Publish Overflow 5 as FPWD
Received on Thursday, 21 November 2024 00:35:13 UTC