Re: [blink-dev] Re: Intent to Ship: Element.isVisible method

[Philip Jägenstedt]

LGTM3 to checkVisibility()!

On Thu, 30 Jun 2022 at 12:21 Yoav Weiss  wrote:

> My LGTM still stands. Thanks for bikeshedding this!! :)
>
> On Wed, Jun 29, 2022 at 8:48 PM Joey Arhar  wrote:
>
>> The CSSWG has resolved to rename the method to checkVisibility:
>> https://github.com/w3c/csswg-drafts/issues/7317
>>
>> On Wed, Jun 8, 2022 at 8:36 AM Philip Jägenstedt 
>> wrote:
>>
>>> 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.
>>>
>>> On Wed, Jun 1, 2022 at 6:29 PM Alex Russell 
>>> wrote:
>>>
 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?


 On Tuesday, May 31, 2022 at 1:15:34 PM UTC-7 Chris Harrelson wrote:

> On Tue, May 31, 2022 at 2:42 AM Philip Jägenstedt 
> 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).
>
>
>>
>> Best regards,
>> Philip
>>
>> On Fri, May 27, 2022 at 6:06 PM Chris Harrelson <
>> chris...@chromium.org> wrote:
>>
>>>
>>>
>>> On Fri, May 27, 2022 at 9:03 AM Philip Jägenstedt <
>>> foo...@chromium.org> wrote:
>>>
 On Wed, May 25, 2022 at 10:49 PM Chris Harrelson <
 chris...@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?

>>>
>>> Yes. This issue 
>>> tracks it, just needs spec edits.

Re: [blink-dev] Re: Intent to Ship: Element.isVisible method

[Yoav Weiss]

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

On Wed, Jun 29, 2022 at 8:48 PM Joey Arhar  wrote:

> The CSSWG has resolved to rename the method to checkVisibility:
> https://github.com/w3c/csswg-drafts/issues/7317
>
> On Wed, Jun 8, 2022 at 8:36 AM Philip Jägenstedt 
> wrote:
>
>> 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.
>>
>> On Wed, Jun 1, 2022 at 6:29 PM Alex Russell 
>> wrote:
>>
>>> 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?
>>>
>>>
>>> On Tuesday, May 31, 2022 at 1:15:34 PM UTC-7 Chris Harrelson wrote:
>>>
 On Tue, May 31, 2022 at 2:42 AM Philip Jägenstedt 
 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).


>
> Best regards,
> Philip
>
> On Fri, May 27, 2022 at 6:06 PM Chris Harrelson 
> wrote:
>
>>
>>
>> On Fri, May 27, 2022 at 9:03 AM Philip Jägenstedt <
>> foo...@chromium.org> wrote:
>>
>>> On Wed, May 25, 2022 at 10:49 PM Chris Harrelson <
>>> chris...@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?
>>>
>>
>> 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.
>>
>>
>>
> --
>

Re: [blink-dev] Re: Intent to Ship: Element.isVisible method

[Joey Arhar]

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

On Wed, Jun 8, 2022 at 8:36 AM Philip Jägenstedt 
wrote:

> 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.
>
> On Wed, Jun 1, 2022 at 6:29 PM Alex Russell 
> wrote:
>
>> 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?
>>
>>
>> On Tuesday, May 31, 2022 at 1:15:34 PM UTC-7 Chris Harrelson wrote:
>>
>>> On Tue, May 31, 2022 at 2:42 AM Philip Jägenstedt 
>>> 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).
>>>
>>>

 Best regards,
 Philip

 On Fri, May 27, 2022 at 6:06 PM Chris Harrelson 
 wrote:

>
>
> On Fri, May 27, 2022 at 9:03 AM Philip Jägenstedt 
> wrote:
>
>> On Wed, May 25, 2022 at 10:49 PM Chris Harrelson 
>> 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?
>>
>
> 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.
>
>
>
 --

>>> 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+unsubscr...@chromium.org.

>>> To view this discussion on the web visit
 

Re: [blink-dev] Re: Intent to Ship: Element.isVisible method

[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.

On Wed, Jun 1, 2022 at 6:29 PM Alex Russell 
wrote:

> 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?
>
>
> On Tuesday, May 31, 2022 at 1:15:34 PM UTC-7 Chris Harrelson wrote:
>
>> On Tue, May 31, 2022 at 2:42 AM Philip Jägenstedt 
>> 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).
>>
>>
>>>
>>> Best regards,
>>> Philip
>>>
>>> On Fri, May 27, 2022 at 6:06 PM Chris Harrelson 
>>> wrote:
>>>


 On Fri, May 27, 2022 at 9:03 AM Philip Jägenstedt 
 wrote:

> On Wed, May 25, 2022 at 10:49 PM Chris Harrelson 
> 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?
>

 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.



>>> --
>>>
>> 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+unsubscr...@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
>>> 
>>> .
>>>
>>

-- 
You 

Re: [blink-dev] Re: Intent to Ship: Element.isVisible method

[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?


On Tuesday, May 31, 2022 at 1:15:34 PM UTC-7 Chris Harrelson wrote:

> On Tue, May 31, 2022 at 2:42 AM Philip Jägenstedt  
> 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).
>  
>
>>
>> Best regards,
>> Philip
>>
>> On Fri, May 27, 2022 at 6:06 PM Chris Harrelson  
>> wrote:
>>
>>>
>>>
>>> On Fri, May 27, 2022 at 9:03 AM Philip Jägenstedt  
>>> wrote:
>>>
 On Wed, May 25, 2022 at 10:49 PM Chris Harrelson  
 wrote:

