- From: Simon Pieters <simonp@opera.com>
- Date: Thu, 22 Aug 2013 11:37:00 +0200
- To: "Tab Atkins Jr." <jackalmage@gmail.com>, "David Bruant" <bruant.d@gmail.com>
- Cc: "Boris Zbarsky" <bzbarsky@mit.edu>, "www-dom@w3.org" <www-dom@w3.org>
On Thu, 22 Aug 2013 10:03:34 +0200, David Bruant <bruant.d@gmail.com> wrote: > Le 22/08/2013 04:11, Tab Atkins Jr. a écrit : >> On Wed, Aug 21, 2013 at 5:56 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote: >>> On 8/21/13 8:43 PM, James Craig wrote: >>>> if (typeof document.body.ondismissrequest !== "undefined") { >>> >>> Just if ("ondismissrequest" in document.body), I'd think. > I could not agree more :-) > >> Yeah, this is all you need to do. It's not perfect, but web devs are >> good at making a racket when we accidentally ship something that >> passes this test but doesn't actually work. > Unfortunately indeed. > This reminds me of discussions related to FirefoxOS (when some features, > disabled for security reasons are exposed as null [1]). > Also reminds me of a comment I read from the Persona project [2] > > Maybe specs (WebIDL?) should start providing guidance on how not to > expose an API when it doesn't work (disabled for security reason or > else)? [[ When support for a feature is disabled (e.g. as an emergency measure to mitigate a security problem, or to aid in development, or for performance reasons), user agents must act as if they had no support for the feature whatsoever, and as if the feature was not mentioned in this specification. For example, if a particular feature is accessed via an attribute in a Web IDL interface, the attribute itself would be omitted from the objects that implement that interface — leaving the attribute on the object but making it return null or throw an exception is insufficient. ]] http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#extensibility -- Simon Pieters Opera Software
Received on Thursday, 22 August 2013 09:31:39 UTC