[css-ui] Control whether an element is findable/searchable (Ctrl+F)

[hftf]

I want to control whether an element is findable/searchable via a browser’s Find function (usually accessed with the Ctrl+F or Cmd+F shortcuts).

Why?

In an interface where meaningful elements accompany or interrupt the flow of running text, users should still be able to interact normally with the text as if those elements were inert.

This JSFiddle shows a sentence interspersed with some annotations. Both the words and annotations are marked up with abutting <span> tags. (The example is simplified from a real interface I designed.)

Suppose you want to find a sentence within a long annotated paragraph. Most browsers will only find up to a single word (e.g. Th, This), but not a string of several words (This sentence). That behavior is demonstrated below by Chrome 71/Mac:

GIF showing Find behavior for annotated sentence example

While this feature would primarily be used by authors to improve user experience in browsers, it could also be used by search engines to ignore certain interface elements when indexing or displaying blurbs on results pages.

Current status

The desired behavior is similar to the existing user-select property, which controls whether an element is selectable or copyable.

However, the spec does not define whether user-select affects findability, and if not, does not provide an alternative mechanism for doing so.

CSS Basic User Interface Module Level 4 refers to “findable” once, in the context of generated content:

6.1 Controlling content selection

When generated content in pseudo elements becomes selectable through this mechanism, UAs should also make this content findable through their search function.

CSS Generated Content Module Level 3 refers to “searchable” once, in the context of generated content:

1.1. Accessibility of Generated Content

Generated content should be searchable, selectable, and available to assistive technologies.

Workarounds

Use CSS generated content.

Cons:

• Abuses presentation and removes important semantics
• Not possible to nest or include mixed/phrasing content

---

Other workarounds:

• Use JavaScript to reposition elements
• Use tables for layout

Questions

1. Should user-select encompass findability?
2. If not, should a new control be invented?
3. How do findability, selectability, copyability, etc. interact with similar annotation methods, such as ruby annotation or interlinear glosses in linguistics?
   • Should the default UA stylesheet for ruby define properties like user-select for rt?
   • Should a separate issue be created for this?

More examples

1. Example of English text containing a word with a phonetic ruby annotation (JSFiddle):

   GIF

   

2. Example of per-letter ruby annotations (taken from a recent presentation):

   GIF

   

Further reading

• StackOverflow: HTML: Can you hide/ignore text elements from browser Find (CTRL+F) (▲13, 2013)
• StackOverflow: Is there any way to designate content off-limits to browser's built-in text searching? (▲2, 2015)
• [css-content] Request for note regarding selection, search, and accessibility of generated content (2015) – entire thread

[birtles]

3. How do findability, selectability, copyability, etc. interact with similar annotation methods, such as ruby annotation or interlinear glosses in linguistics?

For the particular case of ruby, it seems like UAs have the information needed to ignore ruby text when doing find in page (or alternatively match only the ruby text and ignore the base text) so this would just be a quality of implementation issue? That obviously doesn't help with the other use cases you mentioned, however.

I'd be a little bit concerned with authors abusing this (e.g. publishers deliberately making their content not searchable) but presumably UAs would provide a way to override this just like one can Shift+right click an element to get the native context menu when the content is overriding it.

[mikkorantalainen]

I think user-select should affect findability because the usual UI is to highlight/select the text that was found and if the user cannot select the text in first place, the find shouldn't do that either. In addition, user-select: none should already overlap with the text that's not worth searching for (e.g. UI elements) so existing use cases of user-select would probably already have correct behavior automatically.

[stefanhamburger]

Another motivating example:

I have a menubar with some options hidden behind a drop-down menu, which becomes visible on hover/focus. I still expose the options to the DOM (with position: absolute; left: -9999px) to allow users to tab through them and have them be part of the accessibility tree.
However, I don't want them to be searchable via Ctrl+F while they're not visible, as the search results would only confuse users.

I would not need a CSS property if I could automatically detect when the browser searches for text; then I could e.g. automatically show the drop-down menu. But this is not possible because search does not trigger a select event or similar.
I like the suggestion to make text with user-select: none not searchable but the current behavior in both Firefox and Chromium is that they will find text with user-select: none.

[emilio]

I filed #9726 with another motivating example, and a strawman proposal:

  user-find: auto | none;

