Alice: was just reviewing... Reading joey's comment - not sure how useful for other things it really is... For cases like the details element...

... feels like he slightly misunderstood what I said about pseudoselector... It really depends on the content - only useful for when the content was previously hidden and is being shown as a result of the user interaction that triggered this event...

... most of the alternatives - says "doesn't allow content to become hidden again"... don't understand why the proposed solution does that.

Ken: you can remove it...

...reviewing explainer...

Alice: let's ask for clarification on that... I will take an action to read this and get to the bottom of that. Still don't undertsand why a better design wouldn't be automatic unlocking plus a pseudoselector.

Ken: is it always find in page

Alice: also scroll-to-text... Seems like you're forcing authors to listen for the event - extra work for authors. Could go badly for users if authors don't do that work... I don't understand the cons of the automatic unlocking options.

Ken: [reading through comments...]

... if you search for something in the DOM but it's hidden you have the ability to unhide it ...

... notifies the page when the match is found ...

Dan: let's move this to the plenary.

Ken: I think it's pretty good...

Alice: Skimmed the combined explainer.... Looking at responses.

Alice: a new privacy & security section

Ken: [lists some fixes]

Alice: the idea is so you can't do a brute force attack

Ken: also prevent building out a string of what the user is searching for

Alice: that makes sense. Also got my head around -- one of the alternatives when you get a match is to show it. I understood why they don't want that. once it's showing you don't know when to hdie it again... So putting the developer in charge of when it closes but because it's a CSS property it becomes ambiguous . So in order to not have to answer questions - you have it closed when the property applies and have the developer manually open it.

... so when I suggested a pseudo-selector. They mentioned as a use case wanting to highlight the search string. ... you can only get the berforematch event on hidden matcheable content. And you have to remove hiddenmatcable...

... but - say I'm typing lorem ipsum and I've typed "lore" and it's matched..

Ken: we don't want the web site where content is moving forward and back... so a grace period.

Alice: that's my one remaining question - fairly straightforward. Any other web spec that works like that where CSS gives you access to a DOM feature?

Ken: painting and layout? We have contains and with the Houdini APIs some of the other CSS properties will be exposed... resize observer and it won't resize because it's not doing layout...

Alice: those are my 2 main thoughts - can they be more percise about the 2nd security mitigation; other one is having the event only fire on content in the DOM tree of a hiddenmatchable element <- seems like a good security measure but not sure if there is a precedent between events and CSS properties.

Alice: maybe coming to us earlier would have been better.

ken leaves a comment

[alice will leave a comment]

[bumped]

Rossen: Caught up Alice to previous 5c discussion.

Alice: Cleared up the expectations of proposed behavior. The feature applies to content that is already part of the DOM but kept out of the render tree, similar to display:none with the only difference that if a Find-on-page algo runs, it will match the query.

Rossen: Great, why isn't this an optional value of display? Something like display:none matchable; This way we have clear expectations of the behavior inside the element (no animations, transitions etc.) while allowing matches. ... Further, is the content inside the hidden-matchable available for name computation of ARIA?

Alice: It should be similar to the way we do it for display:none. Also, the intent of the feature is to apply to the contents only and not the element itself.

Rossen: Sounds good and I'm convince we should let the work continue moving forward with CSSWG. I'll add closing comments and suggest adding a WPT test along that verifies ARIA name computation works as expected.

@kenchris, @alice and myself took another pass reviewing the final proposal of the feature during our "Kronos" VF2F. Overall we are happy with the current design being a CSS property instead of HTML attribute. The functionality is similar to display:none if we were to add an optional matchable value and make it apply to the contents of the element and not the element itself.

One important question that came up during the review is whether we have verified that this new way of making content hidden is handled correctly per the Name Computation algorithm. Since this feature makes content hidden our expectation is that the behavior will be similar to that of diaplay:none and we ask that you consider adding a WPT test to cover that scenario.

Specifically, that an aria-labelledby or aria-describedby attribute which refers to an element within a content-visibility: hidden, content-visibility: auto or content-visibility: hidden-matchable block will correctly expose the text of the element as contributing to the name/description of the referring element:

<input aria-labelledby="a-label">
<div style="content-visibility: hidden-matchable">
  <span id="a-label">This should be the label of the above input</span>
</div>

Thank you for working with us.

Ken: It looks like this was reviewed with the CSSWG already and they deffered to TAG.

Rossen: That's right, we did talk about it with CSSWG but did not accept the feature. Instead of accepting, the SCSWG resolved to have TAG look at it first and then only move forward with working on it further.

Rossen: I'm still a bit worried about the a11y aspect of the feature. The change in behavior here can have the subtle affect of content not being available to users as it used to before. In other words, I'm a user opens a long Word document they are expecting that all headers, paragraphs etc. to be available to them. Setting hidden-matchable inside such document will now hide sections until they're in view or matched. Unless the AT query for the next header is the equivalent of a find-in-page, which isn't the case today, the content won't be abailable to the user and apear broken.

... I have two consecutive sessions with Alice later today. This seems to be one of the last issues with the proposal, let me go over it with her quickly and propose next steps.

Ken: Sounds good. Also, it does seem that the path forward for the feature is with the CSSWG as a property and not an HTML attribute for example.

Rossen: Agreed.