- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 01 May 2024 23:49:38 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-pseudo-4] single highlight pseudo for find-in-page?`, and agreed to the following: * `RESOLVED: Add ::search-text, using :current to distinguish currently-focused match, mark as optional to implement` <details><summary>The full IRC log of that discussion</summary> <fantasai> florian: We have this set of highlight pseudo-elements that lets you restyle how UA styles spelling-error, selection, etc.<br> <fantasai> florian: as part of that family, being able to restyle browser's find-in-page has been proposed<br> <fantasai> florian: also discussed whether to highlight active vs inactive<br> <fantasai> florian: the underlying question, does that even work? E.g. in Safari, wouldn't restyle how browser does it already<br> <fantasai> florian: Safari does it as an overlay<br> <fantasai> florian: we would need some way to say not to do the overlay, or accept double-styling, or ...<br> <fantasai> florian: So what pseudo-classes do we need, and how do we do it?<br> <fantasai> schenney: Issues on agenda due to trying to prototype<br> <fantasai> schenney: in Chromium<br> <fantasai> schenney: both Firefox and Safari convert the matched text to ::selection when the UI for find-in-page is exited<br> <fantasai> schenney: I don't think that's a problem, but we may need to define what happens there<br> <fantasai> schenney: If people think this is a horrible idea, should say so. So first, any objections to prototyping?<br> <fantasai> florian: no objection to prototyping, but should have some idea of how it should work in e.g. Safari<br> <fantasai> florian: doesn't mean don't do it, but know what it means<br> <fantasai> schenney: ... I don't think Safari has reasonable path to implementing<br> <fantasai> florian: one approach is Safari doesn't implement the syntax<br> <fantasai> florian: but also part of defining is defining painting order<br> <fantasai> florian: is this an area where we can pick an answer, or will browsers need different answers<br> <fantasai> florian: Unlike other pseudos, where we seem to have agreement on what we do in the page, there's more variation here<br> <fantasai> florian: could come up with an answer, and ask Safari people to answer in question<br> <fantasai> Rossen: fallback is?<br> <fantasai> florian: you try to style something and it doesn't get styled<br> <vmpstr> q+<br> <fantasai> smfr's comment btw: https://github.com/w3c/csswg-drafts/issues/10212#issuecomment-2086545393<br> <fantasai> Rossen: seems we have one UA that unlikely to implement in forseeable future if ever<br> <vmpstr> q-<br> <fantasai> Rossen: maybe loose language in terms of "may" rather than "must"<br> <fantasai> Rossen: and safe fallback<br> <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"<br> <fantasai> florian: otherwise hard for authors to know how to do the styling, if allowed to do it in multiple ways<br> <fantasai> schenney: back to issue, what do we name this pseudo-element?<br> <fantasai> schenney: proposal is to name it ::search-text, consistent with ::target-text<br> <fantasai> schenney: and then to add :active pseudo-class to style active vs inactive differently<br> <fantasai> florian: this seems reasonable to me<br> <fantasai> florian: active vs inactive is if multiple words highlighted, and one is currently focused?<br> <fantasai> florian: this is a UI feature, not required to highlight multiple<br> <fantasai> florian: if highlighting several, one is active and others inactive; if highlighting multiple, then what?<br> <fantasai> schenney: in that case it's active<br> <fantasai> schenney: we can't expose what the browser's doing due to privacy concerns<br> <Rossen__> ack kbabbitt<br> <florian> q+<br> <Rossen__> ack khush<br> <Rossen__> ack fantasai<br> <fantasai> fantasai: :active currently is about click state in most cases, not about activation (though I wish it was)<br> <TabAtkins> scribe+ TabAtkins<br> <fantasai> fantasai: are we OK with this not being about click state for ::search-text?<br> <fantasai> fantasai: also, is it :active or is it :focus?<br> <fantasai> schenney: It's active in that it will be converted to selection when exiting search UI<br> <fantasai> schenney: but using new class name not used anywhere else<br> <fantasai> schenney: focus could maybe work<br> <fantasai> Rossen: I would stay away from :focus for accessibility reasons<br> <kbabbitt> +1 to staying away from focus for accessibility reasons<br> <fantasai> Rossen: :active is less problematic<br> <fantasai> Rossen: also assumes it's a singleton, not sure if this is true today<br> <TabAtkins> fantasai: "current" could work - we do have a :current pseudo<br> <fantasai> https://www.w3.org/TR/selectors-4/#time-pseudos<br> <TabAtkins> florian: what's it for?<br> <TabAtkins> fantasai: time-dimensional pseudoclasses<br> <TabAtkins> florian: If it doesn't conflict, reusing might be okay<br> <fantasai> florian: it's somewhat comparable<br> <fantasai> florian: there's a sort of time axis, but only wrt prev/next buttons<br> <florian> q?<br> <vmpstr> q+<br> <fantasai> florian: wrt one thing highlighted, that's an existing feature; but I don't think it's a problem<br> <fantasai> florian: there's a whole range of colors depending on window highlighted or not or one or many etc.<br> <Rossen__> ack florian<br> <fantasai> florian: I'm not sure it's doing anything not represented by the pseudos we're discussing<br> <fantasai> florian: but it's not just theoretical<br> <fantasai> vmpstr: Discussed Safari might not be able to implement, but if they did, changing color with backdrop change could affect things<br> <fantasai> florian: I don't think Safari is dimming the backdrop, it's applying a whole-page effect<br> <fantasai> florian: that's not representable by CSS on a highlight pseudo<br> <fantasai> florian: if we expect other browsers to do this, maybe it's the wrong approach<br> <smfr> q+<br> <Rossen__> ack vmpstr<br> <Rossen__> ack smfr<br> <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<br> <fantasai> smfr: justification to add new pseudos seems pretty weak<br> <fantasai> florian: There are some browsers that render this as something representable as in-page CSS<br> <fantasai> florian: author could restyle<br> <fantasai> s/could/could reasonably/<br> <fantasai> florian: but in other UAs could decide to not implement<br> <fantasai> schenney: the use case was pages that do e.g. code display/editing<br> <fantasai> schenney: being able to differentiate in-page search vs browser search<br> <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<br> <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<br> <fantasai> smfr: [missed]<br> <fantasai> Rossen: Fragment navigation or whatever ...<br> <fantasai> smfr: scroll-to-text-fragment<br> <fantasai> Rossen: that gets navigated to, as far as I know it's the same mechanism<br> <fantasai> Rossen: not sure if UX is different?<br> <fantasai> schenney: in Chromium, the underlying rendering implementation would be the same<br> <florian> s/[missed]/like those annoying web pages that turn off context menus…]<br> <fantasai> schenney: shared system for painting, different frameworks for identifying the text<br> <fantasai> schenney: anti-pattern case is a good one<br> <fantasai> florian: 1. Do we do this? 2. If so, how?<br> <fantasai> florian: I haven't heard any arguments about the proposed syntax being wrong, but debate over whether to do it<br> <fantasai> florian: possibly we want to introduce some browser failsafe, like if contrast is bad can ignore autho styling<br> <fantasai> s/autho/author/<br> <fantasai> florian: if we have this feature, the proposed syntax is reasonable<br> <fantasai> POLL: Should we have this feature?<br> <fantasai> Rossen: Any objections to adopting this feature?<br> <fantasai> smfr: Not going to object, just neutral. Safari may not implement.<br> <astearns> I think it may be a minefield we’ll need to remove, but I won’t object<br> <fantasai> schenney: so we will call it ::search-text, and you may use ..? :current?<br> <fantasai> schenney: to distinguish which is the current focused one<br> <fantasai> smfr: wrt naming, thinking back to content-visiblity: hidden-find-matchable-thingy<br> <fantasai> smfr: doesn't that use the term 'find' and not 'search'?<br> <fantasai> vmpstr: That term does not appear in syntax, only in the spec<br> <fantasai> smfr: ok<br> <fantasai> PROPOSED: Add ::search-text, using :current to distinguish currently-focused match, mark as optional to implement<br> <fantasai> RESOLVED: Add ::search-text, using :current to distinguish currently-focused match, mark as optional to implement<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10212#issuecomment-2089302563 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 1 May 2024 23:49:39 UTC