- From: Matthew Tylee Atkinson <notifications@github.com>
- Date: Thu, 28 Aug 2025 02:57:33 -0700
- To: w3ctag/design-reviews <design-reviews@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3ctag/design-reviews/issues/1120/3232811373@github.com>
matatk left a comment (w3ctag/design-reviews#1120) Thanks for your reply @schenney-chromium. We discussed this proposal again today, and are still supportive of the use case (improving the in-page highlight experience and accessibility). We have an alternative approach suggestion for you to consider. The explainer talks about the behaviours of different browsers. However, did you consider the alternative approach of _not_ implementing this, and instead setting the expectation the UAs be responsible for choosing highlight colors based on the active background color and user preferences so that they provide appropriate contrast (similar to Safari's more involved approach)? Taking this alternative approach would not afford content authors the same level of control (and responsibility) that the highlight pseudos approach provides. It would however have the effect of making the 'find in page' feature consistent within a given UA, and it would avoid the possibility that authors fail to provide appropriate colors. (Given that some users may prefer lower, or higher, contrast, and dark mode may be in effect, providing appropriate colors is non-trivial work for the content author.) In addition, have you considered possible abuse scenarios? I.e. under the proposed approach, authors could set colors that effectively disable the find-in-page feature. -- Reply to this email directly or view it on GitHub: https://github.com/w3ctag/design-reviews/issues/1120#issuecomment-3232811373 You are receiving this because you are subscribed to this thread. Message ID: <w3ctag/design-reviews/issues/1120/3232811373@github.com>
Received on Thursday, 28 August 2025 09:57:37 UTC