Re: [w3ctag/design-reviews] Beforematch event and content-visibility: hidden-matchable (#511)

After several discussions at the CSSWG, they are OK with the new content-visibility:hidden-matchable property if the TAG approves it as well.
I updated [the explainer](https://github.com/WICG/display-locking/blob/master/explainers/hidden-content-explainer.md) to include answers to the issues they brought up:
- Reader mode
Should hidden-matchable content be included in reader mode?
We should recommend it be included because it’s semantically part of the document.
- Accessibility
Should hidden-matchable subtrees be included in the accessibility tree?
No, as Alice said [here](https://github.com/w3c/csswg-drafts/issues/5595#issuecomment-722723687), because content shouldn’t be included in the accessibility tree until it is actually visible on the page.
- Which user-agent algorithms should be able to fire the beforematch event on hidden-matchable content?
Find-in-page, ScrollToTextFragment, and ElementFragments should both fire the beforematch event, and we can add it to their steps in the spec.
- hidden-matchable content is “part of the current view” but not currently visible on-screen. Is this confusing to developers? (raised by @smfr).
- Should hidden-matchable be a CSS property or an HTML attribute?
Many accessibility features are in CSS. For example, the Chromium accessibility tree uses CSS to make decisions about what is visible or not to this tree.
It's much more ergonomic for developers to use CSS. It's also highly related to the semantics of the existing content-visibility CSS property, so adding an attribute would end up with a matrix of corner cases and a more confusing API.
It’s also easier to upgrade an existing site with CSS, since they will likely be replacing display:none with content-visibility:hidden-matchable.

> As far as I understand, the user has to reveal the content immediately when a match is found, which might result in content shifting around. Especially I might be typing "icecream" really fast, making a section with the text "ice" show and then unmatch because it didn't contain "icecream". Should there be a bit if grace period, like find-in-page text only triggering an event when the user has made a small pause, like say 50-100ms?

I think that the grace period could be implemented later as a separate feature for find-in-page because the same problem already exists without this feature: when you start typing a word, Chrome will try to find everything starting with the very first letter you type, which can slow down the page and/or jump around unexpectedly. Safari, however, has a delay already implemented, and it would exist as part of the browser’s find-in-page UI instead of being something implemented in the rendering engine like this feature is.


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/511#issuecomment-767007651