SVGAElement all attributes except href should be as HTML i.e. not SVGAnimatedString

[longsonr]

download, rel, relList, hreflang and type are all modelled as SVGAnimatedString attributes. There seems no reason to do this as they aren't much use as things to be SMIL animated (in fact download is stated to be non-animatable in the spec).

Possible solution

have these the same as the HTML specification i.e. 

       [SetterThrows]
       attribute DOMString download;
       [SetterThrows]
       attribute DOMString rel;
       [PutForwards=value]
       readonly attribute DOMTokenList relList;
       [SetterThrows]
       attribute DOMString hreflang;
       [SetterThrows]
       attribute DOMString type;

[AmeliaBR]

Closing as duplicate of #312. @longsonr, could you please add your suggestions to that issue?

[AmeliaBR]

Hmm... unless you want to make this a separate issue, just for the second point. In which case, edit the title accordingly & I'll re-open.

For reference: I made them animated strings for consistency with the SVG 1.1 properties on the interface. But I agree that there's no real use for them.

[longsonr]

@AmeliaBR I've narrowed it to just the non-href attributes. Can you reopen it please?

[dstorey]

I agree this is a good idea, especially as they're not currently implemented (AFAICT) with the exception of download in Firefox, but they implemented it as DOMString anyway.

We could even possibly look to pull them in from HTML as part of a mixin if they matched, which would keep them in sync.

[liamquin]

@longsonr , can Mozilla contribute any tests in this area to wpt for svg, assuming we change them to DOMString?

[liamquin]

[either way, we need to mark Dom support for these attributes as at risk in SVG unless we know we're getting 2 implementations this Summer.]

[css-meeting-bot]

The Working Group just discussed SVGAElement.

The full IRC log of that discussion

<AmeliaBR> Topic: SVGAElement
<AmeliaBR> Github: https://github.com//issues/315
<AmeliaBR> David: SVG 2 has new attributes added, they are currently defined as being exposed using SVGAnimatedString.
<AmeliaBR> ... No browsers implement them that way, the suggestion is to implement them using the basic HTML form.
<AmeliaBR> ... It would be easier to implement if consistent with HTML.
<AmeliaBR> Amelia: This issue was raised by Robert Longson, a Firefox implementer, so I suspect he also thinks it would be an easier implementation for them.
<AmeliaBR> David: It's easy to make the change, since they're not implemented, except that Firefox exposes download, and does it as a basic DOMString, not an animated string.
<dstorey> sorry my call dropped
<AmeliaBR> Liam: Are there any tests? Should we ask the person who proposed the change to provide tests?
<AmeliaBR> Amelia: He's a volunteer, not sure if he's familiar with the test requirements.
<AmeliaBR> Liam: Should they be marked at risk?
<AmeliaBR> Amelia: Yes, since they're not implemented, but we still need to think about which version is more likely to get implementations.
<AmeliaBR> Dirk: I would vote for changing to DOMString, and also marking as at-risk.
<AmeliaBR> Related issue for consideration: https://github.com//issues/312
<dstorey> (doesn't seem like it wants to dial me back in)
<AmeliaBR> Amelia: I think we're over time. Can we discuss more on GitHub? In particular, can implementers comment about whether you're likely to implement these properties at all, and if so whether you prefere DOMString versus SVGAnimatedString?
<AmeliaBR> Dirk: I don't want to see any new properties with SVGAnimatedString.
<AmeliaBR> Amelia: OK, so that's the kind of comments we should see.
<AmeliaBR> end topic
<AmeliaBR> s/end topic//

[dstorey]

I agree with @dirkschulze about avoiding any new SVGAnimatedString. We (Edge) are unlikely to implement these in the current form. Sharing the definition/implementation with HTML would make it more likely that we would implement.

[dstorey]

There are presumably 3 implementers (@dirkschulze, @longsonr, myself) in favour of using the HTML definition rater than SVGAnimatedString.

@liamquin, @AmeliaBR, @boggydigital: can we get a resolution on the change here, or do we need to do that formally on a call?

Furthermore do we want to do the same as tabIndex/dataset et al and ask HTML to define the common ones in a mixin that we include?