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

Accidentally didn't log the discussion, so here it is for posterity:

<details><summary>irc log</summary>
<pre>
 fantasai> jarhar: Hi I'm Joey. I'm working on content-visibility: hiddne-matchable
 fantasai> jarhar: in parallel with HTML feature called ??
 fantasai> jarhar: A lot of websites have sections, like wikipedia
 heycam> s/??/beforematch/
 fantasai> jarhar: and find-in-page doesn't work because it's 'display: none'
 fantasai> jarhar: When searching for these things, want these things to be findable
 fantasai> jarhar: so you would send 'content-visiblity: hidden-matchable' which is same as 'content-visibility: hidden'
 * fantasai q+
 * Zakim sees myles, fantasai on the speaker queue
 fantasai> jarhar: that'll find the element and fire ??
 fantasai> jarhar: and page has ability to change the style to reveal the content
 cbiesinger> s/??/the beforematch event/
 fantasai> jarhar: and after one RequestAnimationFrame
 fantasai> jarhar: browser will scroll to it
 florian> s/??/before match/
 fantasai> jarhar: and that's pretty much thie ideal
 emilio> q+
 * Zakim sees myles, fantasai, emilio on the speaker queue
 fremy> this is a wonderful proposal
 <myles> q-
 * Zakim sees fantasai, emilio on the speaker queue
 fantasai> s/thie ideal/the idea/
 astearns> ack fantasai
 * Zakim sees emilio on the speaker queue
 florian> fantasai: I'm curious, in a lot of cases, it seems it should just work
 florian> fantasai: in the case of a details element, it should just pop open
 florian> fantasai: I'm a little confused as to why we wouldn't want this to happen as well
 fantasai> jarhar: Agree supporting content in details element
 fantasai> jarhar: but separate from CSS property
 fantasai> jarhar: for DETAILS could just say browser can change the state of DETAILS automatically
 fantasai> jarhar: but other case don't use DETAILS element, those use display: none
 fantasai> jarhar: so providing a different way
 smfr> q+
 * Zakim sees emilio, smfr on the speaker queue
 fantasai> jarhar: also CSS state is maintained by page, page has opportunity to change itself
 <antasai> jarhar: 2nd question?
 TabAtkins> q+
 * Zakim sees emilio, smfr, TabAtkins on the speaker queue
 bkardell_> q+
 * Zakim sees emilio, smfr, TabAtkins, bkardell_ on the speaker queue
 fantasai> fantasai: why wouldn't this be the default behavior for 'content-visbility: hidden'
 fantasai> jarhar: could maybe, but some concern around privacy mitigations
 fantasai> jarhar: if we fired on hidden content
 fantasai> jarhar: page, after it gets an event, the page is required to reveal the content or else we lock the page out of using beforematch
 fantasai> jarhar: we want to prevent the page from trying to figure out what the user is searching for
 fantasai> jarhar: and hidden-beforematch is what we're using to determine state
 bkardell_> actually I will just say most of the time that is probably not actually what you want and if you need me to clarify why I can readd to the queue
 fantasai> jarhar: a lot of pages using 'content-visilibity: hidden' already, and would create lockout, so not great
 bkardell_> q--
 * Zakim sees emilio, smfr, TabAtkins, bkardell_ on the speaker queue
 fantasai> jarhar: so that's why
 astearns> ack emilio
 * Zakim sees smfr, TabAtkins, bkardell_ on the speaker queue
 bkardell_> q-
 * Zakim sees smfr, TabAtkins on the speaker queue
 fantasai> emilio: Find-in-page already changes the selection of the document, and that's observable now
 fantasai> emilio: so how useful is this mitigation
 fantasai> jarhar: There are other ways to observe find-in-page
 TabAtkins> So the answer to "why not give 'hidden' this behavior, and then add another value that has the current unmatchable behavior" is "there's already some legacy content that we'd prefer not to break if not necessary"
 fantasai> jarhar: e.g. by listening to scroll events
 * dholbert has quit (Ping timeout: 180 seconds)
 fantasai> jarhar: in Firefox as you type it fires selection events
 fantasai> jarhar: makes it easy to detec
 fantasai> jarhar: in Chromium not the same
 fantasai> jarhar: the selection is only fired when user dismisses find-in-page dialog
 * dauwhe has quit (Client closed connection)
 vmpstr> q+
 * Zakim sees smfr, TabAtkins, vmpstr on the speaker queue
 fantasai> jarhar: so from Firefox point of view, makes sense not to have extra mitigation, but from our side it's needed
 * dauwhe (~dauwhe@ef89345d.public.cloak) has joined #css
 fantasai> emilio: Other question is, this makes find-in-page effectively asynchronous, which is not something that happens
 fantasai> emilio: how does window.find() work and similar things?
 fantasai> emilio: and why does this have to be a CSS property at all?
 fantasai> emilio: I think if you find text in a 'display: none' subtree, and if page reacts to it
 fantasai> emilio: find again or something
 fantasai> emilio: idk
 fantasai> jarhar: for async part, it's true, the whole flow is async
 fantasai> jarhar: first we find the match, then wait for next animation frame, then ?, then wait for next frame, then see if it was revealed
 fantasai> jarhar: that was seen to be necessary ...j
 fantasai> jarhar: based on page, which wasn't handling the style change synchronously
 fantasai> jarhar: but for normal find-in-page use case, whene not 'hidden-matchable'
 fantasai> jarhar: still keeping it synchronous
 fantasai> jarhar: not really sure if we'll fire beforematch or window.find
 fantasai> jarhar: at this point
 fantasai> jarhar: only motivation for me is to make easier to test across platform, but not aware of any use cases for window.find where you need to search hidden content
 astearns> ack smfr
 * Zakim sees TabAtkins, vmpstr on the speaker queue
 fantasai> smfr: ...
 fantasai> smfr: you select into it
 fantasai> smfr: and then you have to realize all the content
 * dholbert (~dholbert@ef89345d.public.cloak) has joined #css
 fantasai> smfr: seems like what you're proposing would bring in content during find, incremental improvement
 astearns> s/.../from what I remember about content-visibility/
 fantasai> smfr: but wouldn't select content
 fantasai> smfr: previously if user did select-all on the document
 melanierichards> present+
 fantasai> smfr: because of selection, would realize content for invisible stuff, woudl be slow (?)
 fantasai> smfr: but find would work in a reasonable way
 * Rossen_ (~Rossen@ef89345d.public.cloak) has joined #css
 fantasai> smfr: with this new thing
 fantasai> smfr: but why is find special?
 fantasai> smfr: what about scroll to text?
 fantasai> smfr: what about seach for addresses, metadata
 fantasai> smfr: #target
 fantasai> smfr: ...
 fantasai> smfr: Why only find?
 fantasai> jarhar: started with find, could expand to other use cases
 fantasai> levin: I think auto already supports all these things
 fantasai> levin: this is adjustment to 'hidden', which is not available to find-in-page
 astearns> ack TabAtkins
 * Zakim sees vmpstr on the speaker queue
 fantasai> TabAtkins: You mentioned how a page doesn't respond to the format event by revealing something, we'll remove their ability to do it
 fantasai> TabAtkins: does that mean we automatically turn the thing visible, or what?
 fantasai> jarhar: We stop firing the beforematch event
 fantasai> jarhar: it's invisible
 fantasai> TabAtkins: so the whole page is broken, not just one aspect of the use
 fantasai> jarhar: Usually there's some other way to reveal content in the page, just find-in-page would be broken
 * plh has quit ("Leaving")
 fantasai> TabAtkins: Before you'd walk up and try to find something auto that could fail open rather than failing closed
 fantasai> myles: So if you catch an event and do nothing, different from not catching the event??
 fantasai> florian: I don't think anyone said that
 fantasai> florian: question is if you don't respond to event, do you stay hidden or get auto-revealed
 fantasai> TabAtkins: Default being to reveal
 fantasai> TabAtkins: if you're responding on your own, would do CancelDefault
 fantasai> jarhar: There's no way to possibly have the browser build the content
 * dauwhe has quit (Ping timeout: 180 seconds)
 fantasai> jarhar: page is in control of the style, same as 'hidden'
 TabAtkins> s/CancelDefault/preventDefault()/
 fantasai> jarhar: CSS property says this is hidden, and until the page reveals, it should stay hidden
 fantasai> jarhar: There's internal state in the thing, and when you search for it, it would unlock similar to 'auto'
 fantasai> jarhar: but direction we're going, page maintains state, and it has to remove the CSS property
 fantasai> TabAtkins: I would like to have more discussion about that
 fantasai> TabAtkins: feels backwards for bad pages
