[heycam/webidl] Consider [LegacyStringClass] (#547)

See: https://github.com/w3c/svgwg/issues/175
@dstorey, @AmeliaBR

Folks working on SVG are trying to fix `href` and `className` in the SVG DOM to be more compatible with the HTML equivalent versions of those APIs. In HTML, these attributes get and set strings, in SVG they get `SVGAnimatedString` (and don't set), and `SVGAnimatedString` has `baseVal` (gets and sets string) and `animVal` gets a string only.

After a lot of thought, our "A" solution is to somehow make the `SVGAnimatedString` a type of actual string object for maximum compat, augmented with the `baseVal` and `animVal` attributes for backwards compatibility. This is the solution proposed in Issue https://github.com/w3c/svgwg/issues/175. 

How to actually do that? Following the pattern of `Legacy...` extended attributes, having `SVGAnimatedString` use a new [LegacyStringClass] seems like an option that might work, although there's a lot of assumptions we're making. We're hoping this issue and the smart folks working on WebIDL bindings can help work out if/how this could be achieved.

At it's surface, the interface would inherit from %StringPrototype%, but then we have a host of questions:
* what does it mean for an IDL interface type to *be a string* type? 
* Is it possible to define all the string-like capabilities/semantics that this object would have to emulate?
* How would this instance interact with the other built-in string operations? (Are the string operations in EcmaScript generic enough to work on "string-likes"?) 
* What is the mechanism for actually storing the string? How is a string type converted into this type when assigned to an attribute of this type? 
The list goes on.

If this is an insane idea, would love to know--it certainly seems like it will be complicated, but also pretty compatible if it does work.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/heycam/webidl/issues/547