W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2011

Re: Proposal for a page visibility API

From: Alex Komoroske <komoroske@chromium.org>
Date: Fri, 21 Jan 2011 11:13:49 -0800
Message-ID: <AANLkTikzADZ-Zt22xrp8nR9V3s17Vwi0Vg9foUZASnpD@mail.gmail.com>
To: Glenn Maynard <glenn@zewt.org>
Cc: public-webapps@w3.org
On Thu, Jan 20, 2011 at 12:50 PM, Glenn Maynard <glenn@zewt.org> wrote:

> On Thu, Jan 20, 2011 at 2:36 PM, Alex Komoroske <komoroske@chromium.org>wrote:
>
>> If you intend "preview" to include large but smaller-than-full-size
>>> previews, eg. scaled to 50%, I'd recommend avoiding the word "thumbnail"; I
>>> think most people wouldn't consider that a thumbnail.  (I could probably
>>> come up with a reasonable UI where a preview is at 100%, too...)
>>>
>>
>> I agree, although I'm struggling with the precise wording to replace that
>> description with.  Do you have any suggestions?
>>
>
> I did, too.  The main generality behind previews that I came up with is
> that they're not actually the real, interactive page; they're more like a
> picture of the page than the page itself (eg. moving the mouse over it won't
> trip any mouseovers)--but that's far too complicated to get into for a
> description that should be simple and generalized.
>

How about:

“preview” : the page may be at least partially visible, but not in an
interactive form (e.g. a lower-resolution thumbnail when switching between
tabs).

>
> > visibilitychange
>>> >
>>> > A simple event, fired at the document object immediately after
>>> document.visibilityState transitions between visibility states.  The event
>>> has a property, fromState, that is set to the value of
>>> document.visibilityState just before it was changed to the current value.
>>>  Note that visibility has nothing to do with whether the document’s contents
>>> have fully loaded or not, which implies that for any given visibility
>>> transition event, onload may or may not have already fired.
>>>
>>> This should also include the old document.visibility value.
>>>
>>
>> Agreed, but what should the property of the event be called?  fromVisible
>> seems awkward.
>>
>
> "wasVisible" is more natural, but it may be inconsistent to use both "from"
> and "was" in the same event.  I'm not sure if there are any precedents to
> follow...
>
> I have a moderate preference for "wasVisible" given the extreme awkwardness
of "fromVisible"

>
> On Thu, Jan 20, 2011 at 6:47 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> > So an iframe that's scrolled out of view could return "hidden" if the
> browser wants?
>
> That's probably bad: if you're in a hidden iframe, you likely want to know
> if the document you're in is visible, not to always think you're hidden.
>

I think that's right.  I'll add language that makes it clear it's the
top-most containing page visibility.

If in the future there are valid use cases for an iframe to know when it's
hidden within its visible parent or scrolled off screen, we could provide an
additional visibility state in the second (optional) set of return values
for document.visibilityState that can be used for this case.


>
> --
> Glenn Maynard
>
Received on Friday, 21 January 2011 19:14:40 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:43 GMT