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 `add Element.isVisible[toDocument]`, and agreed to the following:

* `RESOLVED: Work on solving these use cases for an isVisible API and revisit in a future call`

<details><summary>The full IRC log of that discussion</summary>
&lt;fantasai> Topic: add Element.isVisible[toDocument]<br>
&lt;fantasai> github: https://github.com/w3c/csswg-drafts/issues/6850<br>
&lt;fantasai> chrishtr: ...<br>
&lt;fantasai> chrishtr: Need to do this to determine that things properly displayed<br>
&lt;Rossen_> q?<br>
&lt;Rossen_> ack florian_irc<br>
&lt;fantasai> chrishtr: currently use approximations that are increasingly incorrect as we add more advanced rendering features<br>
&lt;fantasai> chrishtr: When content is skipped using content-visiblity, protects code so that don't accidentally force-???<br>
&lt;fantasai> chrishtr: We've seen this problem when adopting content-visibility<br>
&lt;fantasai> chrishtr: Proposed definition is that box has to be "rendered" per HTML, i.e. has a box<br>
&lt;fantasai> chrishtr: 'visibility' is 'visible'<br>
&lt;fantasai> chrishtr: not in the skipped subtree of content-visibility<br>
&lt;fantasai> smfr: opacity:0 is visible, right?<br>
&lt;fantasai> chrishtr: yes, and clipped out counts as visible<br>
&lt;fantasai> smfr: so not really visible to the user, but some more subtle definition<br>
&lt;fantasai> chrishtr: Also scrolled off-screen considered visible<br>
&lt;lea> Seems like there's a lot of disagreement about the exact definition, what if this accepted a dictionary so that authors can define the type of "visibility" they need?<br>
&lt;fantasai> chrishtr: so seems like need name to be slightly different, e.g. isVisibletoDocument<br>
&lt;lea> Also, not sure how `isVisibleToDocument()` adds clarity over `isVisible()`, it mainly seems more verbose<br>
&lt;fantasai> Rossen_: I wanted clarification on whether or not isVisible state here means that the box of the element is rendered inside the viewport or not<br>
&lt;fantasai> Rossen_: Sounds like the answer is not necessarily?<br>
&lt;fantasai> Rossen_: Seems like the definition is box of the element could potentially be viewable<br>
&lt;fantasai> Rossen_: So, like, *can* be visible<br>
&lt;Rossen_> q?<br>
&lt;fantasai> lea: It seems there's a lot of uncertainty about the exact definition of this function<br>
&lt;fantasai> lea: couldn't we have options so that authors can decide what type of visiblity they care about?<br>
&lt;fantasai> lea: because clearly a single definition is not serving all use cases<br>
&lt;Rossen_> ack lea<br>
&lt;fantasai> lea: Also, isVisibleToDocument() doesn't seem to really add clarity, just adds verbosity<br>
&lt;fantasai> &lt;fantasai> +1<br>
&lt;fantasai> chrishtr: Not sure I understand use cses?<br>
&lt;fantasai> lea: Some use cases need to know whether visible in viewport, some just need to know if there's a box, and some need to know if contents are rendered<br>
&lt;fantasai> lea: so different use cases<br>
&lt;fantasai> chrishtr: We did consult with reps from Pupeteer and Clearwrite<br>
&lt;dholbert> q+<br>
&lt;fantasai> chrishtr: and they thought the definition was good for their use case<br>
&lt;fantasai> chrishtr: and meets the needs of the content-visibility partners we have<br>
&lt;florian_irc> q+<br>
&lt;fantasai> lea: As a web dev, testing whether a box is visible is something web developers have needed and use frequently<br>
&lt;florian_irc> q-<br>
&lt;fantasai> lea: adding isVisible that is a specific type of rendering for a specific use case<br>
&lt;smfr> +1 to lea’s suggestion<br>
&lt;fantasai> lea: if we're adding this new function, can't we add an ability that a majority of the authors need?<br>
&lt;fantasai> +1 to lea<br>
&lt;Rossen_> ack dholbert<br>
&lt;fantasai> dholbert: I'm curious whether it makes sense to include visiblity: hidden in the definition<br>
&lt;fantasai> dholbert: seems different category of visiblity than content-visiblity and display:none<br>
&lt;fantasai> dholbert: visibility:hidden, you still have to compute layout with it<br>
&lt;fantasai> dholbert: and authors are fully in control of it<br>
&lt;lea> Potentially useful, as this has historically been used *a lot* by authors: https://api.jquery.com/visible-selector/#visible1<br>
&lt;fantasai> chrishtr: Maybe it makes sense to be more specific about what the function does, and maybe introduce multiple function<br>
&lt;smfr> q+<br>
&lt;fantasai> chrishtr:  e.g. has a box and not ??<br>
&lt;fantasai> chrishtr: visiblity can be checked directly with existing methods<br>
&lt;lea> (jQuery implements as a selector, but it was used in the same way, to test visibility of a given element, for a certain definition of visibility)<br>
&lt;fantasai> dholbert: opacity:0, as smfr mentioned; and then content covered up by other content<br>
&lt;fantasai> chrishtr: so the only one is has a box and is not skipped<br>
&lt;fantasai> chrishtr: I think that would meet the needs<br>
&lt;fantasai> dholbert: only issue is that isVisible is a problematic name<br>
&lt;lea> also, would be nice if it addressed use cases like https://stackoverflow.com/questions/123999/how-can-i-tell-if-a-dom-element-is-visible-in-the-current-viewport<br>
&lt;Rossen_> a11y tools have been requesting such behavior for a very long time... yet I don't see that as a strong use case<br>
&lt;florian_irc> fantasai: I suggest "isDisplayed", cause that's got more to do with what we are doing<br>
&lt;florian_irc> fantasai: here, visibility variants isn't quite right<br>
&lt;Rossen_> q<br>
&lt;Rossen_> ack fantasai<br>
&lt;fantasai> fantasai: displayed links to the idea of 'display' and the box<br>
&lt;fantasai> s/box/box generation/<br>
&lt;fantasai> smfr: I like lea's idea of a more fine-grained approach<br>
&lt;fantasai> smfr: could imagine 2 versions<br>
&lt;fantasai> smfr: a function isVisible() takes a dictionary, which properties interested in<br>
&lt;fantasai> smfr: another is returns a dictionary, which says which types of visibility involved in<br>
&lt;fantasai> smfr: first one is more performant, don't have to calculate types that aren't needed<br>
&lt;fantasai> smfr: ...<br>
&lt;dbaron> (leaving the meeting now)<br>
&lt;fantasai> s/.../if more fine-grained API, that removes ambiguity or confusion around things that affect visibility/<br>
&lt;Rossen_> ack smfr<br>
&lt;Rossen_> ack lea<br>
&lt;fantasai> lea: Pasted a linkto jQuery API for similar functionality<br>
&lt;fantasai> lea: They've done a lot of work to address use cases<br>
&lt;fantasai> lea: would be good to take prior art into account<br>
&lt;fantasai> lea: seems they define as whether any layout boxes<br>
&lt;fantasai> lea: but seems definition changed at one point<br>
&lt;fantasai> lea: also linked to stack overflow, other places, ppl want to know whether an element is visible in the viewport<br>
&lt;fantasai> lea: would be useful if it could do that as well<br>
&lt;fantasai> lea: right now the way to test this is to create an intersection observer<br>
&lt;fantasai> lea: but it's awkward to write code like that, so would be nice if there was a function that would just tell you<br>
&lt;fantasai> lea: unsure if isDisplayed is more clear, would go with isVisible because shorter<br>
&lt;vmpstr> q+<br>
&lt;Rossen_> q+<br>
&lt;fantasai> fantasai: just to clarify, I think if we're doing something general then isVisible is fine, but if limiting to whether the box is generated isDisplayed makes sense to me<br>
&lt;fantasai> vmpstr: If going with dictionary approach, would dictionary be things like test viewport visibility, test display none, test ???<br>
&lt;Rossen_> ack vmpstr<br>
&lt;fantasai> vmpstr: how would that work?<br>
&lt;fantasai> lea: I think we should center around use cases rather than specific properties, so that it is more future proof<br>
&lt;tantek> +1 leaverou, decide on the funtionality first, and then the name can follow<br>
&lt;fantasai> lea: I propose we resolve to work on it, and go back to the drawing board and revisit later after redesigning<br>
&lt;bradk> 👍<br>
&lt;fantasai> chrishtr: sgtm<br>
&lt;tantek> +1 leaverou on all that. center around use-cases, revisit after redesigning<br>
&lt;fantasai> Rossen_: Seems like we went down this path of content-visibility and trying to chunk how much content is processed and address perf gains, which is a good effort<br>
&lt;fantasai> Rossen_: now we're trying to contain the damage<br>
&lt;fantasai> Rossen_: ... things that were otherwise easily discoverable<br>
&lt;fantasai> Rossen_: This type of functionality has been requested by accessibility tools for a long long time<br>
&lt;fantasai> Rossen_: to recognize whether something is visible, can it be visible, where is it visible<br>
&lt;fantasai> Rossen_: They have frameworks working around these problems<br>
&lt;fantasai> Rossen_: trying to reverse-engineer engine's decisions and results<br>
&lt;fantasai> Rossen_: so I don't see a11y considered anywhere in this issue, and would recommend we take these use cases as well<br>
&lt;fantasai> Rossen_: in addition to ones described by Lea and Simon<br>
&lt;Rossen_> q?<br>
&lt;fantasai> Rossen_: Any other feedback to this issue?<br>
&lt;fantasai> chrishtr: resolving as Lea suggested that use cases make sense and go back to issue makes sense<br>
&lt;fantasai> chrishtr: Just want to make sure that WG has consensus that these use cases are worth solving<br>
&lt;lea> +1 on the use cases being worth solving<br>
&lt;lea> (that was the first part of the resolution I proposed :)<br>
&lt;fantasai> Proposed Resolution: Work on solving these use cases for an isVisible API<br>
&lt;fantasai> RESOLVED: Work on solving these use cases for an isVisible API and revisit in a future call<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-1011300312 using your GitHub account


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

Received on Wednesday, 12 January 2022 17:47:30 UTC