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.
This feature is not particularly contentious or complicated, but is mostly useful in the presence of content-visibility.
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.
This feature is easy to feature detect and polyfill.
I have no security risks/considerations for this feature.
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.
This feature does not need any new debugging features.
103
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/7232Contact emails
jar...@chromium.orgExplainer
https://github.com/WICG/display-locking/blob/main/explainers/isvisible.mdSpecification
https://drafts.csswg.org/cssom-view/#dom-element-isvisibleSummary
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>DOMTAG review
https://github.com/w3ctag/design-reviews/issues/734TAG review status
PendingRisks
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
--
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.
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.
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.
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.
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.
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:hiddenHowever, 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.
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?
--
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.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.