Re: [Page Visibility] Spec Updates

On Tue, May 10, 2011 at 5:32 PM, Jatinder Mann <jmann@microsoft.com> wrote:
>
>
>
> We can decide on where to expose these properties based on this research. I
> actually do prefer exposing these properties on Document.
>
>
>

I won't be able to attend tomorrow's call (I'll be presenting at Google I/O
at precisely that time), but for the record I do support document, mainly
because of the global variables problem.


> > In later discussion in the public-webapps thread, we decided to change
> the meaning of "visible" to " the page content may be at least partially
> visible", because the spec does not require that user agents report hidden
> when a non-minimized window happens to be fully obscured by another window.
>
>
>
> I agree that visible shouldn’t return false (or visibilityState return
> PAGE_HIDDEN) for the case that a non-minimized window is fully obscured by
> another window, as this may not be technically easy to determine. We can
> either explicitly specify that the fully obscured case is not to be
> considered hidden, or we can go with a more generic definition of visible as
> “may be at least partially visible”. I would prefer the former as it’s clear
> and well defined. We can discuss this on the call tomorrow.
>

The very first proposal for this API explicitly mentioned tabs, and people
on the original thread (rightly) pointed out that the API should be as
desktop-UI agnostic as possible.  The more generic wording comes directly
out of that, although it might have gone a bit too far to the generic.
 Leaving it more general has the (slight) benefit that in the future if some
UA decides to implement fully-obscured-counts-as-hidden they can.  However,
I don't feel strongly about this point.


>
> > The draft proposes that visibilityState returns numerical constants, but
> in the original proposal visibilityState returned strings.
>
>
>
> We can have visibilityState return strings, however, the spec should
> specify pre-defined DOMString constants so that web developers can inspect
> for capability, rather than read documentation to determine capability.
> DOMStrings constants have not yet been used in the HTML5 spec, however,
> per the webIDL spec, http://dev.w3.org/2006/webapi/WebIDL/#idl-constants,
> DOMStrings constants are legitimate. For example, our constants can change
> as so:
>
>
>
>   const unsigned short PAGE_HIDDEN = “hidden”;
>
>   const unsigned short PAGE_VISIBLE = “visible”;
>
>   const unsigned short PAGE_PREVIEW = “preview”;
>
>   const unsigned short PAGE_PRERENDER = “prerender”;
>
>
>
> A web developer can check the current state by doing either:
>
>
>
> if (window.visibilityState == “hidden”)
>
> OR
>
> if (window.visibilityState == window.PAGE_HIDDEN)
>
>
>
> A user agent can still expose “webkit-partially-hidden” in advance of
> “partially-hidden”/window.PAGE_PARTIALLY_HIDDEN being standardized as so:
>
>
>
> if (window.visibilityState == “webkit-page-partially-hidden”)
>
> * *
>
>
>

This seems like a good way to go to me.


>  > In the original thread the discussion settled on "the page may be at
> least partially visible, but not in an interactive form" for the semantics
> of "preview", where the relevant part is that it's non-interactive.  I like
> the "non-interactive" component being part of the semantics, because I think
> it captures nicely what a preview means.
>
>
>
> Defining previews as “non-interactive” may not capture all preview cases.
> For example, if you pin Jango.com with IE9 to your Windows 7 taskbar, you
> can interact with the preview – you can either pause or play the music.
> Other user agents or Operating Systems may want to take support an
> interactive preview. Likewise, I don’t recommend defining previews as
> “static” versus “dynamic”, as an Operating System or user agent may choose
> to do either.  I recommend we either define all cases or we keep the preview
> definition as generic as possible. I prefer the latter.
>

I think you convinced me that the latter is better. :-)

>
>
> > In the original draft, conforming user agents MUST return "hidden" and
> "visible" for visibilityState, and MAY return the other values ("prerender",
> "preview", "cache", future values) if they choose to.  The reason was that:
>
>
>
> This is an excellent point. Except for “hidden” and “visible” states, which
> must be defined, the other states should be optional as they may not always
> make sense for a user agent. E.g., a mobile user agent may or may not have
> the concept of preview. I will update the spec to make the “prerender” and
> “preview” states optional.
>
>
>
>