- From: Anne van Kesteren <annevk@annevk.nl>
- Date: Mon, 21 Mar 2016 14:04:34 +0100
- 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. -- https://annevankesteren.nl/
Received on Monday, 21 March 2016 13:04:59 UTC