Copying questions from there:

• Does that seem reasonable? It should be extensible in the future if we want to, but that seems like a consistent starting point to me.

• Another question is: Should this property be inherited? user-select isn't, but user-select is really weird. I think it'd be simpler if this one was inherited, but open to other ideas.

cc @josepharhar @mfreed7 @rniwa @fantasai @frivoal

[hftf]

Some annotations may contain meaningful text that one might want to find in some situations, but not in others. This may motivate a use case beyond only two simple values. Taking an example from my OP (and happy 5th birthday to it):

Pablo Casals (“kuh-ZALLS”) became

Pablo <ruby><rb>Casals</rb><rp> (“</rp><rt>kuh-ZALLS</rt><rp>”)</rp></ruby> became

A third option both could be most flexible in situations where the developer cannot assume the user’s intent at any point:

rt, rp { user-find: ____ }	Casals became	kuh-ZALLS	Casals (“kuh-ZALLS”) became
auto: yes, annotation is always in text flow	not found	found	found
none: no, annotation taken out before find	found	not found	not found
both: skippable, tries both options above	found	found	found

Another upside of a third value (both or optional or whatever you call it) is that it can apply to parentheses (rp).

I don't know how browsers implement finding, but the effect of both is like wrapping a (…)? around a regular expression or branching on epsilon in a state machine. Probably easier said than done and there may be other complexities (like what if multiple overlapping matches cross a skippable annotation?).

Perhaps creating a new ARIA role "annotation" that defaults to this both value would help users of assistive technology (AT). Users can still access the annotations (as they are meaningful), but they live in a separated context outside the running text without interrupting it, and can optionally skip them (as a whole or individual). Then the implicit ARIA role of rt and rp can become "annotation".

---

While the topic is fresh, maybe a similar issue of controlling copyability should be considered (probably in another thread). Currently, it is not possible to control whether ruby parentheses (rp) get copied. And if the author didn’t explicitly provide parentheses, should the lack of rp generate parentheses when the user is copying? The status quo is an unreadable result that looks like Casalskuh-ZALLS became even when rp exist.

[josepharhar]

Does that seem reasonable? It should be extensible in the future if we want to, but that seems like a consistent starting point to me.

As a way to make find-in-page stop finding things that are rendered, yeah this seems like a good way to do it. This does not conflate with hidden=until-found because that feature makes hidden things searchable, whereas this is the opposite. One of the reasons that hidden=until-found was moved from CSS to HTML was that the browser is able to modify the state of the attribute when the hidden thing is revealed, but in this case there is no state to change so CSS seems fine.

Another question is: Should this property be inherited? user-select isn't, but user-select is really weird. I think it'd be simpler if this one was inherited, but open to other ideas.

I don't have any thoughts on this.

A third option both could be most flexible in situations where the developer cannot assume the user’s intent at any point:

The particular way that find-in-page finds matches is not specced as far as I can tell and is really user agent dependent, and I kind of feel like this proposal is too imposing or at least would require us to spec how find-in-page really works, which seems like it would take a lot of work. I am not in favor of adding the both value.

Chrome had a feature request to allow case-sensitive find-in-page, but our UX people decided that we shouldn't allow it: https://bugs.chromium.org/p/chromium/issues/detail?id=8717
This isn't exactly the same as allowing the page to tweak how layout influences find-in-page matches, but if there were a proposed way to allow the site to force case-sensitivity for find-in-page results, I fear that it may be at odds with the resolution of that crbug. This layout idea could theoretically also be an option in the browser's find-in-page options in addition to case sensitivity, right?

I don't feel super strongly about this, but I think that we should just consider emilio's property values for now.

[tabatkins]

Yup, this seems reasonable, and I think your syntax is reasonable. (Notably, how it doesn't let you say "definitely make this findable", just "make this findable as normal", so things can stay unfindable if that's important.)

The GitHub use-case is pretty compelling, that's some hefty workarounds.

I think this should be inherited. Aside from a few weird cases, our general rule is "text properties inherit, block properties don't", and this is a text property.

[frivoal]

I'm tempted to say that having user-select affect find-ability is the right place to start. I suspect that the vast majority of the time, that will do what you want. If it isn't enough, we can always introduce user-find as well for the cases where they need to be decoupled, with the two interacting via auto.