re. binary size: I'd hope ICF would collapse the truly identical stubs; the rest presumably differ in something like the property name passed to ExceptionState (which would be web-visible)

peria@ and I recently had a discussion about a similar thing; how to support aliases that Web IDL cannot represent.

The situation is that we have an IDL interface "Foo", and its prefixed version "webkitFoo".  Suppose that these two properties must return the exactly same object [1], then there is no way in Web IDL to represent an alias "webkitFoo" [2].

[BindingAlias=] is good to know.  Although, this doesn't work nicely with a complex combination with [RuntimeEnabled=].  Actually no extended attribute works nicely with a complex combination with [RuntimeEnabled=] because RuntimeEnabled is a meta concept over extended attributes.  Sigh.  So, it's not flaw of [BindingAlias=].


[1] Maybe it's not mandatory to return the exactly same object.  Like [NamedConstructor], it might be acceptable to return a different object but it has the same prototype chain.

[2] Web IDL can define an attribute that returns the same object, but in this case, the attribute is an accessor property, not a data property.  Maybe the difference doesn't matter much, though.

----

> We need this in order to implement generated CSSStyleDeclaration attributes, as some of the attributes we expose to the web cannot be written as valid WebIDL. Implementing this extended attribute would also allow us to replace current attributes implemented with [ImplementedAs=], possibly saving us binary space.

Could you elaborate your situation for more details?

As long as CSSStyleDeclaration is defined in a web standard based on Web IDL, [BindingAlias=] shouldn't be necessary to implement CSSStyleDeclaration.  Why do you want [BindingAlias=]?

For the binary size, I'm suspicious.  We already have thousand-ish properties.  Unless there are a lot of aliases, the impact wouldn't be huge.

> Could you elaborate your situation for more details?
>
> As long as CSSStyleDeclaration is defined in a web standard based on Web IDL, [BindingAlias=] shouldn't be necessary to implement CSSStyleDeclaration. Why do you want [BindingAlias=]?

Per the CSSOM spec, we should be generating actual IDL attributes for each CSS property to be implemented on CSSStyleDeclaration. We, as of right now, implement this as an anonymous getter, but this creates some interoperability issues (see bug 700338 for more information). The problem is with dashed properties, as according to the spec (https://drafts.csswg.org/cssom/#dom-cssstyledeclaration-_dashed_attribute) they need both an attribute in camel case and with the dash. WebIDL identifiers are defined as /_?[A-Za-z][0-9A-Z_a-z-]*/ (note that a leading dash is not allowed), so e.g. -webkit-line-clamp would not be a valid IDL attribute.

(incidentally, our current IDL parser does not allow dashes anywhere in an attribute name, but that's something that can be fixed)

I'm not entirely sure about the binary size part, #1 makes a good point that ICF might fold all the identical functions but since most CSS properties have a dash somewhere, that means most CSS properties will have 2 or 3 generated IDL attributes.

Thanks for the explanation.  I think I now understand the situation.

1. Support of hyphenated-attribute-name is must-have.

2. There is a concern about binary code size.

peria@, would you address on issue 1. hyphenated-attribute-name?
I think your patch https://crrev.com/c/1092219 partially solved the issue, and we'll need some more work in the bindings code generator.

For  issue 2 , once issue 1. gets resolved, let's see how much the binary size will increase first.  And then, let's address it if necessary.

Yes, I can work for 1, but it is independent from this issue, so let's file a new issue for it. (issue 850972)