- From: Samuel Bradshaw via GitHub <sysbot+gh@w3.org>
- Date: Thu, 11 Apr 2024 00:06:27 +0000
- To: public-css-archive@w3.org
> 1. **Do we really need two highlight pseudos, or would a pseudo-class like ::search-match:active make more sense?** Since ::active-search and ::inactive-search sound like they would be mutually exclusive, this may just be a question of elegance, not ambiguity like in [[css-pseudo-4] ::selection vs ::inactive-selection #4579](https://github.com/w3c/csswg-drafts/issues/4579). I like the proposal of `::search-match` and `::search-match:active` rather than adding two new pseudo-elements. > 2. **Where should they go in the highlight [painting order](https://drafts.csswg.org/css-pseudo/#highlight-painting)?** We propose that they paint over everything except maybe ::selection, because they reflect an explicit user intent to identify the search string, even more so than ::target-text (see also [[css-pseudo] priority of the native highlights #4594](https://github.com/w3c/csswg-drafts/issues/4594)). > > 3. **What do we do about Firefox moving the selection with the active match? (cc @emilio)** — Firefox and Safari eagerly move the selection to the active match (see [demo](http://bucket.daz.cat/work/igalia/0/65.html)). This is unlike Chrome, where the selection is cleared from when you first execute a search with new terms, to when you exit find-in-page. If search matches become highlight pseudos that paint below ::selection, the matches will look like selections, not matches. > > * **We could make (active?) matches paint over ::selection rather than below it** — Firefox can continue moving the selection with the active match, and this may be more compatible with Safari’s [find-in-page overlay behaviour](https://github.com/w3c/csswg-drafts/issues/5233#issuecomment-689678600) > * **We could make Firefox move the selection to the active match only when exiting find-in-page** — this might be better for privacy anyway (see [@zcorpan’s comment here](https://github.com/WICG/scroll-to-text-fragment/issues/128#issuecomment-1602668431)) I think it makes sense for the match to be painted above everything including the selection. Is there a downside to this? I tested in Safari, Chrome, and Firefox (on macOS) and in all three, selection isn't visible while in find-on-page mode. Given that, I don't think there'd ever be a case where you'd want a selection to appear on top of a search match. > 4. **What do we do about Safari’s yellow “bubbles”? (cc @litherum, @smfr)** — Safari on macOS and iOS has special platform-specific appearance for find-in-page. They darken everything except the matches, which seems like it will be compatible with these new highlights, but their yellow “bubbles” for the active match [paint on top of everything](https://github.com/w3c/csswg-drafts/issues/5233#issuecomment-689678600), [can only have one background color](https://github.com/w3c/csswg-drafts/issues/5233#issuecomment-689678600), and may not be able to handle anything other than plain text, not even text decorations (see [demo](http://bucket.daz.cat/work/igalia/0/65.html) and screenshots below). > > * **We could disable special appearance for find-in-page when a match (or the page) has custom styles** — though I’m not too sure about the UI implications here (see [comments by myles in #5233](https://github.com/w3c/csswg-drafts/issues/5233#issuecomment-689678618)) > * **We could allow UAs to parse and compute but ignore find-in-page styles that they can’t support** — Safari’s approach already ensures contrast with page colors, which so far seems to be the main use case anyway This second option sounds similar in some ways to CSS `accent-color`: the author specifies a color, and the browser applies it to various elements that would normally have color. Which elements or parts of elements actually get the color varies between browsers. What Safari's doing brings up another question, though – should authors also be able to style the dark backdrop? We have the `::backdrop` pseudo-element – should that apply to the find-on-page UI? -- GitHub Notification of comment by samuelbradshaw Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3812#issuecomment-2048625740 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 11 April 2024 00:06:28 UTC