Re: [csswg-drafts] [css-contain-2] Proposal: content-visibility: hidden-matchable (#5595)

**Disclaimer:** I have read this issue, [TAG review #511](https://github.com/w3ctag/design-reviews/issues/511), [the explainer](https://github.com/WICG/display-locking/blob/master/explainers/hidden-content-explainer.md), and various linked documents, at least twice. I am in favor of the idea and I thank those who have worked on it so far. I am an author, not an expert, and I hope my contribution will be useful. Please correct me if I’m wrong about anything!

---

The question below does not seem to have been directly discussed much yet:

> Is it the correct decision to integrate this feature with `content-visibility`?

I am concerned that extending the `content-visibility` property with the value `hidden-matchable` conflates two concepts at once: visibility and searchability.

## Searchability is the desired primitive

The new [primitive](https://extensiblewebmanifesto.org/) most relevant to this proposal is the concept of **searchability** (or findability, matchability, etc.). Searchability could be thought of as a new general property of any element. Even some non-elements with visible text could theoretically be made searchable, such as CSS generated content or tooltips using the HTML title attribute.

In #3460, I make a case for essentially the inverse of this proposal. As the OP summarized, this issue (#5595) is about making hidden text searchable, while #3460 is about making visible text non-searchable. Note that visibility is not relevant to #3460.

An isolated design for #5595 that does not take into account #3460 could undesirably result in two very different, confusing solutions for handling the same single primitive: searchability.

## Searchability belongs in CSS

* CSS already has tools to control the visibility of content. They include `display: none`, `visibility: hidden`, and now `content-visibility: hidden`. (HTML5 has the `hidden` attribute as well, and there are probably more hiding mechanisms I haven’t mentioned.)

* Precedents already exist in CSS for controlling (enabling or disabling) other primitive user interaction abilities via specific properties. They include selectability and copyability via  `user-select`, and clickability via `pointer-events`.

* In a similar fashion, a new property could let authors declare the searchability of an arbitrary element. It could be called something like  `user-search` or `content-matchable` or whatever. Has this been considered?

It seems hard to determine whether user interaction abilities belong exclusively in the semantic/markup layer or in the style/presentational/visual layer. But for the purposes of this proposal, it is mostly thanks to CSS that the visibility of content (semantic markup elements) is controlled at all.

Imagine a Wikipedia article with a section containing a paragraph. By default (HTML only, no CSS), the paragraph would be visible and searchable. To better fit the experience on mobile devices, the authors then chose to add CSS and Javascript to change the particular “presentation” of the page, letting sections collapse. It does not seem consistent for the visibility of the paragraph to be disabled via the style layer, but the searchability of the paragraph to be re-enabled via the markup layer.

That being said, the key idea behind searchability is whether or not certain content is **conceptually** thought of as being part of the same document. (Hidden content may or may not be conceptually part of the document, just as visible content may or may not be conceptually part of the document.) This important point is acknowledged in the OP (emphasis mine):

> **hidden-matchable**: Content is not technically shown to the user visually (and as a result the UA need not spend time rendering it by default), but **is conceptually part of the current view** and is only not shown because it's inside of a UX pattern such as an accordion or their off-screen portions of a userland infinite list.

If for over 20 years, authors had not already been mainly using CSS to declare whether markup is visible or not – and, as a result, to usually make a verdict on its meaningness (its conceptual relevance) – then it might make more sense to use the markup layer to notate whether an element is “conceptually part of the document.”  (Remember that CSS visibility notably affects the accessibility tree too.)

## Is there an argument for this being in  `content-visibility`?

I am trying to understand the reason why this feature belongs in the scope of `content-visibility`. Is it because optimization is most important? (i.e. the feature will only be applied to the few elements specifically marked as relevant to it via `content-visibility: hidden-matchable`, and tying it to visibility means that authors necessarily cannot misuse it, such as by applying a broad rule like `* { user-search: searchable; }` that defeats the purpose of the optimization)

Scanning an element for two style conditions – the hypothetical `user-search: searchable` and `display: none` – should not involve much more computation than the method implied by the current proposal, which scans for one condition.

## Some use cases

[As noted](https://github.com/WICG/display-locking/blob/master/explainers/hidden-content-explainer.md#cons-5), the `<details>` element only makes sense for some use cases. Semantically, “the [`<details>`](https://html.spec.whatwg.org/multipage/interactive-elements.html#the-details-element) element represents a disclosure widget from which the user can obtain **additional** information or controls.” In other words, hidden-ness is a property that can apply to any element (thanks to CSS and Javascript) and is not in 1-to-1 correspondence with `<details>`’s semantics.

Below are some scenarios in which hidden content can be considered to be conceptually part of the same document.

* Toggleable/collapsible/expandable/foldable sections (or section headings)
  * Wikipedia mobile site. Not implemented using `<details>`, but arguably I suppose it could work semantically.
  * Recursively nested comment threads (forums, Reddit, outliners)
  * Generated table of contents, `.focus()` should still work
* Paginated lengthy content
  * E-books [(the example above)](https://github.com/w3c/csswg-drafts/issues/5595#issuecomment-776179117)
  * Paginated tables
  * [Discourse forum threads (only 5 posts are dynamically partially loaded at a time)](https://meta.discourse.org/t/discourse-taking-over-ctrl-f/16190/2)
* Automatically scrolling content (accordions, carousels, marquees)
* “Infinite scrolling” (Twitter)
* Audio/video captions (usually, only the current caption is visible, unless you open the entire transcript)
* Slideshow presentations (usually, only one slide is visible at a time, unless you open the slide overview)
  * e.g. [reveal.js](https://revealjs.com/)
* Modals temporarily blocking main content (the modal may not even be conceptually part of the document)
* Really anywhere you’ve seen a “read more” or “show the rest of this thread” button to click to reveal or load on demand (won’t name examples, since it’s so ubiquitous)


-- 
GitHub Notification of comment by hftf
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5595#issuecomment-778223559 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 12 February 2021 14:20:31 UTC