W3C home > Mailing lists > Public > public-web-perf@w3.org > July 2011

RE: [PageVisibility] Feedback

From: Jatinder Mann <jmann@microsoft.com>
Date: Tue, 26 Jul 2011 18:09:03 +0000
To: "public-web-perf@w3.org" <public-web-perf@w3.org>, Anne van Kesteren <annevk@opera.com>
Message-ID: <EE4C13A1D11CFA49A58343DE361B0B04068D5A81@TK5EX14MBXC254.redmond.corp.microsoft.com>
Anne, thank you for taking the time to review the spec.

1. The hidden attribute on Document is potentially confusing with the hidden attribute existing on all HTML elements, especially as the Document object sometimes shares such global HTML attributes (dir and numerous event handler attributes). Maybe isVisible would be better?

My understanding is that the HTML5 hidden attribute is only defined for HTML elements, which would preclude the Document object as it inherits from Node. There is no conflict here.

Using document.hidden would make feature detection easier than using document.isVisible. For example, using if (document.isVisible) for feature detection has the downside that the undefined case, which legacy browsers would hit, is equal to the not visible case - legacy browsers will get the behavior defined for the hidden page. Doing feature detection on document.hidden will ensure that the undefined case is equal to the visible page case - legacy browsers will get the page with the visible behavior. 

2. visibilityState should presumably return a DOMString.

Thanks for catching, this is a typo. I will update the spec.

3. We use strings in a number of APIs and it is clearly a better approach however none of these APIs currently expose them as constants and I do not think there is a good reason to do that. Examples of such APIs are XMLHttpRequest (the responseType attribute) and the HTML Canvas 2D Context (numerous attributes).

Constants have the advantage of allowing web developers to inspect for capability via developer tools and IDEs rather than read documentation to find out which strings are supported.

5. Instead of using [NoInterfaceObject], a different interface name, and implements, please simply use "partial interface Document".

My understanding is that using [NoInterfaceObject] with a different interface name and implements is functionally the same as using "partial interface Document". Is this not the case?

Received on Tuesday, 26 July 2011 18:09:32 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:31 UTC