- From: Anssi Kostiainen <anssi.kostiainen@nokia.com>
- Date: Wed, 12 Oct 2011 18:55:44 +0300
- To: ext Giuseppe Pascale <giuseppep@opera.com>
- Cc: ext Bryan Sullivan <blsaws@gmail.com>, "public-device-apis@w3.org WG" <public-device-apis@w3.org>, Dave Raggett <dsr@w3.org>
Hi, On 12.10.2011, at 18.19, ext Giuseppe Pascale wrote: > On Wed, 12 Oct 2011 17:05:29 +0200, Anssi Kostiainen <anssi.kostiainen@nokia.com> wrote: > >> As per the discussion during today's call, I added the following step to the API checklist: "the API should be implementable in pure JavaScript to allow shims for browsers that do not have native implementations": >> >> http://www.w3.org/2009/dap/wiki/ApiCheckList >> >> Sometimes obeying this rule may not lead to the best possible design, thus "should". Feel free to embellish. >> > Of course not everything will be implementable in javascript. If that was the case already, then why bothering writing a spec, we should be writing a js library. > The concept I (we) are trying to push is that, when possible, a design that allow an high level API to be designed on a small set of features embedded into the browser is desirable. I think we're after the same thing. I mean the API should allow shims, or to be exact polyfills [1], such as [2]. I reworded the statement a bit to make this clearer: "the API should be implementable in pure JavaScript to allow shims that mimic the API and provide fallback functionality" -Anssi [1] A shim that mimics an API providing fallback functionality to older browsers. [2] https://github.com/Modernizr/Modernizr/wiki/HTML5-Cross-browser-Polyfills
Received on Wednesday, 12 October 2011 15:56:54 UTC