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