Intent to Ship: Element.isVisible method

286 views
Skip to first unread message

Joey Arhar

unread,
May 3, 2022, 7:08:11 PMMay 3
to blink-dev

Contact emails

jar...@chromium.org

Explainer

https://github.com/WICG/display-locking/blob/main/explainers/isvisible.md

Specification

https://drafts.csswg.org/cssom-view/#dom-element-isvisible

Summary

Element.isVisible() returns true if the element is visible, and false if it is not. It checks a variety of factors that would make an element invisible, including display:none, visibility, content-visibility, and opacity.



Blink component

Blink>DOM

TAG review

https://github.com/w3ctag/design-reviews/issues/734

TAG review status

Pending

Risks



Interoperability and Compatibility

This feature is not particularly contentious or complicated, but is mostly useful in the presence of content-visibility.



Gecko: No signal

WebKit: No signal

Web developers: No signals

Other signals:

Ergonomics

This feature could be used in tandem with content-visibility or details elements. Usage of this API will not make it hard for Chrome to maintain good performance.



Activation

This feature is easy to feature detect and polyfill.



Security

I have no security risks/considerations for this feature.



WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

This does not deprecate or change any existing APIs and does not have any risk for WebView.



Debuggability

This feature does not need any new debugging features.



Is this feature fully tested by web-platform-tests?

Yes

Flag name

--enable-blink-features=isVisible

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1309533

Estimated milestones

103



Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

https://github.com/w3c/csswg-drafts/issues/7232

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5163102852087808

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK6btwK01yGZ0LVb6M_8WdeC5OM0qfUv5T1TUO%3D1if1G%2BKogRw%40mail.gmail.com


This intent message was generated by Chrome Platform Status.

Yoav Weiss

unread,
May 4, 2022, 6:02:48 AMMay 4
to blink-dev, Joey Arhar
On Wednesday, May 4, 2022 at 1:08:11 AM UTC+2 Joey Arhar wrote:

Contact emails

jar...@chromium.org

Explainer

https://github.com/WICG/display-locking/blob/main/explainers/isvisible.md

Specification

https://drafts.csswg.org/cssom-view/#dom-element-isvisible

Summary

Element.isVisible() returns true if the element is visible, and false if it is not. It checks a variety of factors that would make an element invisible, including display:none, visibility, content-visibility, and opacity.



Blink component

Blink>DOM

TAG review

https://github.com/w3ctag/design-reviews/issues/734

TAG review status

Pending

Risks



Interoperability and Compatibility

This feature is not particularly contentious or complicated, but is mostly useful in the presence of content-visibility.



Gecko: No signal

WebKit: No signal

Can you ask for signals?
 

Web developers: No signals

Would be good to gather signals here as well.

Joey Arhar

unread,
May 5, 2022, 4:26:28 PMMay 5
to Yoav Weiss, blink-dev

Mike Taylor

unread,
May 19, 2022, 6:52:22 PMMay 19
to Joey Arhar, Yoav Weiss, blink-dev
Given the CSSWG resolution in https://github.com/w3c/csswg-drafts/issues/7274#issuecomment-1130214343, LGTM1 to ship assuming we're not shipping `checkInert` with the rest.

Thanks for addressing Mozilla's feedback.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK6btwKkoRBHUja0MePoXLRq0vN_WVeF%3Dr2se34ThXo5Tr%2BdtQ%40mail.gmail.com.


Dave Tapuska

unread,
May 19, 2022, 7:17:46 PMMay 19
to Mike Taylor, Joey Arhar, Yoav Weiss, blink-dev
So how does this method work for iframes that have their visibility hidden? Is it intended to work for that?

<iframe style="visibility:hidden">
 <div></div>
</iframe>

div's isVisible will always be true. Perhaps isVisible needs a caveat that it only works for the current document. Oh that is what was debated here.

dave.

Joey Arhar

unread,
May 20, 2022, 2:39:14 PMMay 20
to Dave Tapuska, Mike Taylor, Yoav Weiss, blink-dev
> Oh that is what was debated here

I think that the use of "document" there was about being in the viewport and being painted, not about iframes.

Currently, isVisible doesn't look at parent iframes. I don't think there's anything wrong with adding that functionality for LocalFrames, but doing so for RemoteFrames would probably have security/privacy considerations.

Dave Tapuska

unread,
May 20, 2022, 3:44:11 PMMay 20
to Joey Arhar, Mike Taylor, Yoav Weiss, blink-dev
Ya I only ran into this when investigating how visibility really works. Such as visibilityChanged events and document.visibilityState do not change for a hidden iframe. (which I guess is correct based on its definition, because those are about the tab being in the foreground or not). The only problem I have with this definition is that the CSS spec declares it as "rendered" and if someone is considering that as pixels on the display that isn't quite correct.

