07:47
<nakima>
What's the matrix "script"
07:49
<nakima>
Woe
08:40
<sideshowbarker>

TabAtkins: (or any others here with insight into this area) Is there any mechanism I can use with either CSS and/or HTML attributes to programatically toggle a node’s “relevant to the user” state? And a way to use that in combination with its content-visibility state to toggle making it visible?

On the face of it, it seems like what the HTML inert attribute means is the same as what CSS means by “not relevant to the user” — and so, the combination of inert + content-visibility: auto could/should cause a node to be non-visible.

But the CSS doesn’t actually say that, nor do implementations do that.

The context is: I want to implement closing/opening of details elements using content-visibility internally but also make the contents searchable with find-in-page. The relevant part of the current HTML spec requirements say to use hidden:

The details element's second slot is expected to have its style attribute set to "display: block; content-visibility: hidden;" when the details element does not have an open attribute.

…however, the relevant part of the current CSS Containment spec about hidden says this:

The element skips its contents. The skipped contents must not be accessible to user-agent features, such as find-in-page, tab-order navigation, etc., nor be selectable or focusable.

…while the relevant part about auto says this:

If the element is not relevant to the user, it also skips its contents. Unlike hidden, the skipped contents must still be available as normal to user-agent features such as find-in-page, tab order navigation, etc., and must be focusable and selectable as normal.

So, to conform to the current CSS spec requirements, to allow find-in-page on closed details elements, it seems I actually should not use hidden to make them closed (despite what the HTML spec currently says), but should instead use auto.

However, just using content-visibility: auto for closed details will not on its own make their contents non-visible — instead it seems I need to somehow also make the contents not “relevant to the user”. And to me at least, it seems like inert could/should be the way to do that, and the CSS and/or HTML specs could/should say that.

But if not with inert, is there some other way to make a node not “relevant to the user”?

09:07
<sideshowbarker>
Or alternatively, we could change the HTML spec to not say that content-visibility should be used for details — but instead just that UAs must make the contents of closed details elements non-visible to users (using whatever internal means the UA chooses to use for that) while also requiring the contents must not be skipped contents for the purposes of find-in-page. (While also having the spec continue to state that for any closed details in which find-in-page locates a match, the UA must auto-expand it — by setting its open attribute).
09:14
<sideshowbarker>
It’s starting to seem to me now that having the HTML spec say that UAs are expected to use content-visibility for closing/opening details may not be a great choice. It certainly doesn’t seem necessary to use content-visibility for that case, because the CSS content-visibility state of any details contents is not observable by web developers anyway.
09:26
<sideshowbarker>
All that said, though, I guess since it’s not exposed/observable to web developers anyway, then it seems like I could reasonably argue that implementing opening/closing of details with content-visibility: hidden internally doesn’t strictly break conformance with CSS spec requirements
10:38
<zcorpan>
sideshowbarker: hmm, what gives? https://participate.whatwg.org/agreement-status?user=sideshowbarker&repo=html&pull=9870
10:39
<sideshowbarker>
zcorpan: sigh yeah that’s because my membership in the relevant GitHub organization is private, not public
10:40
<sideshowbarker>
I very much don’t like the fact that the participation mechanism requires me to make my membership in that relevant GitHub public
10:40
<sideshowbarker>
but anyway, I can turn it back on temporarily
10:42
<zcorpan>
sideshowbarker: hmm, can you create a new GH org that's just for the IPR check?
10:42
<sideshowbarker>
Yeah, I guess I could, but I rightly shouldn’t have to
10:43
<sideshowbarker>
Instead, the participation mechanism should be made to work in some different way
10:44
<sideshowbarker>
And I don’t say that personally about my own case — but in general, for all participants, we should not be forcing them to publicly leak any organizational membership to the entire world that they might not really want to
10:45
<sideshowbarker>
Myself, a while back, I made all my GitHub org memberships private — because I don’t personally have much need to make them public
10:45
<sideshowbarker>
We should be allowing everybody to have that same choice if they want
10:45
<zcorpan>
sideshowbarker: seems like something to bring up with the sg
10:46
<sideshowbarker>
In the past, I have not had much success in getting the SG to see anything my way
10:46
<sideshowbarker>
I tried with the pseudonymous-contributor case, and lost
10:49
<sideshowbarker>
I also tried with the case of distinguishing editorial/non-substantive/no-possible-IPR-impact changes from substantive/IPR-impacting changes — and I think the SG ended up deciding to make some change there, but if so, it was after such a long time that I had lost energy for paying attention
10:53
<zcorpan>
https://github.com/whatwg/sg/pull/228
17:06
<Jeffrey Yasskin>
And I don’t say that personally about my own case — but in general, for all participants, we should not be forcing them to publicly leak any organizational membership to the entire world that they might not really want to
I have mixed feelings about that: on the one hand, you're right that people should be able to participate in github without their affiliations always being fully public. On the other, when someone's contributing to an open standard on behalf of their employer, it's both useful for reviewers to know that we should think of their contribution as coming from that organization, and important for the public to be able to see what organizations are influencing the standards. I wish Github had a "public-but-not-publicized" setting for this, where the affiliation would appear in the context of certain contributions, but wouldn't appear on the profile page.
20:03
<Arnau>
For HTML tree construction, is the stack of open elements a stack of elements or nodes? By the name I would guess elements, but the definition (https://html.spec.whatwg.org/multipage/parsing.html#stack-of-open-elements) seems a bit ambiguous and says "the topmost node on the stack is the first one added to the stack". Plus, if the stack only has element nodes, wouldn't the current node and adjusted current node always be elements?
20:08
<Andreu Botella>
The stack of open nodes can also be seen as the set of ancestors of the current point in the DOM into which you're currently parsing
20:09
<Andreu Botella>
since the stack is created empty (so there's no Document node in it), and the only non-Document nodes that can contain children are Element nodes, I think it can be safely assumed that it only contains elements
20:09
<Andreu Botella>
(oh, actually Document also can't contain children)
20:25
<Arnau>
Oh, I get it
20:25
<Arnau>
So I can make it a stack of element nodes, right?
23:55
<Eric Portis (he/him)>
TabAtkins Florian Rivoal: should contain-intrinsic-size alter Image.naturalWidth/Height ? https://codepen.io/eeeps/pen/RwOKmJL?editors=1111