[css-pseudo-4] Add a highlight pseudo-element for find-in-page or scroll-to-text #5233
Comments
|
One possible concern would be a developer setting those colors to something with no contrast to the other text on the page, but I'm not sure if that is any worse than other things the developers could do to fight with the user or make mistakes regarding contrast. If that is a significant concern, we could add normative language to require a certain amount of contrast with the background of the text, and if there isn't then allow UAs to ignore the color. |
|
There is also the window.find API, which currently causes a selection highlight, not a find-in-page highlight. |
|
In gecko the selection that
In gecko the find-in-page color is called This is somewhat similar to the discussions we've had about styling the inactive window selection, where it seemed that people preferred a pseudo-class that applied to the existing |
|
I'd previously suggested that CSS have a mechanism for multiple named selections and an API for creating them, and a find-in-page selection (or more than one of them) could fit in to that. |
|
That seems somewhat related to this proposal by Microsoft. |
|
I've put this in the Thursday milestone so that @megangardner can attend. |
|
The CSS Working Group just discussed
The full IRC log of that discussion<fantasai> Topic: Highlight pseudo-element for find-in-page / scroll-to-text<Rossen_> github:https://github.com//issues/5233 <fantasai> florian: In Pseudos 4 we have ::selection, ::grammar-error, ::spelling-error <fantasai> florian: Another thing ppl sometimes want to style is find-in-page highlight <fantasai> florian: so maybe we want one of those <fantasai> florian: I think I'd like to point out two things <fantasai> florian: There is a work in progress spec to try to make it possible for authors to create custom highlights for any reason <fantasai> florian: on the JS side of things, you'd set ranges on the page <Rossen_> spec in reference is https://drafts.csswg.org/css-highlight-api-1/ <fantasai> florian: on CSS side you can style them <fantasai> florian: If you want to style the browser one <fantasai> florian: pointed out at least by Apple <fantasai> florian: unlike the others, the UI that is used by some browsers <fantasai> florian: isn't something you can create in CSS <fantasai> florian: so expressing through selector, you can't express those effects in CSS <tantek> curious about the visual effects that can't be expressed in CSS, screenshots? <fantasai> florian: so proposed resolution is partially no change, and partially poke the editors of that spec <fantasai> cbiesinger: scroll-to-text is that when searching for a thing and click search result, the browser will scroll to the first matching fragment <fantasai> florian: idk if we want authors to have control over the UI <fantasai> florian: or if want consistency across pages and should stay out of authors' hands <tantek> this is also used by the IndieWeb for annotations and marginalia with fragmentions https://indieweb.org/fragmention <tantek> q+ <Rossen_> ack tantek <fantasai> tantek: 2 questions <fantasai> tantek: find-in-page seems like a well-established feature <fantasai> tantek: effects might not be consistent across browsers, could study and figure out what the effects are <fantasai> tantek: curious about effects that can't be expressed in CSS <fantasai> tantek: maybe add screenshots of the effect to the issue? <fantasai> tantek: happy to defer decision until we have more info <fantasai> tantek: don't seem to have a rush <fantasai> tantek: on scroll-to-text or marginalia use case <smfr> q+ <fantasai> tantek: in the Indie Web community, there's a diversity of how authors want to style this effect <fantasai> tantek: both from perspective of person linking, and from perspective of site linking to the text <fantasai> tantek: Sometimes author wants to say "these are the words I want to select" <fantasai> tantek: and leave up to destination to highlight / style or not <florian> q+ <fantasai> tantek: third case of browser doing something by default if neither author of link or author of page wants to do something <fantasai> tantek: so complex interaction between author of the link, author of the page <fantasai> tantek: maybe want to decide text fragment, or whole paragraph, or section, or something <fantasai> tantek: and maybe browser does something <fantasai> tantek: maybe need to investigate more <fantasai> tantek: I see the utility for a page to control the presentation of highlights and annotations <fantasai> tantek: but requires more study of possible effects to come up with a good solution <florian> q? <fantasai> tantek: Also sometimes animated <fantasai> tantek: fragmention to a blog post of mine, my site will scroll to that paragraph, not to the text itself <fantasai> tantek: and then do yellow highlight on that paragraph which then fades away <fantasai> tantek: non-intrusive, here's what you are looking for <fantasai> tantek: didn't want to pollute styling with something persistent <fantasai> tantek: not sure that's possible with pseudo-element either <fantasai> tantek: bunch of ways ppl doing presentation effects with this <fantasai> tantek: so requires further documentation before designing a solution <chrishtr> q+ <fantasai> smfr: I don't think the page can currently detect when the user does find in page <fantasai> smfr: if we allow highlighting, then that exposes that information <fantasai> smfr: so some privacy concerns there <fantasai> smfr: not sure I want that to happen <Rossen_> ack smfr <Rossen_> ack fantasai <Zakim> fantasai, you wanted to note :target allows anything, right? and to <tantek> example link to the animation effect I was mentioning: https://tantek.com/2020/187/b1/changes-indieweb-organizing-indiewebcamp-west#keep%20listening (should work in any browser with JS turned on, Fragmentions implemented with a polyfill on my site) <fantasai> fantasai: I don't think anything is exposed to the author <fantasai> fantasai: highlight pseudos don't affect computed style or layout or anything except painting for the user <tantek> scribenick: tantek <fantasai> scribeNick: fantasai <fantasai> smfr: Is there an API to detect? <fantasai> florian: not yet determined <Rossen_> ack florian <fantasai> smfr: user after finding, can hit ? to select the result <fantasai> florian: back to tantek's point wrt research <fantasai> florian: one aspect not doable in CSS in general <fantasai> florian: these pseudos are non-tree-abiding, and cannot affect layout <fantasai> florian: so things that you can do in CSS in general, you can't do with these types of pseudo-elements <fantasai> florian: so need to know what authors would want to do, if it's even possible <fantasai> chrishtr: [asks for tantek to clarify] <Rossen_> ack chrishtr <fantasai> tantek: IndieWeb community is trying out different presentations of how to show fragmention when someone links to your site with a fragmention <fantasai> tantek: yellow paragraph highlight + fade is just one example <fantasai> tantek: others folks have used other effects <fantasai> tantek: experimentation is happening on personal websites <fantasai> tantek: e.g. "scroll that into view, show specific effect" <fantasai> tantek: using polyfill right now <fantasai> chrishtr: so writing JS code that parses the text in the URL? <fantasai> tantek: I believe it's a fairly straightforward simple polyfill <fantasai> tantek: which then adds class names that you can style <fantasai> tantek: so that there's a separation between polyfill and provides a hook that author can style accordingly <fantasai> tantek: not everyone has to write JS <fantasai> chrishtr: main response to that is cool to be experimenting with this effect <fantasai> chrishtr: ... <fantasai> tantek: There are other interactions where select text in a blog post <fantasai> tantek: you'd have options to then tweet that text, or do something else <fantasai> tantek: multiple phases <fantasai> tantek: method of causing a highlight to occurr <fantasai> tantek: DOM hooks to style the highlight <fantasai> tantek: independent of that you could potentially provide a UI to do something with the highlighted text <fantasai> tantek: e.g. +1 the highlight, or copy and post to Twitter <fantasai> Rossen_: sorry to interject, but I think we're straying <fantasai> chrishtr: I agree with those use cases and would like to follow up offline <fantasai> chrishtr: main point is, as long as we're making progress towards exploring this space so we can find the right APIs to expose that's good <fantasai> chrishtr: Right now feature in one browsers that does not allow customization of the color <tantek> looks like the fragmention polyfill I'm using puts a "fragmention" attribute on the containing paragraph (or possibly nearest block-level element) <fantasai> chrishtr: and quite a lot of dev requests to change color in that particular UI mode <fantasai> chrishtr: and want to respect that desire and make progress to authors customize look and feel <fantasai> florian: The challenge here is that these are very restrictive pseudo-elements, only a few aspects of rendering can be change <tantek> color (and background-color) are just the beginning of these needs, that's the point <fantasai> florian: so need to see if what is desired is possible to solve via highlight pseudo <tantek> we shouldn't prematurely optimizing for only color is my point <tantek> s/prematurely/be prematurely <fantasai> Rossen_: Somewhat related to highlight API spec <hober> q+ <fantasai> hober: I'd like to step down as co-editor of highlight API, haven't had time <fantasai> hober: I'd like to suggest as my replacement Megan Gardner <fantasai> hober: she did the WebKit implementation <fantasai> florian: I don't plan to step down, and I look forward to work with Megan <fantasai> RESOLVED: Megan replaces Tess as editor of Highlight API spec <fantasai> fantasai: think that find-in-page vs fragmention are slightly different in their needs <Rossen_> ack hober <Rossen_> ack fantasai <tantek> +1 fantasai totally agreed the features are different <fantasai> fantasai: so let's keep those things distinct in the discussion <fantasai> Rossen_: +1 <fantasai> Rossen_: Ppl working on this need to figure out the boundaries between ? and ? <fantasai> Rossen_: which exposes user interaction <fantasai> Rossen_: if we are exposing something new, we are adding additional privacy-related exposure to the content layer <fantasai> Rossen_: That is biggest sticking point, are we starting to expose something additional, and if so how so <fantasai> Rossen_: outside of that, good thing to continue investigating |
|
I did some research into additional use cases and considerations. @tantek brought to my attention explorations like Marginalia from IndieWeb. The idea there is to use a fragment identifier to indicate responses or comments on sites. On that page, it suggests that "As a first step, marginalia can be displayed as normal post-level comments at the bottom of the post but with a reference/fragmentioned link to the context-phrase.". Such a UI would require the site's script to understand the fragment identifier and modify DOM accordingly; a pseudo-element is much too restrictive in expressivity. In that case a script-exposed state such as that proposed here, and/or a script event indicating highlighting as proposed here would be make sense. However, for simple styling of default User Agent affordances such as the color of the scroll-to-text highlight, it makes more sense to simply expose the highlight pseudo-element for this purpose, and specify which CSS properties apply to it. An alternative of requiring script to do it would be very difficult for page authors to implement, in part because it needs to happen very earlier in the page load lifecycle. It's possible to imagine a User Agent that does not use only a highlight to indicate scroll-to-text (e.g. maybe there would be an overlay UI of some kind), but it seems unlikely that this would occur without a highlight, because a highlight + scrolling is a very effective and established way for a User Agent to indicate text on a page that the user is interested in and plays nicely with the style and layout concepts of the web. I'd like to move for us to adopt a highlight pseudo for find-in-page and scroll-to-text. We could even add one for each, since as mentioned in the CSSWG meeting notes the use cases are different. |
|
This sounds like it could potentially be useful. Have we heard from developers/publishers that they want the ability to customize the highlight style & would make use of this if we provided the capability? We have heard some feedback that the current yellow color is not pleasant and are exploring other colors, so I'm wondering if that would be sufficient to address any current concerns vs whether devs feel they need the ability to further customize. Some quotes / concrete examples from devs of how they would override the highlight style to improve the UX on their site (e.g. screenshot of current yellow highlight and the alternative style they'd use instead) could help us here. |
|
@bryanmcquade I think any color will be incompatible with some sites, since the color scheme of sites varies greatly. We already have pseudo elements to override colors of other similar concepts like spelling and grammar underlines, and I think this feature falls into the same pattern. |
|
On macOS and iOS, the yellow bubble isn't actually part of the page - it's on its own layer floating above the page. Because of that, we don't really have infrastructure to style part of the bubble in one color and the rest in another color; we kind of have to just pick a single color for the entire bubble. The spec should be flexible enough to allow for this constraint. |
|
The CSS Working Group just discussed
The full IRC log of that discussion<dael> Topic: [css-pseudo-4] Add a highlight pseudo-element for find-in-page or scroll-to-text<dael> github: https://github.com//issues/5233 <chrishtr> tab go for it, my mic is broken <dael> TabAtkins: I can run with it <dael> TabAtkins: Thread talks about general highlight API. This is about find in page or scroll to text stuff. That they're not exposed is inconsistent and means authors can't have consistent highlight. Proposal is expose those two under same or separate times. <florian> q+ <dael> TabAtkins: If same group like UA-selection. Is separate ::find-in-page and ::scroll-to-text <GameMaker> q+ <dael> TabAtkins: Opinions? Okay to pursue? <gregwhitworth> TabAtkins: how does this relate to https://drafts.csswg.org/css-highlight-api-1/ ?? As this was created for that if I recall correctly <dael> florian: We talked a month ago. This question doesn't take into account that conversation. If I recall find in page effects by browsers are way beyond highlight pseudo element. Safari does whole page darkening. Not something normal pseudo could do. <fantasai> gregwhitworth, this one hooks into the browser UI <TabAtkins> gregwhitworth: It doesn't, and that's not - that's for a *generic* highlighting mechanism controllable by authors <gregwhitworth> gregwhitworth: ahhh <dael> florian: Conceptually similar but style is very different. We should do some research abotu what browsers do and what authors want to do and if that fits within existing things <smfr> q+ <dael> TabAtkins: Browsers do go beyond but they all currently do the same selection-ish highlight. May have other styling but still highlight the selection. It's a pretty basic UX that we feel will be stable across time. being able to customize highlight still seems reasonable to do <florian> q- <astearns> ack GameMaker <dael> GameMaker: My comment is that Safari does darken page. Also I'm not entirely on board where we'd need 2 to do what Chrome does. Highlight whole page in one color and the one you're at is in a different color. this only suggests one thing <dael> GameMaker: Browsers do different things. If we make this a highlight element, elements are styled in more ways. With selection you can do more, but opening to highlight pseudo element there's a whole host of things we can do <chrishtr> q+ <dael> GameMaker: I can see why we're considering. I don't know what devs are asking for. I don't know right thing to do it <dael> GameMaker: Summary- Chrome would need 2 colors b/c they highlight all words and the one you're looking at is different. Opening to full pseudo highlight is more than just color and it's opening more than we can do. Need to be cognizant of that and I'm not sure devs are asking for this <emilio> q+ <astearns> ack smfr <dael> smfr: One question is if author provides styles does that disable browser built in find highlighting? <dael> TabAtkins: What would be tricky about that? <gregwhitworth> q? <dael> smfr: If styling is simply color no but if more involved later there might be something like appearance where browser decides to turn off built in <dael> myles: Related point where if some elements have pseudo and others don't do we auto-darken the page when at elements that don't have this and when you cmd + G to the next would we change darkening? <gregwhitworth> q+ <dael> TabAtkins: I don't think we'd turn off darkening. I was wondering if problems darkening and turning on author supplied highlight colors <astearns> ack chrishtr <emilio> q- <dael> chrishtr: Like to point out there are 2 use cases. Find in page and scroll to text. Chrome has recieved dev desire on scroll to text. When you use this it will highlight bg of selected content in yellow for short period. Many devs find that color doesn't fit with theme <florian> q+ <dael> chrishtr: Added find in page b/c thought would be good to think together. Agree find in page is more complex. I think scroll to text is pretty simple <astearns> ack gregwhitworth <una> q+ <dael> gregwhitworth: I've likewise heard developer request for this. Having a browser hook would be good. Very valid points on open questions. Feel it warrents a more concrete proposal. As you denoted chrishtr it may vary between the two <astearns> ack florian <dael> gregwhitworth: For a use case there is developer interest and worth exploring <dael> florian: How it would work if it's a highlight is defined. But details on use case would be good to see if they fit. It was mentioned it's a fading yellow highlight. If the fading exposed, timing, control? Knowing this would help us figure out if this is the right thing to do <dael> florian: We know what pseudo highlights do but we kknow less what we're trying to achieve. Good to document. Probably different between find in page and scroll to text. Maybe document both separately. See if it fits the use case <astearns> ack una <dael> una: Bringing this up as opportunity to be consistent. Some browsers highlight all words, some only active. Some difference in colors cross browser. Lots of considerations here. Not jsut contrast but browser experience. And what happens with dark mode, how do we make sure the highlighted word stands out. <florian> q? <dael> leaverou: Another thing is this is a pseudo element that will spawn multiple sub elements. Is there precenent. Is it a special pseudo element? <dael> florian: There's precedent <dael> TabAtkins: Defined in ::selection. Constrained properies that make it hard to tell number of boxes <dael> leaverou: currentColor? <dael> TabAtkins: It's however it works in ::selection <fantasai> See https://drafts.csswg.org/css-pseudo-4/#highlight-pseudos <dael> florian: It's pretty cool, the definition. not tree abiding and weird, but defined weird. <fantasai> The properties supported are not allowed to affect layout in any way <dael> una: B/c contrast issue it might be good to allow this so you can style borders and other parts of highlight to make it stand out. Would help authors make sure text style stands out in their specific design <fantasai> properties currently specified to work is https://drafts.csswg.org/css-pseudo-4/#highlight-styling <dael> chrishtr: dark mode- can't dev proved dark mode style for this? <dael> una: Yes, jsut additional overhead. Good to do b/c author makes sure whatever preference mode these styles have clear visibility <chris> s/will spawn multiple/will span multiple/ <dael> TabAtkins: Support that. b/c we all do dark mode I'm of opinion any UA provided color should be under author control to make sure it looks good with both dark and light <dael> florian: I suggest we split the issue in 2. Document what browsers do today and which aspect authros want to control. From there can judge if it's a good fit. Good chance for scroll to text. Find in page, maybe maybe not. <dael> florian: Split the issue, document use cases. Does that sound reasonable? <dael> astearns: Anyone argue it should be a single way? <dael> florian: It might be. If we say highlight pseudo is right that's a single way. That some browsers highlight all and some only active. I think there's also highlight in scroll bar. There's a number of things being done. <dael> florian: If we want to say the find text thing is easy and the other less then we split. But we explore in parallel and if they're easy we do both <dael> chrishtr: Makes sense to split. Scroll to text is much simplier. It's a progressive enhancement of linking property. In Chromium-based it shows a yellow that disappears after user interactions. It's pretty simple <dael> chrishtr: I can file a new issue and go into more detail with examples <dael> florian: Thing I wonder about this is the timeout. Other highlight pseudos aren't timed. Other than that it doesn't sound hard. <tantek> we have examples with much more interaction, such as marginalia, e.g. what Medium does with highlight UI <dael> fantasai: Just like with selection I think UA controls when it exists <dael> florian: Probably <dael> florian: Is this transition out and the transition out is defined by UA? Maybe. <dael> astearns: We'll open at least 1 new issue to separate the two <hober> q++ <hober> err, q+ <dael> chrishtr: Great to confirm if there's any objection to trying to move forward and spec scroll to text? <astearns> ack hober <astearns> ack + <dael> hober: I don't htink I object. I do think that the find in page one is supported across all browsers and has more complex styling. Tackling harder first means you get easier for free later. <gregwhitworth> q+ <tantek> agrees with hober, specify find first since it's more cross-browser <dael> florian: Not sure. At thispoint we're trying to see if the definition fits more problems <gregwhitworth> astearns: my q is an addendum <dael> TabAtkins: The text find thing is a soft problem already. Not jsut easy, it's a none problem once we define it exists <astearns> ack gregwhitworth <tantek> q? <tantek> I don't understand the proposal? <dael> astearns: I think we have a way forward to open another issue <dael> gregwhitworth: Wanted to make sure chrishtr was good with where we're at <dael> chrishtr: Great to resolve that it's useful for scroll to text. Come back with a proposal text to verify with the group <gregwhitworth> ack gregwhitworth <dael> astearns: Prop: We have this facility for browsers that impl scroll to text <dael> astearns: Obj? <tantek> q+ <dael> florian: Still curious about how animation works. If we'll come back with a definition of how that works, yes <astearns> ack tantek <dael> tantek: I think framing the scroll to text in terms of highlight is too narrow a framing. Don't object to exploring but object to limiting to juust that <dael> tantek: Medium, for example. If you scroll to a selection of text additional UI occurs where you can annotate. At least couple indy web where you can comment in margins and when you highlight it highlights text you commented on. <dael> tantek: Have in the wild that kind of text that's far beyond simple backgorund highlights. I don't oppose exploring, just want to make sure we're not trying to collapse it with something like find that's mroe limited <dael> chrishtr: Responded to those use cases in github. Those would need script involvement. Similar to how we discussed accent color on form controls this is low hanging fruit. It by no means precludes more customization in the future <dael> tantek: Okay, thanks <dael> florian: From my PoV I would like to know if entire fade in and out is UA controled or if timing is controlled. <dael> chrishtr: I think that's out of scope for resolution and I'll come back with a precise thing. <dael> astearns: Resolution is we're interested and would like you to pursue and come back with proposal text? <dael> chrishtr: Yes <dael> RESOLVED: we're interested and would like chrishtr to pursue and come back with proposal text <florian> s/if timing is controlled./if its timing is UA controlled but the actual fading is controlled from css/. |
This is reasonable - should be fine to allow UAs to take the style from the nearest common ancestor of the highlighted fragments and use it across the selection, if that's required for their rendering. |
This may end up being a color that is wildly different from any color that other UAs show. We might want a different heuristic. |
|
@fantasai sounds good, thanks. |
|
Was the idea to allow a developer to customize the find-on-page match highlight colors abandoned? I'm not finding any open issues about this use case, and in the latest CSS spec, it seems that |
|
@samuelbradshaw See #3812 for that discussion |
Right now you can customize the color of a selection highlight via ::selection, but there appears to
be nothing for user agent-specified selections such as find-in-page and scroll-to-text-fragment.
How about we add
::ua-selection?The text was updated successfully, but these errors were encountered: