W3C home > Mailing lists > Public > public-script-coord@w3.org > January to March 2016

Re: [SecureContext] - throw or hide

From: Anne van Kesteren <annevk@annevk.nl>
Date: Mon, 21 Mar 2016 14:04:34 +0100
Message-ID: <CADnb78jg-1MJns3ki3a36rW5pPFSdRNPFMubS_5DvqaDa_kgEQ@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: Jonathan Watt <jwatt@jwatt.org>, Richard Barnes <rbarnes@mozilla.com>, Martin Thomson <mt@mozilla.com>, public-script-coord <public-script-coord@w3.org>
On Mon, Mar 21, 2016 at 1:57 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 3/21/16 4:53 AM, Anne van Kesteren wrote:
>> I think it's mostly Richard and Martin that favor tying this to exposure.
> And me, for what it's worth.  I strongly believe we should not be exposing
> attribute getters that are 100% guaranteed to throw when called.
>> I think that only works well for new APIs. We'd then still need
>> something for legacy APIs we want to limit to secure contexts (maybe
>> just prose).
> Why?   That is, why do you think it's more web-compatible to make an API
> that's feature-detected as present throw than to make it feature-detect as
> not present and hence trigger polyfills.
>> I tend to think we should just do whatever is least complicated
> And most likely to actually be shippable, yes.

Are there many APIs under consideration that are attributes? I thought
most were methods. I agree it makes sense to go this way if there's a
lot of attributes.

The problem with existing APIs I was thinking of has these assumptions:

* It's a method that returns a promise
* It ships in enough browsers that developers invoke it without a feature test

E.g., Web Crypto, though you told me that particular API was already
not very interoperable to begin with.

Received on Monday, 21 March 2016 13:04:59 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:25 UTC