fantasai> TabAtkins: broken JS
 astearns> ack vmpstr
 * Zakim sees no one on the speaker queue
 fantasai> levin: Use cases we're targetting here are things like wikipedia collapsed sections
 fantasai> levin: where there are already handlers that expand the content
fantasai> levin: this would add that find-in-page can expand the content
 fantasai> levin: if there's an error
 fantasai> levin: It prevents pages from figuring out what character is type by incrementally constructing a DOM but never revealing that content
 fantasai> levin: somewhat possible now with scroll offsets, but they're visible always
 fantasai> levin: Content you're searching is visible
 fantasai> levin: would allow you to search content, and remains visible
 vmpstr> S/levin/vmpstr/
 fantasai> TabAtkins: Framing of strict improvement over 'hidden' makes me a little happier
 fantasai> TabAtkins: but think there should be some discussion about whether that's the right way to go
 TabAtkins> s/'hidden'/'display:none'/
 fantasai> +1 to Tab's concern
 fantasai> and to smfr's
 fantasai> astearns: Hearing some concerns around what happens when events break
 <fantasai> astearns: ..
 fantasai> astearns: Wonder if we should take this back to the issue and get more of the proposal fleshed out, and answer questions, then bring back on a regular call
 fantasai> astearns: Any other discussion?
 fantasai> fantasai: Just +1 to TabAtkins and smfr's questions and conerns
</pre>
</details>

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


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

Received on Tuesday, 20 October 2020 21:51:34 UTC