Re: [csswg-drafts] [cssom-view] Proposal: add Element.isVisible[toDocument] to detect if element is visible in the document. (#6850)

The CSS Working Group just discussed `[cssom-view] Proposal: add Element.isVisible[toDocument] to detect if element is visible in the document.`, and agreed to the following:

* `RESOLVED: Add isVisible to element as defined in the issue. Work out the corner case in a separate issue`

<details><summary>The full IRC log of that discussion</summary>
&lt;dael> Topic: [cssom-view] Proposal: add Element.isVisible[toDocument] to detect if element is visible in the document.<br>
&lt;dael> github: https://github.com/w3c/csswg-drafts/issues/6850<br>
&lt;dael> chrishtr: brought this up a couple weeks ago. 2 use cases to add. 1) know if an element is visible via testin framework. Some links in the issue. 2) if content under content-visibility:hidden is skipped. Checking without forcing render<br>
&lt;dael> chrishtr: Previous talked a bit about name and about mapping this back to use cases and prior art. Discussion about how to make this extensible to different definitions of visible<br>
&lt;dael> chrishtr: I went back and looked at jquery visbile function and looked at a11y tech. a11y tech looks at internal UA APIs so this seems not applicable.<br>
&lt;dael> chrishtr: Prop: add isVisible function with 2 default behaviors. Having a layer box and not being in content-visibility:hidden subtree. Dictionary argument to allow you to opt into other types that are both convenient and not convenient to query now in order to allow devs to query<br>
&lt;dael> Rossen_: Looking at some of the discussions around a11y and how such a feature could be used. I think you're right most AT go through something like UI automation and not this. But what they go after is they look at APIs available to authors and then negotiate with platforms about if it makes sense for them to have<br>
&lt;dael> Rossen_: My motivation there was to see if having a property like isVisible won't trigger additional interpretations. Having had discussions with one of the ATs it doesn't look like they'd be too interested. I can't speak to more then them<br>
&lt;dael> Rossen_: Based on that I'm fine. if more requests come our way we can consider if we should discuss this as part of css-aam to have further mappings<br>
&lt;dael> chrishtr: Okay. I ahd a similar discussion with Chrome a11y team and they reached same conclusion<br>
&lt;dael> Rossen_: Okay. Back to functionality merit, any other opinions or reason we want to change anything?<br>
&lt;dael> chrishtr: Prop: Add isVisible function to the element object that has behavior: has a box and is not skipped by content-visbility:hidden ancestors. Dictionary of options for additional types of visibility; tracksVisibilityName which is a bool attribute<br>
&lt;fantasai> ok<br>
&lt;heycam> "track" sounds like some checking that is ongoing<br>
&lt;dael> chrishtr: Return value is also a dictionary indicating if it's a box, if it's skipped, and would tell you other information based on what's defined<br>
&lt;flackr> q+<br>
&lt;dael> chrishtr: Most important is isVisible and we can work on dictionary in ED<br>
&lt;dael> Rossen_: Objections to accepting this?<br>
&lt;Rossen_> ack heycam<br>
&lt;dael> heycam: I think the word tracks sounds like doing something ongiong. Probably a better word to be found<br>
&lt;dael> fantasai: Check?<br>
&lt;dael> chrishtr: Check is a good work<br>
&lt;dael> s/work/word<br>
&lt;dael> chrishtr: Change proposal to check. That makes sense<br>
&lt;Rossen_> ack flackr<br>
&lt;dael> flackr: Skimming prop. If you requested a bunch of checks and element was skipped do we clean the style to see if other checks are true or false?<br>
&lt;dael> chrishtr: Hm. Hadn't considered. If it doesn't have box or box is skipped...I guess if you spec those perhaps it should force.<br>
&lt;dael> flackr: Not sure right behavior<br>
&lt;dael> chrishtr: Either could ignore you or return false. Weird to say you're visible but not<br>
&lt;dael> vmpstr: Will thier return a bool of all params?<br>
&lt;dael> chrishtr: Returns a dictionary.<br>
&lt;dael> chrishtr: Another option would be return the first 2 and then it's null<br>
&lt;dael> Rossen_: Would it be better to, instead of think on our feet, let's resolve on the bigger capability and then you can work out this case in a separate issue. Unless you're looking for a concrete resolution<br>
&lt;vmpstr> +1<br>
&lt;flackr> +1<br>
&lt;dael> chrishtr: Makes sense to resolve on the big thing<br>
&lt;dael> Rossen: Prop Add isVisible to element as defined in the issue. Work out the corner case in a separate issue<br>
&lt;dael> RESOLVED: Add isVisible to element as defined in the issue. Work out the corner case in a separate issue<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6850#issuecomment-1057555124 using your GitHub account


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

Received on Thursday, 3 March 2022 01:00:06 UTC