- From: François REMY via GitHub <sysbot+gh@w3.org>
- Date: Tue, 09 Feb 2021 19:20:27 +0000
- To: public-css-archive@w3.org
> hidden-matching adds a new level of ambiguity about what content is "visible" That's true. I think that's a useful distinction to make though, because I can't find another way to achieve this. Maybe we should work on examples of use cases though, I feel this discussion was not rooted in concrete cases, which tends to yield more questions than answers. Maybe there's something obvious that already would solve this and we didn't notice. > why Find gets special treatment, given the other ways content is exposed by UAs That is something I would argue is indeed wrong. In the ideal world, the provisional content would also display in the accessibility tree (even as a place-holder template). In a way, I think we want something that says "this is not visible to the user yet, but it should be searchable/scannable" (and the UA's find feature is only one way to do so). After that, user agents might have bugs, and initially limit this to only search if that is the only thing they have budget for, but I feel this would be wrong indeed. What are other examples of things you believe would be useful to have this type of hidden content exposed to? > Reader detection can't use the same level of more efficient but less precise content traversal without making it appear buggy to users. Probably true. But the question is "does the Reader mode works better today"? Right now, I assume that the Reader mode doesn't seen hidden content at all. In this case, we are exposing new content to the Reader mode that it should see, possibly with reduced functionality. But if it was `display:none` you wouldn't see this content at all, which arguably is a worse kind of buggy. I guess we should do a before/after. ---------------------------------------- In the spirit of trying to talk about use cases, here is the one that got all of this started, mobile wikipedia: <table><tr><td>  </td><td>  </td></tr></table> This is done using the following piece of CSS:  As things stand today, the content in the sections is: * not searchable using find (neither on the iPhone nor on my desktop browsers in mobile mode) * not exposed to accessibility software (I assume everywhere, I don't see how that would be the case) * probably not used for reader mode computations? (maybe not though, because the rule only applies if js is detected which might be asynchronous; that hidden text is currently displayed on my iPhone's reader mode when I force-enable it but I can't know how that works behind the scenes) In this use case, I don't see how things would be worse if there was a toggle to say that "the content inside that `display:none` element should be searchable. Making this text searchable is not very complicated for the website, because simply removing the `display:none` fixes everything. So if the browser sends an onbeforematch event on the section, it can just add an "expanded-section" class and everything will work as expected. ---------------------------------------- The second use case I have in my mind is a Word or ePub reader. Usually, this type of document is split into "chunks of content" (like pages, or chapters) which can be layouted independently. But there is so much content that layout out everything would probably cause a visible slow down. So the trick is to load content on-demand when it becomes scrolled to. The issue is that this prevents searching this content (and, for accessible users, it prevents displaying the list of headings, etc...).  Here again, each of these chunks can be marked as "currently-hidden but should-be-scannable". Then when you search through the book, you find that a word you are looking for is located on page 356. So the browser sends an event asking for page 356 to be converted from "currently-hidden but should-be-scannable" to "visible". Removing `display:none` might be sufficient to do that, but some other processing might be necessary to achieve this (maybe some work is performed only on demand, like for instance rehydrating visualization components like interactive graphs, or maybe some of the fine-grained styling requires additional data). In this case, I don't think it is possible not to set `display:none` on the many pages of the book if you want good performance. A reader view should probably add this content, but load it as it comes into view. This might require additional development from the reader view, but this seems reasonable to me. In many cases though, maybe the reader mode can just ignore the "hidden but searchable" mark? ---------------------------------------- Are there other use cases that should be considered? -- GitHub Notification of comment by FremyCompany Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5595#issuecomment-776179117 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 9 February 2021 19:20:30 UTC