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

Re: Extended attributes vs. new types

From: Boris Zbarsky <bzbarsky@mit.edu>
Date: Wed, 25 Jan 2017 23:32:13 -0500
To: Domenic Denicola <d@domenic.me>
Cc: public-script-coord <public-script-coord@w3.org>
Message-ID: <2f943564-46c5-51fd-176b-52857975ff92@mit.edu>
On 1/25/17 5:20 PM, Domenic Denicola wrote:
> It seems the simplest thing to do is to just remove the ExtendedAttributesList that precedes such productions.

That could break some IDL consumers, no?  (I mean, I know for a fact it 
would break Gecko.)

> As you noted below only [Clamp], [EnforceRange], and [TreatNullAs] apply to arguments or dictionary members.

Of the extended attributes defined in the IDL spec.  But extended 
attributes are allowed to be defined by other specs, and are supposed to 
serve as a general extension point for cases when IDL needs to express 
implementation-specific things that there is no existing IDL syntax for.

Just looking at Gecko's IDL, we support [TreatNonCallableAsNull] on 
operation arguments to simplify the implementation of some legacy 
interfaces.  We also support all of our conditional-exposure extended 
attributes (things like "pretend this doesn't exist if some pref is not 
set", "pretend this does not exist unless we're in a sufficiently 
privileged context", etc) on dictionary members.  I would not be 
terribly surprised if at some point we want to support [SecureContext] 
on dictionary members, for similar reasons.

Received on Thursday, 26 January 2017 04:32:48 UTC

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