I did find enough stack overflow articles about people asking about interactions with the parent document. I don't think making it work for same origin iframes vs cross origin iframes is something that would give much benefit. 

dave.

Yoav Weiss

unread,
May 25, 2022, 4:40:50 AMMay 25
to blink-dev, Dave Tapuska, Mike Taylor, Yoav Weiss, blink-dev, Joey Arhar
LGTM2

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

Alex Russell

unread,
May 25, 2022, 11:43:01 AMMay 25
to blink-dev, Yoav Weiss, Dave Tapuska, Mike Taylor, blink-dev, Joey Arhar
The TAG has not substantively commented on this one, and I'd expect them to raise some concerns. For instance, this is a synchronous method, but we've explicitly built Intersection Observers as an async mechansim for cheaply computing *true* visibility, whereas this API only checks some current CSS properties (with options). This seems to be poorly integrated, and I'd have expected the TAG to at least suggest a different name.

Have you considered an OT? Or prodded the TAG?

Best Regards,

Alex

Philip Jägenstedt

unread,
May 25, 2022, 4:44:09 PMMay 25
to Alex Russell, blink-dev, Yoav Weiss, Dave Tapuska, Mike Taylor, Joey Arhar
It looks like the TAG was prodded, since the "2022-06-13-week"
milestone was just added to
https://github.com/w3ctag/design-reviews/issues/734.

However, I don't think it's reasonable for us to keep waiting for the
TAG until mid-June when this proposal already had plenty of input from
other vendors in https://github.com/w3c/csswg-drafts/issues/6850.

This API checks the synchronously available state to determine if the
element is going to be hidden in the next frame, but it doesn't
determine if it's really visible like Intersection Observer. That
seems like a useful thing to have. However, the bits involving inert
and aria-hidden do seem a bit out of place for something called
isVisible, to me.

Alex, can you simulate the TAG and give some suggestions for what
names they should suggest? isHidden() is the first that comes to mind
for me.

Best regards,
Philip
>>>>>> To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
>>>>>> To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK6btwKkoRBHUja0MePoXLRq0vN_WVeF%3Dr2se34ThXo5Tr%2BdtQ%40mail.gmail.com.
>>>>>>
>>>>>>
>>>>>> --
>>>>>> You received this message because you are subscribed to the Google Groups "blink-dev" group.
>>>>>> To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
> --
> You received this message because you are subscribed to the Google Groups "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
> To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/64d45aa5-e1f3-42ae-95c8-b60bba772bden%40chromium.org.

Chris Harrelson

unread,
May 25, 2022, 4:49:44 PMMay 25
to Philip Jägenstedt, Alex Russell, blink-dev, Yoav Weiss, Dave Tapuska, Mike Taylor, Joey Arhar
On Wed, May 25, 2022 at 1:44 PM Philip Jägenstedt <foo...@chromium.org> wrote:
It looks like the TAG was prodded, since the "2022-06-13-week"
milestone was just added to
https://github.com/w3ctag/design-reviews/issues/734.

However, I don't think it's reasonable for us to keep waiting for the
TAG until mid-June when this proposal already had plenty of input from
other vendors in https://github.com/w3c/csswg-drafts/issues/6850.

This API checks the synchronously available state to determine if the
element is going to be hidden in the next frame, but it doesn't
determine if it's really visible like Intersection Observer. That
seems like a useful thing to have.

The useful thing is:
* Reliably detect visibility according to some basic semantics that are common to test for (use cases listed in the issue)
* Provide a performant way to detect content-visibility:hidden
 
However, the bits involving inert
and aria-hidden do seem a bit out of place for something called
isVisible, to me.

These two are no longer part of the proposal.

Philip Jägenstedt

unread,
May 27, 2022, 12:03:15 PMMay 27
to Chris Harrelson, Alex Russell, blink-dev, Yoav Weiss, Dave Tapuska, Mike Taylor, Joey Arhar
On Wed, May 25, 2022 at 10:49 PM Chris Harrelson <chri...@google.com> wrote:


On Wed, May 25, 2022 at 1:44 PM Philip Jägenstedt <foo...@chromium.org> wrote:
It looks like the TAG was prodded, since the "2022-06-13-week"
milestone was just added to
https://github.com/w3ctag/design-reviews/issues/734.

However, I don't think it's reasonable for us to keep waiting for the
TAG until mid-June when this proposal already had plenty of input from
other vendors in https://github.com/w3c/csswg-drafts/issues/6850.

This API checks the synchronously available state to determine if the
element is going to be hidden in the next frame, but it doesn't
determine if it's really visible like Intersection Observer. That
seems like a useful thing to have.

