- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 2 May 2024 19:32:45 -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 Scroll Snap
---------------
- RESOLVED: Dispatch scroll snap events on pseudo elements by
targeting the ultimate originating element (Issue #10175:
Should pseudo-elements show up as null
SnapEvent.snapTargetBlock/Inline)
- RESOLVED: Snap events targeting the document bubble in the same way
scroll events do (Issue #10173: Should snap events fired
at the document bubble?)
- RESOLVED: scrollsnapchanging and scrollsnapchange (Issue #9697: Use
present tense for snap event names)
CSS Pseudo Elements
-------------------
- RESOLVED: Add ::search-text, using :current to distinguish
currently-focused match, mark as optional to implement
(Issue #10212: Single highlight pseudo for find-in-page?)
- RESOLVED: ::search-text paints directly above or directly below
::selection (up to UA) (Issue #10213: painting order of
find-in-page highlights)
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2024May/0000.html
Present:
Rossen Atanassov
Kevin Babbitt
Stephen Chenney
Elika Etemad
Robert Flack
Simon Fraser
Daniel Holbert
Vladimir Levin
Alison Maher
Florian Rivoal
Khushal Sagar
Jen Simmons
Alan Stearns
Regrets:
Yehonatan Daniv
Jonathan Kew
David Leininger
Miriam Suzanne
Bramus Van Damme
Lea Verou
Chair: Rossen
Scribe: fantasai
Scroll Snap
===========
Should pseudo-elements show up as null SnapEvent.snapTargetBlock/Inline
-----------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10175
flackr: You can set scroll-snap-align on pseudo-elements, and UA
snaps to them
flackr: what should we do for the events we're defining?
flackr: my proposal is to treat just like other targetted events, and
dispatch at owning element
flackr: just like click etc.
flackr: Dev won't have any way to know which pseudo was targetted
flackr: could expand similar to Animations to add a string saying
which pseudo
Rossen: Are there use cases for such dispatching?
flackr: Pseudo-elements can be snapped to, want to tell dev that
we've snapped to something
flackr: we just don't have a way to reference the pseudo without the
pseudo IDL in css-pseudo-4 which nobody has shipped
flackr: the dev will know that we snapped to something, just won't
know which
flackr: could get complicated in combination with some of the ongoing
current proposals
flackr: like adding snap areas to fragments etc.
flackr: but for things like ::after/::before, probably don't need to
care
florian: Seems more typical than if you snap to pseudo *and* element
<astearns> +1 to consistency with other targeted events (even though
it isn't entirely useful)
florian: And if the pseudo is the only possible target on this
element, there's not much of a mystery what you snapped to.
But authors are infinitely creative, so my expectation of
what's typical is not necessarily warranted
florian: I would hope that we explore sooner than later how to target
pseudos in general
florian: if we think the most promising approach doesn't work, then
we paint ourselves into a corner this way
florian: so if we expect it to be the way forward, should make sure
it is the way forward
flackr: I have some ideas on supporting generic events, but point
taken
khush: With all the other places we've worked around lack of
expressing pseudo in JS by using its originating element and
string saying which pseudo
khush: noted we could give that string here
flackr: I'm proposing that just like with other events, says target
is the owning element
flackr: if we extend later, propose matching Animations string, says
targeting this pseudo with this string
khush: So right now no use case for knowing whether element or pseudo?
flackr: No strong use cases
Rossen: Sounds we can resolve, unless other comments?
PROPOSED: dispatch events on pseudo by targeting the originating
element
khush: "ultimate originating element"
RESOLVED: Dispatch scroll snap events on pseudo elements by targeting
the ultimate originating element
Should snap events fired at the document bubble?
------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10173
flackr: Snap events are very similar to scroll events in how dev
thinks about them and how dispatched
flackr: scroll events, when targeting the document, ?? window
flackr: should we do the same with snap events? I propose yes
florian: My intuition is the same. Is there any, even theoretical,
counter-argument? Why would anyone want different?
florian: If we can't think of any plausible reason, then we have a
resolution :)
Rossen: Objections?
<kbabbitt> +1
<TabAtkins> +1, this just seems straightforward
<flackr> Proposal: snap events targeting the document bubble in the
same way scroll events do
RESOLVED: snap events targeting the document bubble in the same way
scroll events do
Use present tense for snap event names
--------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/9697
flackr: Was pointed out that "snapchanged" event felt inconsistent
with other names which use present tense
flackr: removing past tense, and adding 'scroll' in front of 'snap'
flackr: The idea was to make them sort next to the scroll events
flackr: Proposal is snapchanged -> scrollsnapchange and snapchanging
-> scrollsnapchanging
<TabAtkins> No particular opinion, except I agree the tense change is
good.
flackr: I think the tense change is good, ambivalent about adding
'scroll'
flackr: they do only apply to scroll containers
flackr: so not unreasonable to say 'scroll'
<TabAtkins> I don't think "scroll" is quite necessary, unlikely that
"snap" will ever apply meaningfully to anything else
<fantasai> Agree, but the one benefit is it aligns closer to the CSS
properties
<fantasai> which makes it easier for people to associate them
<TabAtkins> Yeah, that's fair.
RESOLVED: scrollsnapchanging and scrollsnapchange
CSS Pseudo-elements
===================
Single highlight pseudo for find-in-page?
-----------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10212
florian: We have this set of highlight pseudo-elements that lets you
restyle how UA styles spelling-error, selection, etc.
florian: as part of that family, being able to restyle browser's
find-in-page has been proposed
florian: also discussed whether to highlight active vs inactive
florian: The underlying question, does that even work? E.g. in
Safari, wouldn't restyle how browser does it already
florian: Safari does it as an overlay
florian: we would need some way to say not to do the overlay, or
accept double-styling, or ...
florian: So what pseudo-classes do we need, and how do we do it?
schenney: Issues on agenda due to trying to prototype
schenney: in Chromium
schenney: Both Firefox and Safari convert the matched text to
::selection when the UI for find-in-page is exited
schenney: I don't think that's a problem, but we may need to define
what happens there
schenney: If people think this is a horrible idea, should say so. So
first, any objections to prototyping?
florian: No objection to prototyping, but should have some idea of
how it should work in e.g. Safari
florian: doesn't mean don't do it, but know what it means
schenney: ... I don't think Safari has reasonable path to implementing
florian: One approach is Safari doesn't implement the syntax
florian: but also part of defining is defining painting order
florian: is this an area where we can pick an answer, or will
browsers need different answers
florian: Unlike other pseudos, where we seem to have agreement on
what we do in the page, there's more variation here
florian: could come up with an answer, and ask Safari people to
answer in question
Rossen: Fallback is?
florian: You try to style something and it doesn't get styled
<fantasai> smfr's comment btw:
https://github.com/w3c/csswg-drafts/issues/10212#issuecomment-2086545393
Rossen: Seems we have one UA that unlikely to implement in forseeable
future if ever
Rossen: Maybe loose language in terms of "may" rather than "must"
Rossen: and safe fallback
florian: We should specify the feature in terms of "must" as in "if
you support the feature, do it this way, but it's optional
to support the feature"
florian: Otherwise hard for authors to know how to do the styling, if
allowed to do it in multiple ways
schenney: Back to issue, what do we name this pseudo-element?
schenney: proposal is to name it ::search-text, consistent with
::target-text
schenney: and then to add :active pseudo-class to style active vs
inactive differently
florian: This seems reasonable to me
florian: active vs inactive is if multiple words highlighted, and one
is currently focused?
florian: This is a UI feature, not required to highlight multiple
florian: If highlighting several, one is active and others inactive;
if highlighting multiple, then what?
schenney: In that case it's active
schenney: we can't expose what the browser's doing due to privacy
concerns
fantasai: :active currently is about click state in most cases, not
about activation (though I wish it was)
fantasai: Are we OK with this not being about click state for
::search-text?
fantasai: Also, is it :active or is it :focus?
schenney: It's active in that it will be converted to selection when
exiting search UI
schenney: but using new class name not used anywhere else
schenney: focus could maybe work
Rossen: I would stay away from :focus for accessibility reasons
<kbabbitt> +1 to staying away from focus for accessibility reasons
Rossen: :active is less problematic
Rossen: also assumes it's a singleton, not sure if this is true today
fantasai: "current" could work - we do have a :current pseudo
<fantasai> https://www.w3.org/TR/selectors-4/#time-pseudos
florian: what's it for?
fantasai: time-dimensional pseudoclasses
florian: If it doesn't conflict, reusing might be okay
florian: it's somewhat comparable
florian: There's a sort of time axis, but only wrt prev/next buttons
florian: wrt one thing highlighted, that's an existing feature; but I
don't think it's a problem
florian: there's a whole range of colors depending on window
highlighted or not or one or many etc.
florian: I'm not sure it's doing anything not represented by the
pseudos we're discussing
florian: but it's not just theoretical
vmpstr: Discussed Safari might not be able to implement, but if they
did, changing color with backdrop change could affect things
florian: I don't think Safari is dimming the backdrop, it's applying
a whole-page effect
florian: that's not representable by CSS on a highlight pseudo
florian: if we expect other browsers to do this, maybe it's the wrong
approach
smfr: Unsure of reason to add new pseudos. Browser do different
things, e.g. Safari does an overlay with punching hole through
it for the result
smfr: justification to add new pseudos seems pretty weak
florian: There are some browsers that render this as something
representable as in-page CSS
florian: author could reasonably restyle
florian: but in other UAs could decide to not implement
schenney: The use case was pages that do e.g. code display/editing
schenney: being able to differentiate in-page search vs browser search
schenney: Another use case was someone who didn't want people to
cheat in their browser game by using in-page search, so
could make invisible
fantasai: Actually that was my concern, that pages would abuse to
make find-in-page unusable. E.g. heavily advertised content
that wants you to read through rather than find the thing
you're looking for
smfr: like those annoying web pages that turn off context menus…
Rossen: Fragment navigation or whatever ...
smfr: scroll-to-text-fragment
Rossen: That gets navigated to, as far as I know it's the same
mechanism
Rossen: Not sure if UX is different?
schenney: In Chromium, the underlying rendering implementation would
be the same
schenney: Shared system for painting, different frameworks for
identifying the text
schenney: anti-pattern case is a good one
florian: 1. Do we do this? 2. If so, how?
florian: I haven't heard any arguments about the proposed syntax
being wrong, but debate over whether to do it
florian: possibly we want to introduce some browser failsafe, like if
contrast is bad can ignore author styling
florian: If we have this feature, the proposed syntax is reasonable
POLL: Should we have this feature?
Rossen: Any objections to adopting this feature?
smfr: Not going to object, just neutral. Safari may not implement.
<astearns> I think it may be a minefield we'll need to remove, but I
won't object
schenney: So we will call it ::search-text, and you may use ..?
:current?
schenney: to distinguish which is the current focused one
smfr: With regards to naming, thinking back to content-visibility:
hidden-find-matchable-thingy
smfr: Doesn't that use the term 'find' and not 'search'?
vmpstr: That term does not appear in syntax, only in the spec
smfr: ok
PROPOSED: Add ::search-text, using :current to distinguish
currently-focused match, mark as optional to implement
RESOLVED: Add ::search-text, using :current to distinguish
currently-focused match, mark as optional to implement
painting order of find-in-page highlights
-----------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10213
schenney: If you implement this, and what order do you paint when
there's overlap?
schenney: Proposed that ::search-text paints on top of everything
else, including ::selection
florian: I think I agree. Have we compared what existing
implementations do?
florian: In Firefox you can't tell because ...
schenney: When find-in-page changes you switch from search to
highlight
schenney: only relevant in chromium
fantasai: Not true, Firefox lets you select text while search text is
highlighted
fantasai: Not the active search one, the current one is no longer
current once you start interacting
fantasai: but you can highlight over found text, and selection
highlights over that found text.
fantasai: and that makes sense
florian: In firefox selection text is semi-transparent blue text...
fantasai: You're on a Mac
florian: ::selection is on top and somewhat transparent
florian: If you switch focus from the window you will see the
selection tainting the color of the search
fantasai: On Linux the selection is opaque, and very clearly on top
florian: Would that work for Chrome?
schenney: We can go with anything
fantasai: If you had find-within-selection you might want the find on
top, but I don't think anyone implements that
florian: If you select then search in Chrome, does the selection stop
being there?
Rossen: Seems the selection gets invalidated
florian: So if you have both then you selected most recently, then
maybe it should be on top
Rossen: Let's take a resolution, can always flip it if there's a
different use case
florian: So search would be over everything except ::selection
fantasai: I think I'm okay with this, but might make sense to leave
the ordering of the last two up to the UA, and simply say
they must be on top
Rossen: Isn't this the point of the issue though?
fantasai: We're clarifying it's on top of everything *other than*
selection
schenney: Also leaves open possibility of active over selection and
inactive underneath
<dholbert> I think the proposal matches what I'm seeing on Firefox on
Linux. (I see what fantasai described in some cases too,
with the selections being opaque, but in some cases the
selection does seem to be semitransparent and on-top (as
florian noted)
[discussion of various highlight pseudos]
schenney: Definitely over custom highlight
schenney: This also defines which color wins, and if author specifies
it, that color should also win
schenney: not just background
vmpstr: Clarify paint on top of everything, just within the element
PROPOSED: ::search-text paints directly above or directly below
::selection (up to UA)
florian: Agree above everything else, unsure if we shouldn't pin down
more, but can start with this and maybe make stricter later
on if necessary
Rossen: Hearing no objections
RESOLVED: ::search-text paints directly above or directly below
::selection (up to UA)
Received on Thursday, 2 May 2024 23:33:18 UTC