Re: [csswg-drafts] [css-pseudo-4] Add highlight pseudo for in-page search (#3812)

We are preparing an intent to prototype this in Chromium (cc @schenney-chromium, @jihyerish). Based on this issue and the discussion in #5233 and #5522, it seems there are a few things worth resolving:

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 #4579.

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 #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))

5. **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

![Safari on macOS](https://github.com/w3c/csswg-drafts/assets/465303/4dffbea7-977f-49d8-9e81-88eb97e42ff9)

<img alt="Safari on iOS" src="https://github.com/w3c/csswg-drafts/assets/465303/d5217357-5717-499e-9c4b-9c89aa1458e4" height="360">

-- 
GitHub Notification of comment by delan
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3812#issuecomment-2047241516 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 10 April 2024 11:05:57 UTC