Re: making page visibility a property of document instead of top level browsing context

There's no normative definition of what "visible" means here for a
document.  I think you have to be precise here in order to make this useful
for web developers.  Notes aren't normative.

Nothing on the web platform today exposes the notion of what part of a
document is 'visible', so I think you have quite a bit of writing to do.

- James


On Thu, Oct 10, 2013 at 4:26 PM, Arvind Jain <arvind@google.com> wrote:

> I've put a draft here:
>
> https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/PageVisibility2/Overview.html
>
> The main change from previous version of PageVisibility is making
> visibility a property of the document (as opposed to top level browsing
> context) as we proposed and agreed upon no this thread.
>
> Please let me know if you have any feedback. One question I have is
> whether we define more values for "visibilityState" to cover different
> cases like the following:
> 1) Browser window minimized.
> 2) Background tab.
> 3) IFrame outside of viewport.
> 4) One of document's ancestor is set to display:none
>
> Arvind
>
>
> On Tue, Aug 27, 2013 at 3:25 PM, Jatinder Mann <jmann@microsoft.com>wrote:
>
>> In the current Page Visibility spec, querying document.hidden from an
>> iframe returns the correct value, true, when the browser is minimized or
>> the tab is in the background. The property incorrectly returns false when
>> the top level document is visible, but the iframe is below the fold. I
>> don't see any compatibility issues of improving the fidelity of information
>> provided by this property in the iframe context in a Page Visibility L2
>> spec.
>>
>> -----Original Message-----
>> From: Jonas Sicking [mailto:jonas@sicking.cc]
>> Sent: Saturday, August 24, 2013 6:13 PM
>> To: Ojan Vafai
>> Cc: Arvind Jain; public-web-perf
>> Subject: Re: making page visibility a property of document instead of top
>> level browsing context
>>
>> Agreed. It seems quite possible that this won't break any existing
>> content.
>>
>> / Jonas
>>
>> On Sat, Aug 24, 2013 at 5:55 PM, Ojan Vafai <ojan@chromium.org> wrote:
>> > Ideally we wouldn't add a new property. So, we should try shipping
>> > this in the backwards-incompatible way (i.e. changing the existing
>> > property) and see if we can get away with it.
>> >
>> >
>> > On Sat, Aug 24, 2013 at 5:30 PM, Arvind Jain <arvind@google.com> wrote:
>> >>
>> >> Is it ok to just update the spec in a non compatible way i.e. in the
>> >> new version of the spec, we say visibility is at document level
>> >> (which would be not backwards compatible). Or do we need to add a new
>> property?
>> >>
>> >> Arvind
>> >>
>> >>
>> >> On Sat, Aug 24, 2013 at 5:22 PM, Jonas Sicking <jonas@sicking.cc>
>> wrote:
>> >>>
>> >>> We at mozilla is certainly in support of this. In fact, bz has
>> >>> strongly argued that this should be the case for a very long time.
>> >>>
>> >>> / Jonas
>> >>>
>> >>> On Aug 24, 2013 2:11 PM, "Arvind Jain" <arvind@google.com> wrote:
>> >>>>
>> >>>>
>> >>>> Hi,
>> >>>> I've seen a few requests where developers would like to query for
>> >>>> visibility of their IFRAME (when the iframe is in third party
>> context).
>> >>>>
>> >>>> Today, in Page Visibility, we set document.visibilityState to
>> "hidden"
>> >>>> or "visible", but it is really the visibility of the top level
>> >>>> browsing context that includes the given document. This information
>> >>>> is made available to third party IFRAMEs.
>> >>>>
>> >>>> What do folks think of making document.visibilityState the property
>> >>>> of the document itself instead of the top level browsing context?
>> >>>> That way you can detect conditions like when the IFRAME is below
>> >>>> the fold and therefore not visible while the top level browsing
>> context itself is visible.
>> >>>>
>> >>>> Thanks,
>> >>>> Arvind
>> >>
>> >>
>> >
>>
>>
>