- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 22 Jan 2025 19:40:22 -0500
- 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 Breakout
=====================
- RESOLVED: Spec scroll-marker-contain (Issue #10916: Creating
scroll-marker groups within which to select an active
marker)
- RESOLVED: Adopt everything in the Oct 30 comment
[
https://github.com/w3c/csswg-drafts/issues/11098#issuecomment-2447214498
]
(Issue #11098: What is the active :checked marker when
some markers point to elements within different scrolling
containers?)
- RESOLVED: Only propagate the scroll into view for a scroll marker
up to the common ancestor scroller of the targets (Issue
#11138: Limit scrolling to the associated scroll
container when activating a marker)
- RESOLVED: For a 2D scroller, we will define an algorithm that uses
a primary direction that defaults to the block axis
(Issue #11198: Active marker in 2d scroller?)
- RESOLVED: ::scroll-marker-group applies containment when it is
in-flow only (Issue #11166: Can we relax size containment
on ::scroll-marker-group?)
- RESOLVED: The document.activeElement is the scroll container for a
focused ::scroll-marker or ::scroll-button. :focus
matches only on the specific focused pseudo-element.
:focus-within matches on the ::scroll-marker-group for
::scroll-marker, and the scroll container and all
ancestors for both ::scroll-marker and ::scroll-button
(Issue #11361: :focus and :focus-within styles with
focused scroller pseudo-element)
- There were some concerns expressed that the proposal for issue
#10868 (What counts as "immediately preceding" for
`block-ellipsis`?) would create inconsistent definitions,
however time ran out before the group could discuss further.
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2025Jan/0012.html
Present:
Rachel Andrew
David Baron
Andreu Botella
Emilio Cobos Álvarez
Elika Etemad
Robert Flack
Roman Komarov
Florian Rivoal
Alan Stearns
Miriam Suzanne
Scribe: andreubotella
CSS Overflow
============
Creating scroll-marker groups within which to select an active marker
---------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10916
flackr: We want to be able to make scroll markers out of existing
anchor lines, and this proposal is to add a property
scroll-marker-contain to set on an ancestor that contains all
of the links in a group of scroll markers
flackr: What that means is, one of those links will have
:target-current match
flackr: From the get-go we agreed that this would be the case for (?)
elements, so would this be the case for all elements?
flackr: this would be the thing authors would need to set on their
table of contents
florian: You put it on the table of context, and how do we determine
which one's current?
flackr: Based on the position of the anchor scrollers
flackr: this is the same algorithm we use for the pseudo-element: the
first one that (...)
florian: Is there a risk that, because it's an element rather than a
pseudo-element, it might have contents that are moved out of
the way?
flackr: I suppose there's a possibility that you could have a
:target-current style that causes the target to no longer be
current
flackr: it would cycle at the same interval as :hover, it's not a
tight cycle
flackr: because we're using the position as determined before doing
style and layout
<fantasai> "An element having scroll-marker-contain: auto is a scroll
marker group container establishing a group of all of the
scroll marker elements for which the element having
scroll-marker-contain: auto is the nearest ancestor scroll
marker group container."
florian: I guess you would have to scroll again to reevaluate that
and break the loop
fantasai: We need the grouping because we need to compare the
different targets in the group
flackr: Yeah, we need to compare the different targets to the scroll
position to see which is the target
fantasai: What are your thoughts about using the keyword auto?
flackr: It's a keyword which implies "do something semi-smart"
fantasai: Is it an on-off value?
flackr: Yes
emilio: By resolving on this, are we also resolving on how the
targeting would happen?
emilio: I don't know how this would work with the common ToC use cases
flackr: We have had discussions about that, but we need a mechanism
to determine which target location is current
emilio: But for this property, the target locations would be
everything (...)
emilio: If the thing that contains the target is a link to a header,
does it do the right thing?
flackr: Yes
kizu: Do we need anything special for two nested scroll container?
kizu: Two containers, one of which has a scroll list
flackr: They would be treated as separate lists
flackr: For common cases, I suspect you would not make the one a
separate list, and you'd use (...) to style the outer list if
something in the inner is current
kizu: If we have a ToC with nested items, we could do two nested
containers, and the inner one would only listen to the elements
inside
flackr: having the property be able to be nested the way it is, you
could have the property in a (...) contain group
flackr: even the ones that are not in view would have a contain item
flackr: but I suspect you'd only want to use one list
flackr: but there are use cases for multiple list with a single
active item
florian: What about multiple links to the same target? do they all
become current at the same time?
florian: in a typical ToC example, you typically wouldn't, but maybe
depending on how you construct it, both the number and the
title are separate links
flackr: I think I set the first one is :target-current
flackr: if we can agree at a high level this sounds good, and then we
can figure out details, that would be great
PROPOSED RESOLUTION: Spec scroll-marker-contain
florian: having spec text will enable these discussions better
RESOLVED: Spec scroll-marker-contain
astearns: This is specifying just auto?
flackr: `auto` and `none`. we can decide if that's the right name
<fantasai> Yeah, I think we need to think about that `auto` keyword
What is the active :checked marker when some markers point to
elements within different scrolling containers?
-------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/11098
flackr: With scroll markers created by anchor links, we can link to
scroll targets created in various elements
flackr: How do we determine what's the target created by
:target-current?
flackr: My proposal, if the scroller is not considered to be current,
none of the markers within it are current, and if it is, you
check the subscrollers
florian: Makes sense to me
florian: I wonder if a similar logic could be used for the discussion
in https://github.com/w3c/csswg-drafts/issues/10916: only
things in the nested one match if the scroller is currently
marking
flackr: That would work
flackr: fantasai's comment about the siblings case is that, with two
scrollers only one of them is current, and only the target
within the scroller is given :target-current
flackr: that use case might be better served by multiple scroll
contain groups
flackr: not sure if you'd want to have more than one scroll marker
within a scroll target group
fantasai: If you have one scroller, and the subscrollers are in
sequence, and it's clear one is active and the others
aren't, that makes sense
fantasai: but what if you have a 3-column view and one is the ToC and
the others are scrollers?
fantasai: I'm fine starting with this and see what crazy ideas kizu
comes up with
flackr: I'm not sure what I'd even expect in that case
florian: This is a common theme with this proposal, many ways you
could design it, but we need to pick a design you'd use in
most common cases
florian: and then get author feedback
florian: I don't think there's a generic solution that handles
everything
PROPOSED RESOLUTION: Adopt everything in the Oct 30 comment
fantasai: and wait for kizu to experiment :)
RESOLVED: Adopt everything in the Oct 30 comment
Limit scrolling to the associated scroll container when activating
a marker
------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/11138
flackr: When you have scroll markers as part of a control that are
scrolling some scrollable area, it's not expected that
scrolling that thing scrolls things outside it
flackr: authors often expect that scrolling a container only scrolls
inside that container
flackr: limit scrolling to the common scrolling container of the
markers
<fantasai> sgtm
flackr: there are some related issues, but we don't have to discuss
them here
kizu: +1
kizu: one common case if we don't do this – a ToC that is a sidebar
on mobile but on top on desktop, you don't want the scroll
section to go back up
PROPOSED RESOLUTION: Only propagate the scroll into view for a scroll
marker up to the common ancestor scroller of the targets
RESOLVED: Only propagate the scroll into view for a scroll marker up
to the common ancestor scroller of the targets
Active marker in 2d scroller?
-----------------------------
github: https://github.com/w3c/csswg-drafts/issues/11198
flackr: Determining what is the current target is typically done in a
single access in most scrollers
flackr: However, you can have a scroller that scrolls both
horizontally and vertically
flackr: We need to define something that works well for the plain
horizontal and vertical cases, as well as combined cases
flackr: Proposal to have a primary direction, where we choose that
axis first and choose the current position in that axis
flackr: and for every target which is current in that axis, you check
the secondary direction
flackr: Currently primary axis follows writing-mode, but we have
discussed horizontal scrolling
astearns: Using the primary direction first is simpler, but are there
case where the proximity in the minor axis is much closer
and it'd make sense to use that?
flackr: My temptation is to avoid having too much complexity until we
determine there's a need
flackr: My preference is to do this major, then major axis solution,
and only consider other things if there are use cases
PROPOSED RESOLUTION: Define this algorithm in terms of the primary
direction, which would be the block axis
flackr: This is in the spec as a recommended algorithm
flackr: Maybe we should have a separate issue for making it normative
flackr: Maybe the best thing would be to put the requirements
normative, but the algorithm non-normative
fantasai: This seems reasonable for document that primarily scroll in
one direction
fantasai: but what if you have a small viewport in a larger one?
flackr: As long as the tiles are aligned in the primary axis, it'd
work as expected
flackr: This gets less good if your tiles are not aligned in a grid
(e.g. staggered)
flackr: That would select based on the primary axis, which might not
be best always
fantasai: We should take into account what's on the screen
fantasai: Based on primary direction, it'd be good as long as you
can't target things you can't see
flackr: Targeting things you can see is important for headers of a
section, which might be scrolled out of view while in the
section
flackr: if you're making something 2d, maybe you don't want scroll
markers
flackr: most use cases would be 1d
florian: What if there's a 1d path laid out through 2d in some way?
kizu: Maybe we could have a switch for behavior, selecting one marker
vs several
kizu: In 2d it could be useful if you have multiple selected elements
in a grid
kizu: but we can experiment later
flackr: We have had mentions of a different selector to match
multiple, which could be useful in that case (e.g.
:target-visible)
PROPOSED RESOLUTION: For a 2D scroller, we will define an algorithm
that uses a primary direction that defaults to the block axis
RESOLVED: For a 2D scroller, we will define an algorithm that uses a
primary direction that defaults to the block axis
Can we relax size containment on ::scroll-marker-group?
-------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/11166
flackr: The :scroll-marker-group pseudo class is spec'd to have size
containment to avoid cycles in the number of established
scroll markers
flackr: but that's a common pitfall for authors, since if they forget
to set an explicit size, it doesn't behave as expected
flackr: Can we relax that?
flackr: The common case, you are making a target group out of (...)
and the size doesn't affect the scroll container
flackr: Can we make the containment conditional on whether it's
out-of-flow positioned?
florian: I don't have an issue, the whole point of containment is to
make it easier to reason about this, and this doesn't make
it easier
florian: I'm not familiar enough, but don't you need layout
containment as well?
flackr: You need it to not affect the size of the container
florian: If its size doesn't change but it's not an IFC and you have
a float poking out of it, and the float's size changes, it
could jumble the content around it
florian: so I suspect you also need layout containment
florian: Making size (and possibly layout) containment conditional on
out-of-flow sounds good to me
florian: but even if your position not changing is fine, is it a
problem if your content scrolls too far and causes
scrollbars to appear?
flackr: Not a problem, once scrollbars appear we don't remove them
florian: You could have subtle interactions that break what you
thought was a guarantee
emilio: What's the use case for getting them in flow? if 99% of use
cases require them to be out of flow, shouldn't we always
have containment?
flackr: You need it to be in-flow if you want to put your scroll
marker group in a grid area, and have it have the correct
size, which is relatively common
flackr: I could see leaving that as an open question
flackr: Maybe resolve to do this switch, but consider if there are
legitimate use cases for in-flow position
emilio: We can do this magic to force containment if not abspos, and
contain is already a magic property with interactions
astearns: If the problem is that the size containment is unexpected
for authors, then having it be unexpected only in abspos
makes the problem worse
florian: but for in-flow, it's unexpected and unnecessary
PROPOSED RESOLUTION: scroll-marker-group applies containment when it
is in-flow only
RESOLVED: ::scroll-marker-group applies containment when it is
in-flow only
astearns: As for whether we also need layout containment, we'll have
another issue if that is a problem
:focus and :focus-within styles with focused scroller pseudo-element
--------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/11361
flackr: Scroll markers and scroll buttons are focusable, and we need
to have reasonable behavior for the active element and :focus
and :focus-within pseudos
flackr: the focus element has to be an element, or it would break
existing content
flackr: similar to shadow dom
flackr: similar to shadow dom where the host is focused, the
scrolling container is the host of the pseudo elements
flackr: The :focus and :focus-within pseudos follow the existing
behavior, so :focus only matches on the pseudo which is
focused, and :focus-within matches on the scroll container
and the scroll marker group
flackr: and any ancestor of the scroll container
flackr: If you have a focused element, that's the thing that has
focused and the ancestors have :focus-within
flackr: This does the same for pseudos with the requirement that it
needs to be an element
<flackr> Proposed resolution: The document.activeElement is the
scroll container for a focused ::scroll-marker or
::scroll-button. :focus matches only on the specific focused
pseudo-element. :focus-within matches on the
::scroll-marker-group for ::scroll-marker, and the scroll
container and all ancestors for both ::scroll-marker and
::scroll-button
RESOLVED: The document.activeElement is the scroll container for a
focused ::scroll-marker or ::scroll-button. :focus matches
only on the specific focused pseudo-element. :focus-within
matches on the ::scroll-marker-group for ::scroll-marker,
and the scroll container and all ancestors for both
::scroll-marker and ::scroll-button
<emilio> It looks reasonable, but flackr is there any way for script
to detect whether the scroll container or a marker is
focused?
What counts as "immediately preceding" for `block-ellipsis`?
------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10868
scribe: fantasai
andreubotella: We spoke about this in TPAC in side conversations
andreubotella: Issue is about block ellipsis, line that gets
ellipsized is the one immediately preceding the clamp
point or region break
andreubotella: for continue: collapse, my PR at that point defined
that the clamp point could be after a block element
that didn't contain any lines
andreubotella: In TPAC we talked about only clamping after a line
andreubotella: so if you clamp based on max-height, the last element
that fits on that height is a block element without
any lines
andreubotella: then that element would be after the "clamp point"
andreubotella: the last line that fits, that's where the clamp
point is
andreubotella: the only thing that could be immediately preceding the
clamp point could be a line, because we define it that
way
florian: Thought about this. In generalized case would be less
useful, but does make it simpler
florian: If we apply this only for collapse and not continue:
discard, then I'm fine with it
fantasai: This clamp point would indicate where we insert the
ellipsis, does it also indicate where we clamp from?
fantasai: or can we have a case where the ellipsized line is there,
and there's an image after?
florian: The proposal is to not do this. If you have a block image,
you don't see it
florian: continue:collapse is deliberately simpler, for dealing with
text mostly
florian: as long as we scope the answer to that case, then I'm fine
astearns: If not applying to continue:discard, why apply to
continue:collapse?
astearns: Can we just make this about where we put the ellipsis, and
not affect what content gets clipped?
florian: I think this was desired for other reasons as well. And as
long as we're doing it, problem goes away.
florian: Can't have anything other than clamping at line
fantasai: My question was the same as astearns, why make this
inconsistent, why not say the ellipsis is placed on the
last available line and still show anything after?
Received on Thursday, 23 January 2025 00:40:54 UTC