- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 18 Oct 2023 16:38:17 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[cssom-view] What does element.checkVisibility() return for display: contents elements?`, and agreed to the following: * `RESOLVED: Close no change, reopen if use cases are presented on the issue` <details><summary>The full IRC log of that discussion</summary> <emilio> ntim: right now checkVisibility will return that display: contents elements are not visible because they don't have a box<br> <emilio> ... which I find not very intuitive<br> <emilio> ... I don't know if that was intentional or not<br> <emilio> ... WPTs don't test for this<br> <emilio> q+<br> <astearns> ack emilio<br> <vmpstr> emilio: FF also returns this, not sure if it was intentional. I can see usecases. The spec is not ambiguous<br> <vmpstr> q+<br> <emilio> ntim: it's weird because display: contents is technically visible<br> <astearns> ack vmpstr<br> <emilio> astearns: it's children are anyways<br> <emilio> vmpstr: I don't think this was intentional<br> <dbaron> (leaving the meeting now)<br> <emilio> ... idea was to catch display: none and so<br> <emilio> ntim: my suggestion would be to check for the element or any flat tree ancestor having display: none<br> <vmpstr> emilio: seems ok-ish to me, but i also think there are use cases for making display:contents or considering it invisible. So maybe this should be opt in. I don't know<br> <noamr> q+<br> <vmpstr> ntim: you can see display contents elements<br> <vmpstr> emilio: you can see their children<br> <vmpstr> astearns: you don't see the box, it's background, just its children<br> <bradk> Bay Area just had a small earthquake<br> <astearns> ack noamr<br> <emilio> noamr: What is the behavior for an element with visibility: hidden that has children with visibility: visible? I'd expect this to be consistent<br> <emilio> emilio: It's consistent with that<br> <emilio> noamr: this is an invisible element with visible children, so it's consistent with that<br> <emilio> astearns: I'd suggest taking it back to the issue<br> <emilio> ... if there are use cases we can come back to this<br> <SebastianZ> +1 on Noam's points.<br> <emilio> ... but I don't see consensus<br> <emilio> vmpstr: use cases for making it visible?<br> <emilio> ntim: not necessarily, just a bit unintuitive<br> <emilio> ... don't care either way<br> <emilio> ... I guess for visibility we only check the visibility if checkVisibilityCSS option is<br> <emilio> ... specified<br> <emilio> astearns: suggested to close no change and add WPTs<br> <emilio> fantasai: if there are use cases for both behaviors can we make that flip?<br> <emilio> astearns: we didn't hear use cases<br> <emilio> fantasai: so point is to go back to the issue to request use cases?<br> <emilio> astearns: I was suggesting close no change and reopening if use cases are presented<br> <emilio> ... if you'd like to keep it open fine with that<br> <emilio> ntim: don't feel strongly, I could see web devs wanting to check if contents are visible<br> <emilio> ... but if we don't respect that for visibility then...<br> <emilio> RESOLVE: Close no change, reopen if use cases are presented on the issue<br> <emilio> RESOLVED: Close no change, reopen if use cases are presented on the issue<br> <emilio> ntim: should we add a note to the spec?<br> <emilio> astearns: We should def. have a WPT<br> <emilio> ... having it in the draft is an editorial decision<br> <ntim> my zoom is freezing, but I can add one<br> <emilio> vmpstr: I can add one<br> <fantasai> scribenick: fantasai<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9478#issuecomment-1768934586 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 18 October 2023 16:38:19 UTC