[css-pseudo-4] single highlight pseudo for find-in-page? #10212
Labels
Comments
|
I'm not really sure that having Find pseudos is going to work very well. The current behavior in Safari is that when you do a Find and there are results, the current result is selected (using normal DOM selection), and the UA draws an overlay where the current find result gets a yellow bubble (which entirely obscures whatever the page renders). If the user dismisses the Find overlay, then the result remains selected, so that it can be copied, for example. Now if the page author styles |
|
I expect that in Safari the find-in-page pseudo will be ignored. I would expect it to only apply when a search is active, but there the browser has a specialized UI, and it would disappear when the selection takes over in Safari. The only alternative I can think of would be to disable the overlay interface and use Chromium/Gecko behavior when a find-in-page pseudo is present, but I certainly wouldn't advocate for that as good for users. Firefox also has a search highlight color that switches to selection, and I would expect the pseudo that is used to switch also from find-in-page to selection. This suggest the spec should use the appropriate "... browsers may ..." language. |
|
The CSS Working Group just discussed
The full IRC log of that discussion<fantasai> florian: We have this set of highlight pseudo-elements that lets you restyle how UA styles spelling-error, selection, etc.<fantasai> florian: as part of that family, being able to restyle browser's find-in-page has been proposed <fantasai> florian: also discussed whether to highlight active vs inactive <fantasai> florian: the underlying question, does that even work? E.g. in Safari, wouldn't restyle how browser does it already <fantasai> florian: Safari does it as an overlay <fantasai> florian: we would need some way to say not to do the overlay, or accept double-styling, or ... <fantasai> florian: So what pseudo-classes do we need, and how do we do it? <fantasai> schenney: Issues on agenda due to trying to prototype <fantasai> schenney: in Chromium <fantasai> schenney: both Firefox and Safari convert the matched text to ::selection when the UI for find-in-page is exited <fantasai> schenney: I don't think that's a problem, but we may need to define what happens there <fantasai> schenney: If people think this is a horrible idea, should say so. So first, any objections to prototyping? <fantasai> florian: no objection to prototyping, but should have some idea of how it should work in e.g. Safari <fantasai> florian: doesn't mean don't do it, but know what it means <fantasai> schenney: ... I don't think Safari has reasonable path to implementing <fantasai> florian: one approach is Safari doesn't implement the syntax <fantasai> florian: but also part of defining is defining painting order <fantasai> florian: is this an area where we can pick an answer, or will browsers need different answers <fantasai> florian: Unlike other pseudos, where we seem to have agreement on what we do in the page, there's more variation here <fantasai> florian: could come up with an answer, and ask Safari people to answer in question <fantasai> Rossen: fallback is? <fantasai> florian: you try to style something and it doesn't get styled <vmpstr> q+ <fantasai> smfr's comment btw: https://github.com//issues/10212#issuecomment-2086545393 <fantasai> Rossen: seems we have one UA that unlikely to implement in forseeable future if ever <vmpstr> q- <fantasai> Rossen: maybe loose language in terms of "may" rather than "must" <fantasai> Rossen: and safe fallback <fantasai> 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" <fantasai> florian: otherwise hard for authors to know how to do the styling, if allowed to do it in multiple ways <fantasai> schenney: back to issue, what do we name this pseudo-element? <fantasai> schenney: proposal is to name it ::search-text, consistent with ::target-text <fantasai> schenney: and then to add :active pseudo-class to style active vs inactive differently <fantasai> florian: this seems reasonable to me <fantasai> florian: active vs inactive is if multiple words highlighted, and one is currently focused? <fantasai> florian: this is a UI feature, not required to highlight multiple <fantasai> florian: if highlighting several, one is active and others inactive; if highlighting multiple, then what? <fantasai> schenney: in that case it's active <fantasai> schenney: we can't expose what the browser's doing due to privacy concerns <Rossen__> ack kbabbitt <florian> q+ <Rossen__> ack khush <Rossen__> ack fantasai <fantasai> fantasai: :active currently is about click state in most cases, not about activation (though I wish it was) <TabAtkins> scribe+ TabAtkins <fantasai> fantasai: are we OK with this not being about click state for ::search-text? <fantasai> fantasai: also, is it :active or is it :focus? <fantasai> schenney: It's active in that it will be converted to selection when exiting search UI <fantasai> schenney: but using new class name not used anywhere else <fantasai> schenney: focus could maybe work <fantasai> Rossen: I would stay away from :focus for accessibility reasons <kbabbitt> +1 to staying away from focus for accessibility reasons <fantasai> Rossen: :active is less problematic <fantasai> Rossen: also assumes it's a singleton, not sure if this is true today <TabAtkins> fantasai: "current" could work - we do have a :current pseudo <fantasai> https://www.w3.org/TR/selectors-4/#time-pseudos <TabAtkins> florian: what's it for? <TabAtkins> fantasai: time-dimensional pseudoclasses <TabAtkins> florian: If it doesn't conflict, reusing might be okay <fantasai> florian: it's somewhat comparable <fantasai> florian: there's a sort of time axis, but only wrt prev/next buttons <florian> q? <vmpstr> q+ <fantasai> florian: wrt one thing highlighted, that's an existing feature; but I don't think it's a problem <fantasai> florian: there's a whole range of colors depending on window highlighted or not or one or many etc. <Rossen__> ack florian <fantasai> florian: I'm not sure it's doing anything not represented by the pseudos we're discussing <fantasai> florian: but it's not just theoretical <fantasai> vmpstr: Discussed Safari might not be able to implement, but if they did, changing color with backdrop change could affect things <fantasai> florian: I don't think Safari is dimming the backdrop, it's applying a whole-page effect <fantasai> florian: that's not representable by CSS on a highlight pseudo <fantasai> florian: if we expect other browsers to do this, maybe it's the wrong approach <smfr> q+ <Rossen__> ack vmpstr <Rossen__> ack smfr <fantasai> 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 <fantasai> smfr: justification to add new pseudos seems pretty weak <fantasai> florian: There are some browsers that render this as something representable as in-page CSS <fantasai> florian: author could restyle <fantasai> s/could/could reasonably/ <fantasai> florian: but in other UAs could decide to not implement <fantasai> schenney: the use case was pages that do e.g. code display/editing <fantasai> schenney: being able to differentiate in-page search vs browser search <fantasai> 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> 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 <fantasai> smfr: [missed] <fantasai> Rossen: Fragment navigation or whatever ... <fantasai> smfr: scroll-to-text-fragment <fantasai> Rossen: that gets navigated to, as far as I know it's the same mechanism <fantasai> Rossen: not sure if UX is different? <fantasai> schenney: in Chromium, the underlying rendering implementation would be the same <florian> s/[missed]/like those annoying web pages that turn off context menus…] <fantasai> schenney: shared system for painting, different frameworks for identifying the text <fantasai> schenney: anti-pattern case is a good one <fantasai> florian: 1. Do we do this? 2. If so, how? <fantasai> florian: I haven't heard any arguments about the proposed syntax being wrong, but debate over whether to do it <fantasai> florian: possibly we want to introduce some browser failsafe, like if contrast is bad can ignore autho styling <fantasai> s/autho/author/ <fantasai> florian: if we have this feature, the proposed syntax is reasonable <fantasai> POLL: Should we have this feature? <fantasai> Rossen: Any objections to adopting this feature? <fantasai> 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 <fantasai> schenney: so we will call it ::search-text, and you may use ..? :current? <fantasai> schenney: to distinguish which is the current focused one <fantasai> smfr: wrt naming, thinking back to content-visiblity: hidden-find-matchable-thingy <fantasai> smfr: doesn't that use the term 'find' and not 'search'? <fantasai> vmpstr: That term does not appear in syntax, only in the spec <fantasai> smfr: ok <fantasai> PROPOSED: Add ::search-text, using :current to distinguish currently-focused match, mark as optional to implement <fantasai> RESOLVED: Add ::search-text, using :current to distinguish currently-focused match, mark as optional to implement |
jihyerish
added a commit
to jihyerish/csswg-drafts
that referenced
this issue
Jun 20, 2024
Resolved from CSSWG - w3c#10213 (comment) - w3c#10212 (comment)
This was referenced Jun 20, 2024
fantasai
added a commit
that referenced
this issue
Oct 15, 2024
See #10475 Co-authored-by: Jihye Hong <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
#3812 suggests adding two new highlight pseudos, ::active-search and ::inactive-search, for find-in-page search results. But these highlights are mutually exclusive, so they need not be two separate pseudo-elements and highlight overlays.
We propose instead adding a single highlight pseudo with a pseudo-class (selectors #pseudo-element-states), such as
::search-text:active. You would select::search-textfor all matches,::search-text:activefor the active match, or::search-text:not(:active)for the other matches.The exact naming is not critical, but
::search-textwould be by analogy with::target-text, and clearly describes the thing being highlighted (like::spelling-error), more so than alternatives like::search-matchor::find-in-page.The text was updated successfully, but these errors were encountered: