Intent to Ship: Element.isVisible method

[Joey Arhar]

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]

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]

> Can you ask for signals?

https://github.com/mozilla/standards-positions/issues/634

https://lists.webkit.org/pipermail/webkit-dev/2022-May/032218.html

[Mike Taylor]

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]

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.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b0204d81-ded9-9c94-7a7e-6910b91d88dc%40chromium.org.

[Joey Arhar]

> 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]

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]

LGTM2

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@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+unsubscribe@chromium.org.

[Alex Russell]

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]

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.

>>>>>> To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b0204d81-ded9-9c94-7a7e-6910b91d88dc%40chromium.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]

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.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYcBU%2BUWXGFweVB5G_-MChDDShhbs%3D%3DqgLfKNVEbVY5VeQ%40mail.gmail.com.

[Philip Jägenstedt]

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]

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]

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]

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.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYd11QU0yxfbTnyOX_RcX8U%3D03Y35vrebCVd12hPPOU%3Dsw%40mail.gmail.com.

[Alex Russell]

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:

https://www.youtube.com/watch?v=1Z83L6xa1tw

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]

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]

The CSSWG has resolved to rename the method to checkVisibility: https://github.com/w3c/csswg-drafts/issues/7317

[Yoav Weiss]

My LGTM still stands. Thanks for bikeshedding this!! :)

[Philip Jägenstedt]

LGTM3 to checkVisibility()!