- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 14 Feb 2024 23:04:12 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-ui] Control whether an element is findable/searchable (Ctrl+F)`. <details><summary>The full IRC log of that discussion</summary> <TabAtkins> emilio: i recently stumbled across the problem<br> <TabAtkins> emilio: github has an interesting use-case where they effectively neutralize the rendering of what you see<br> <TabAtkins> emilio: but for a11y they render text on top in an invisible textarea<br> <TabAtkins> emilio: in a way where, if they did the naive thing, ctrl-F would find the text twice<br> <TabAtkins> emilio: so instead they do terrible hacks to prevent that from working<br> <TabAtkins> emilio: but firefox's ctrl-F is better, so they do *worse* hacks<br> <TabAtkins> emilio: which then causes perf problems in firefox because the dom is 100x bigger<br> <TabAtkins> emilio: there are other properties that control findability<br> <astearns> s/is better/is better because it finds content in pseudo-elements/<br> <astearns> (like it says to do in the spec)<br> <TabAtkins> emilio: there are use-cases for having this separate from text selection (like pseudo-element text can be selected but not always findable)<br> <TabAtkins> emilio: Like PDF.js will render transparent text on top fo the PDF so you can search for it and select it<br> <TabAtkins> emilio: so there's no good *heuristic* for auto-determining text shouldn't be findalbe, that won't break some use-cases<br> <TabAtkins> emilio: so obious solution is providing some control over it<br> <TabAtkins> emilio: suggestion is an inherited user-find property that takes auto and none<br> <TabAtkins> emilio: `auto` does "the reasonable thing" (find isn't very well specified)<br> <TabAtkins> emilio: and none definitely makes it unfindable<br> <TabAtkins> emilio: You def don't want stricter control like "always make this findable" if it isn't displayed<br> <TabAtkins> emilio: so i think this proposal solves these use-cases<br> <iank_> q?<br> <TabAtkins> emilio: initially, tying it ot user-select looked like ab etter approach, but i convinced myself it doesn't work great<br> <iank_> q+<br> <TabAtkins> fantasai: a bunch of the examples i nthe issue are about ruby<br> <TabAtkins> fantasai: ruby annotations breaking contiguity<br> <TabAtkins> fantasai: that's justa bug<br> <TabAtkins> emilio: right, should be fixed<br> <florian> q+<br> <TabAtkins> fantasai: because you should also be able to find the annotation<br> <TabAtkins> emilio: yup<br> <emilio> https://github.com/w3c/csswg-drafts/issues/9726<br> <TabAtkins> emilio: I find similar examples in some other editors over time<br> <schenney> Sorry not in the meeting, but am reminded of user-select.<br> <TabAtkins> emilio: somebody filed a bug when i made text in a textarea findable<br> <TabAtkins> fantasai: i think the user often wants to find things hat the author didn't want them to find<br> <TabAtkins> emilio: problem here is double-finding<br> <TabAtkins> fantasai: can we solve those cases tho?<br> <TabAtkins> TabAtkins: use-case here is they want to offer a mor epowerful Find<br> <TabAtkins> emilio: also they want to virtualize large files<br> <TabAtkins> emilio: if the whole giant file is in textarea for a11y, that's fine, but you want to virtualize just about a page-worth of content in rich dom<br> <TabAtkins> emilio: but then the thing on screen shows up twice<br> <TabAtkins> fantasai: my concern is that a lot of use-cases presented here *aren't* reasonable<br> <TabAtkins> fantasai: so if we offer it people will do the wrong thing a lot<br> <TabAtkins> emilio: but you can say the same thing for user-select<br> <TabAtkins> emilio: sometimes annoying for users, but sometimes very good for authors (and uses)<br> <TabAtkins> fantasai: i dunno, not totally convinced<br> <TabAtkins> TabAtkins: i'm convinced, i think it's fine<br> <florian> q?<br> <TabAtkins> iank_: there was a period a few years ago where a lot of news sites were trying to make it difficult to select/copy/etc<br> <TabAtkins> iank_: i could see this being used to make the whole page unsearchable? any thoughts?<br> <TabAtkins> emilio: yeah, you can make annoying things. you can already do that in various ways.<br> <TabAtkins> emilio: we *try* to make visible thins findable<br> <florian> q-<br> <TabAtkins> emilio: the way we try to appraoch sites that hijack the context menu, is provide users ways to bypass<br> <TabAtkins> emilio: like in firefox shift-rightclick shows the original context menu<br> <khush> q?<br> <khush> q+<br> <TabAtkins> emilio: in general there are reasonable use-cases, and we expose worse functionality, so this isn't that bad and worth the use-cases<br> <florian> q+<br> <TabAtkins> khush: You point to one example, the argument is browsers aren't able to find this sentence because of annotations...<br> <khush> https://jsfiddle.net/jw8do93r/<br> <TabAtkins> fantasai: these probably *should* be ruby and marked up as ruby annotations<br> <TabAtkins> khush: right, if the author hides the annotation so the sentence is searchable, the annotations won't be<br> <TabAtkins> emilio: the interaction of the featur ewith adjacent content... this wouldn't even work in our find imples<br> <TabAtkins> emilio: the words in spans are in inline-block<br> <TabAtkins> emilio: and i dont' think we deal well with things spanning lines across blocks<br> <vmpstr> q+<br> <TabAtkins> emilio: i don't think we want people to use this feature for this use-case<br> <TabAtkins> khush: it was kinda funny that this was just the first example someone posted why they want the feature, when we said we didn't want it for this example<br> <TabAtkins> florian: I was originally convinced it shoudl be in user-select, i now agree it shouldn't. unsure if it shoudl exist at all. if it does...<br> <TabAtkins> florian: values are auto and none. for auto, you have heuristics<br> <TabAtkins> florian: if browsers have different opinions about pseudo-elements and whatnot, would it be good to have a third value that overrides the heuristics and make it searchable?<br> <TabAtkins> emilio: why would a browser not make it searchable tho<br> <TabAtkins> emilio: browsers dont' do it today as a tech limitation<br> <TabAtkins> emilio: like khush's example doesn't work due to tech limitations in Gecko anyway, this feature won't help<br> <TabAtkins> vmpstr: i'm a little concerned from a11y pov, i think finding content is more important than selecting content<br> <TabAtkins> vmpstr: i don't want to lump it into user-select<br> <TabAtkins> vmpstr: i think for github, potentially we can find ways of solving that expensive-rendering problem different<br> <TabAtkins> vmpstr: we've attempted that with content visibility<br> <TabAtkins> vmpstr: where you render what's requried but whole DOM remains available<br> <TabAtkins> vmpstr: if that's not good enough i'd rather revisit that<br> <TabAtkins> emilio: i'm not particularly sure why they chose that approach, but i do know that due to Firefox being able to defeat their basic hack, they serve a ridiculous giant DOM and make us super slow<br> <TabAtkins> vmpstr: that's fair, i just don't think that a blanket "you can't search this but you can see it" is a great direction from a11y<br> <TabAtkins> emilio: we do allow similar beahvior controls<br> <TabAtkins> emilio: in this case the thing you're finding isn't visible, but we allow you to find it becuase we don't realize it<br> <dholbert> q+<br> <TabAtkins> emilio: the textarea is transparent<br> <TabAtkins> emilio: so today if you hide it from search you also hide it from a11y<br> <TabAtkins> vmpstr: Right, that distinction doesn't seem great, anytime the two differ it's suspicious<br> <dholbert> q-<br> <TabAtkins> fantasai: two comments. first, if we go in this direction, we should get browsers to fix their ruby annotations disrupting searching<br> <TabAtkins> emilio: yeah this feature might not even improve that issue in browsers<br> <fantasai> s/searching/searching first/<br> <TabAtkins> emilio: depending on the markup you still might not be able to find across elements<br> <GameMaker> q+<br> <bkardell_> huh?<br> <TabAtkins> fantasai: second, highlight vlad's comment that if you hide something from finding but expose to a1y that's weird<br> <TabAtkins> fantasai: third, we have a control already to let us hide things from a11y but not visibly, and vice versa<br> <emilio> q+<br> <emilio> https://bugzilla.mozilla.org/show_bug.cgi?id=1699599 is relevant here<br> <fantasai> s/if we go/if we want to go/<br> <TabAtkins> dbaron: i had the thought, potentially you could have a none value that isn't quite as none as you were intending<br> <TabAtkins> dbaron: but instead is "i want this to not be findable if it isn't visible"<br> <TabAtkins> dbaron: so it biases more toward none but wouldn't prevent visible text<br> <TabAtkins> emilio: but that wouldn't work for github<br> <astearns> 'visible' being potentially visible if scrolled to, perhaps?<br> <TabAtkins> dbaron: the one other thought it, i think fixing the ruby case properly requires essentially allowing multiple readings fo the same dom to be found<br> <TabAtkins> dbaron: i don't know if there are other things with that characteristic<br> <florian> q?<br> <TabAtkins> dbaron: i suspect not, so that does make ruby thing hard to fix. not impossible, but more difficult<br> <florian> qq+<br> <TabAtkins> emilio: i was curious - gecko ignores ruby annotations for Find, so you can find the whole base. that's not controlalble, we just skip them<br> <florian> q-<br> <TabAtkins> emilio: so i want to separate this from the ruby thing because annotations are already unfindable<br> <TabAtkins> fantasai: they'll use this property wrongly if we don't get ruby to search correctly in other browsers<br> <TabAtkins> GameMaker: unsure if relevant, but there's another way to search in pages which is scroll-to-text-fragment<br> <TabAtkins> GameMaker: I think it tries to avoid finding things aren't visible<br> <TabAtkins> GameMaker: it's another way to find things, kinda weird that it's a unique impl<br> <TabAtkins> emilio: i agree ideally this wouldn't be a distinct algorithm<br> <florian> q+<br> <TabAtkins> GameMaker: yeah it's different from Find, handwaves some spaces, and generally is a little weird<br> <TabAtkins> fantasai: i'm not hearing consensus<br> <dholbert> TabAtkins (IRC): it sounds like, of the two major use-cases, one is ruby-basd, the other is virtualization-based<br> <fantasai> TabAtkins: It sounds like a lot of the objection is, of the two use cases one is ruby which is a bug, and another one is virtualization, which should be fixed by content-visibility<br> <florian> q-<br> <fantasai> TabAtkins: Maybe improve ocntent-visibility cases, maybe there will still be a need for virtualization, but either way ...<br> <TabAtkins> emilio: i'd say that realistically this pushes us to make our find impl suck, but<br> <fantasai> TabAtkins: Or maybe there's a third use case that motivates this feature<br> <fantasai> TabAtkins: I think investigating why not using content-visibility is worth doing<br> <fantasai> TabAtkins: helps everyone<br> <TabAtkins> emilio: i think part of the reason is that size of the syntax-highlighted dom can still be substantial<br> <TabAtkins> emilio: so you're shipping a giant dom that effectively contains the text content of the file<br> <TabAtkins> emilio: they wrote up a whole big thing about why they did what they did<br> <fantasai> TabAtkins: I saw that article, I do not remember whether or not they mentioned content-visibility<br> <fantasai> TabAtkins: I can 100% believe that rendering giant synax-highlighted DOM would be expensive, but the whole reason for us to introduce content-visiblity was assuming that DOM is relatively cheap as long as not rendered<br> <fantasai> TabAtkins: so should be able to handle large DOMs like this without too much trouble<br> <fantasai> TabAtkins: Maybe GitHub is an outlier, and shipping that much DOM is still a significant prolem that exceeds our expectations<br> <fantasai> TabAtkins: or maybe virtualization is still a problem andn our assumptions were wrong<br> <fantasai> TabAtkins: but we should figure that out<br> <TabAtkins> fantasai: so it sounds like we don't have consensus to adopt this. suggest we look into the reasons why people would be needing this.<br> <TabAtkins> emilio: realistically we could make the same argument about user-select<br> <fantasai> TabAtkins: user-select is more behavior thing, this is about making a slightly hacky solution (virtualization) less bad<br> <TabAtkins> emilio: I can find the other use-cases i find that were editing related<br> <TabAtkins> emilio: why are editors using a separate text area? If you're editing plain text...<br> <TabAtkins> i can find it and bring it back if it will change opinions<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3460#issuecomment-1944939280 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 14 February 2024 23:04:15 UTC