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 But the CSS doesn’t actually say that, nor do implementations do that. The context is: I want to implement closing/opening of
…however, the relevant part of the current CSS Containment spec about
…while the relevant part about
So, to conform to the current CSS spec requirements, to allow find-in-page on closed However, just using But if not with |
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 |
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 |