>
>
> On Wed, May 25, 2022 at 1:44 PM Philip Jägenstedt  
> 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?

>>>
>>> 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.
>>>
>>>  
>>>
>> -- 
>>
> 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+unsubscr...@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
>>  
>> 
>> .
>>
>

-- 
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+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/bd6eace3-1ebc-4601-b5d0-15065c2e0ed3n%40chromium.org.

Re: [blink-dev] Re: Intent to Ship: Element.isVisible method

[Chris Harrelson]

On Tue, May 31, 2022 at 2:42 AM Philip Jägenstedt 
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).


>
> Best regards,
> Philip
>
> On Fri, May 27, 2022 at 6:06 PM Chris Harrelson 
> wrote:
>
>>
>>
>> On Fri, May 27, 2022 at 9:03 AM Philip Jägenstedt 
>> wrote:
>>
>>> On Wed, May 25, 2022 at 10:49 PM Chris Harrelson 
>>> wrote:
>>>


 On Wed, May 25, 2022 at 1:44 PM Philip Jägenstedt 
 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?
>>>
>>
>> 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.
>>
>>
>>
> --
> 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+unsubscr...@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
> 
> .
>

-- 
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+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-d7W8Wpug%3Dci7-p6Kf%3D1DgO_MCKmigtX2Wr1bObOj-Gg%40mail.gmail.com.

Re: [blink-dev] Re: Intent to Ship: Element.isVisible method

[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

On Fri, May 27, 2022 at 6:06 PM Chris Harrelson 
wrote:

>
>
> On Fri, May 27, 2022 at 9:03 AM Philip Jägenstedt 
> wrote:
>
>> On Wed, May 25, 2022 at 10:49 PM Chris Harrelson 
>> wrote:
>>
>>>
>>>
>>> On Wed, May 25, 2022 at 1:44 PM Philip Jägenstedt 
>>> 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?
>>
>
> 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.
>
>
>

-- 
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+unsubscr...@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.

Re: [blink-dev] Re: Intent to Ship: Element.isVisible method

[Chris Harrelson]

On Fri, May 27, 2022 at 9:03 AM Philip Jägenstedt 
wrote:

> On Wed, May 25, 2022 at 10:49 PM Chris Harrelson 
> wrote:
>
>>
>>
>> On Wed, May 25, 2022 at 1:44 PM Philip Jägenstedt 
>> 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?
>

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.

-- 
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+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw9vuTCCKoceyMi6C3Qg-qs8KJDu8L4a-JydkLh2QwDPPA%40mail.gmail.com.

Re: [blink-dev] Re: Intent to Ship: Element.isVisible method

['Chris Harrelson' via blink-dev]

On Wed, May 25, 2022 at 1:44 PM Philip Jägenstedt 
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.

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 
> 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 
> 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 
> wrote:
> >
> > So how does this method work for iframes that have their visibility
> hidden? Is it intended to work for that?
> >
> > 
> >  
> > 
> >
> > 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 
> 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 
> wrote:
> >>>
> >>>
> >>>
> >>> 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 

Re: [blink-dev] Re: Intent to Ship: Element.isVisible method

[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

On Wed, May 25, 2022 at 5:43 PM Alex Russell  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  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  wrote:
>
> So how does this method work for iframes that have their visibility 
> hidden? Is it intended to work for that?
>
> 
>  
> 
>
> 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  
> 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  wrote:
>>>
>>>
>>>
>>> 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 

Re: [blink-dev] Re: Intent to Ship: Element.isVisible method

[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

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  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  
>>> wrote:
>>>
 So how does this method work for iframes that have their visibility 
 hidden? Is it intended to work for that?

 
  
 

 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  
 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  
> wrote:
>
>>
>>
>> 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.
>>  
>>
>>>
>>> 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 

Re: [blink-dev] Re: Intent to Ship: Element.isVisible method

[Yoav Weiss]

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  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  
>> wrote:
>>
>>> So how does this method work for iframes that have their visibility 
>>> hidden? Is it intended to work for that?
>>>
>>> 
>>>  
>>> 
>>>
>>> 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  
>>> 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  
 wrote:

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

Re: [blink-dev] Re: Intent to Ship: Element.isVisible method

[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.

On Fri, May 20, 2022 at 2:39 PM Joey Arhar  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 
> wrote:
>
>> So how does this method work for iframes that have their visibility
>> hidden? Is it intended to work for that?
>>
>> 
>>  
>> 
>>
>> 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 
>> 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 
>>> wrote:
>>>


 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.


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

Re: [blink-dev] Re: Intent to Ship: Element.isVisible method

[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.

On Thu, May 19, 2022 at 5:17 PM Dave Tapuska  wrote:

> So how does this method work for iframes that have their visibility
> hidden? Is it intended to work for that?
>
> 
>  
> 
>
> 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 
> 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  wrote:
>>
>>>
>>>
>>> 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.
>>>
>>>

 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 

Re: [blink-dev] Re: Intent to Ship: Element.isVisible method

[Dave Tapuska]

So how does this method work for iframes that have their visibility hidden?
Is it intended to work for that?


 


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  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  wrote:
>
>>
>>
>> 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.
>>
>>
>>>
>>> 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 blink-dev+unsubscr...@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 

Re: [blink-dev] Re: Intent to Ship: Element.isVisible method

[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.

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  wrote:



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.


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 blink-dev+unsubscr...@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+unsubscr...@chromium.org.
To view this discussion on the web visit