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 On Wed, May 25, 2022 at 5:43 PM Alex Russell <[email protected]> wrote: > > 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 > > On Wednesday, May 25, 2022 at 1:40:50 AM UTC-7 Yoav Weiss wrote: >> >> LGTM2 >> >> On Friday, May 20, 2022 at 9:44:11 PM UTC+2 Dave Tapuska wrote: >>> >>> 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. >>> >>> On Fri, May 20, 2022 at 2:39 PM Joey Arhar <[email protected]> wrote: >>>> >>>> > 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. >>>> >>>> On Thu, May 19, 2022 at 5:17 PM Dave Tapuska <[email protected]> wrote: >>>>> >>>>> 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. >>>>> >>>>> On Thu, May 19, 2022 at 6:52 PM Mike Taylor <[email protected]> >>>>> wrote: >>>>>> >>>>>> 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. >>>>>> >>>>>> On 5/5/22 4:26 PM, Joey Arhar wrote: >>>>>> >>>>>> > Can you ask for signals? >>>>>> >>>>>> https://github.com/mozilla/standards-positions/issues/634 >>>>>> https://lists.webkit.org/pipermail/webkit-dev/2022-May/032218.html >>>>>> >>>>>> On Wed, May 4, 2022 at 3:02 AM Yoav Weiss <[email protected]> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Wednesday, May 4, 2022 at 1:08:11 AM UTC+2 Joey Arhar wrote: >>>>>>>> >>>>>>>> Contact emails >>>>>>>> >>>>>>>> [email protected] >>>>>>>> >>>>>>>> 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. >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 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. >>>>>> >>>>>> -- >>>>>> 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 [email protected]. >>>>>> 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 [email protected]. >>>>>> 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 [email protected]. > 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. -- 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 [email protected]. 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.