The useful thing is:
* Reliably detect visibility according to some basic semantics that are common to test for (use cases listed in the issue)
* Provide a performant way to detect content-visibility:hidden
 
However, the bits involving inert
and aria-hidden do seem a bit out of place for something called
isVisible, to me.

These two are no longer part of the proposal.

Inert still is, see https://drafts.csswg.org/cssom-view/#dom-element-isvisible. Was there agreement to drop that, but it didn't happen yet?

Chris Harrelson

unread,
May 27, 2022, 12:06:21 PMMay 27
to Philip Jägenstedt, Alex Russell, blink-dev, Yoav Weiss, Dave Tapuska, Mike Taylor, Joey Arhar
Yes. This issue tracks it, just needs spec edits.

I've also opened an issue to discuss whether isHidden is a better name than isVisible and added to the CSSWG agenda.

 

Philip Jägenstedt

unread,
May 31, 2022, 5:42:34 AMMay 31
to Chris Harrelson, Alex Russell, blink-dev, Yoav Weiss, Dave Tapuska, Mike Taylor, Joey Arhar
Thanks Chris!

I think that we should ship this with whatever name the CSS WG can agree on. Do you know when this will be discussed, and do you think we should wait until after that meeting to approve this?

Best regards,
Philip

Chris Harrelson

unread,
May 31, 2022, 4:15:34 PMMay 31
to Philip Jägenstedt, Alex Russell, blink-dev, Yoav Weiss, Dave Tapuska, Mike Taylor, Joey Arhar
On Tue, May 31, 2022 at 2:42 AM Philip Jägenstedt <foo...@chromium.org> wrote:
Thanks Chris!

I think that we should ship this with whatever name the CSS WG can agree on. Do you know when this will be discussed, and do you think we should wait until after that meeting to approve this?

It's on the CSSWG agenda for tomorrow. Let's wait for that group's decision on the name, after which I personally would feel comfortable shipping (though I'm recused as an API owner on this thread, since I am involved in the feature).
 
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Alex Russell

unread,
Jun 1, 2022, 12:29:08 PMJun 1
to blink-dev, Chris Harrelson, Alex Russell, blink-dev, Yoav Weiss, Dave Tapuska, Mike Taylor, Joey Arhar, Philip Jägenstedt
I'm happy for a clearer name if that's the result of the CSS WG discussion, and we do timeout on the TAG from time to time, but maybe we can ask them to review quickly? I'll ping Rossen.

Regardless, given that we are still going to be the first to ship, we have to make sure the I's are dotted and the T's are crossed. Won't block this intent if others are fine to ship w/ whatever resolution to the naming debate happens, but it's an example of a recurring pattern out of the CSS WG (and a few other WGs) that Blink doesn't accept: our process isn't happy to launch without appropriate horizontal review when things are risky. Sometimes we can truncate reviews because we aren't out in front and there's low risk of first-mover disadvantage, but in cases like this where there are no signals from other vendors, the risks of being wrong are pronounced:


In these cases, it's always great to ask if we can go to OT and ship gaplessly if reviews come back green.

Thoughts?


To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

Philip Jägenstedt

unread,
Jun 8, 2022, 11:36:29 AMJun 8
to Alex Russell, blink-dev, Chris Harrelson, Yoav Weiss, Dave Tapuska, Mike Taylor, Joey Arhar
https://github.com/w3c/csswg-drafts/issues/7317 is still ongoing, so I think we should just wait until it's settled in the next CSSWG call.

In this case, there's been (continues to be) multi-vendor input in the CSSWG, and the IntersectionObserver naming has been raised. If members of the TAG want to influence the naming, I think they should weigh in on that issue. If they have a recommendation after the CSSWG has settled the issue, I wouldn't expect the CSSWG to change it again.

But at this point, let's wait for the CSSWG.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Joey Arhar

unread,
Jun 29, 2022, 2:48:46 PMJun 29
to Philip Jägenstedt, Alex Russell, blink-dev, Chris Harrelson, Yoav Weiss, Dave Tapuska, Mike Taylor
The CSSWG has resolved to rename the method to checkVisibility: https://github.com/w3c/csswg-drafts/issues/7317

Yoav Weiss

unread,
Jun 30, 2022, 6:21:42 AMJun 30
to Joey Arhar, Philip Jägenstedt, Alex Russell, blink-dev, Chris Harrelson, Dave Tapuska, Mike Taylor
My LGTM still stands. Thanks for bikeshedding this!! :)

Philip Jägenstedt

unread,
Jun 30, 2022, 11:45:17 AMJun 30
to Yoav Weiss, Alex Russell, Chris Harrelson, Dave Tapuska, Joey Arhar, Mike Taylor, blink-dev
LGTM3 to checkVisibility()!
Reply all
Reply to author
Forward
0 new messages