[PageVisibility] feedback

http://www.w3.org/TR/2011/WD-page-visibility-20110721/

> This interface can also be used to provide better runtime
> user experience decisions not related to power management.

> For example, a puzzle game could be paused when the user
> no longer has the game visible.

In some games the user might want to let the game clock tick even
while it isn't active. Having a game always kick me out just because
I'm not watching (but I can e.g. hear the game sound and switch back
before something bad happens) isn't nice.

> Further, this interface can be used by advertisers
> to not charge for ads that are not visible to users.

Or cause advertisers to change how pages render so that they don't
render any content until the user has actually "watched" the ad.

Which seems more likely.

> For example, the following Javascript shows a theoretical
> web based email client checking for new emails every

s/email/messages/g (or 'email', it's a mass noun)

> second without knowledge of the Page Visibility:

s/Javascript/JavaScript/g

> The script will always check for emails every second,
> even if the user is not actively viewing the page
> because it is not visible.

> This is an example of poor resource management.

Or maybe it isn't. My email client is generally minimized on my
desktop (if it isn't minimized, it's almost certainly behind
everything else in the window stack). But when I get email, it plays a
sound, and it gives me a notification (call it "WebNotification"), at
which point I can choose to restore it and investigate further.

Ideally examples should be written to encourage good behavior. In this
case, good behavior could be not updating a rendering UI, but it
shouldn't be not checking for data. The suggestion here is *not* good
behavior.

When my BlackBerry is in range, it gets data, my email client isn't
"visible", but I absolutely want that data to be retrieved
immediately. And since I was recently in Paris, France (and more
recently I ride on the TTC which has sporadic coverage), I really
appreciated that my BlackBerry would send and receive as much data as
it could during its bursts of network availability. If the screen is
off, the right thing to do is to not paint the screen, not to not
retrieve data from the wire.

If I was using my Phone and it decided not to check email because the
screen was off, and then I got into an area with no signal (TTC
subway, or Flight to Paris), I'd be really upset that it didn't have
my email.

> A DOM attribute is said to be getting when its value

One might 'be said to be getting a DOM attribute', but "a DOM
attribute does not go off getting anything". You're using the wrong
voice ("retrieved" is the right voice) or at least the wrong subject
and object.

> is being retrieved (such as by author script),
> and is said to be setting when a new value is assigned to it.

<one is said to be setting a DOM attribute when one assigns a new
value to a DOM attribute.>

> This section is non-normative

s/$/./

> This attribute returns true if the Document contained

The anchor here is around "<Document >contained", you should move the
<space> token outside the anchor...

This is a global comment as you've apparently copied and pasted the
same bad markup repeatedly.

> by the top level browsing context (root window in the browser's viewport) is not visible at all.

> This attribute returns true if the Document contained
> by the top level browsing context (root window in the
> browser's viewport) is not visible at all. This attribute
> returns false if the Document contained by the top level
> browsing context is at least partially visible on at least
> one screen.

I don't think "screen" is defined in your specification. So what do I
do if I'm using a Voice based browser?

> To accommodate accessibility tools that are typically
> full screen but still show a view of the page, when
> applicable, this attribute may return false when the
> User Agent is not minimized but is fully obscured by
> other applications.

This isn't sufficient text to address my question.

> The User Agent is fully obscured by an Accessibility Tool,
> like a magnifier, but a view of the page is shown.

Please note that it is possible for the UA to not be able to determine
this (the Magnifier is fully capable of running as an 'Administrator'
and the Browser is fully capable of running as a 'LUA' [1]


> This attribute is optional.

Does that mean that `document.PAGE_PREVIEW` may return `undefined`?

> This attribute may return document.PAGE_PREVIEW if the Document

Please note that `this` is confusing. You're using it to mean both
`document.<WHATEVER>` and `document.visibilityState`. You should
really only use `this` to mean one thing, generally it should be the
most recent thing, which would be `document.<WHATEVER>` and you should
use `the property` or something to refer to `document.visibilityState`
or whatever current property you're referencing.

> contained by the top level browsing context is not visible at
> all and a preview of the the Document is visible.

s/the the/the/

> This event can only be registered using addEventListener on document.
> This event will get fired on the first change in document.visibilityState
> after registration; it will not get fired on registration.

s/get/be/; s/get/be/

> •[VENDORPREFIX] is a capitalized name that identifies the vendor,
> •[NAME] is a capitalized name given to the visibility state,
> •[vendorprefix] is a non-capitalized name that identifies the vendor,
> •[name] is a non-capitalized name given to the visibility state.

Please require all of these to be ASCII.


[1] http://blogs.msdn.com/b/aaron_margosis/archive/2006/02/06/525455.aspx

Received on Wednesday, 27 July 2011 03:01:57 UTC