Repository navigation
SVGAElement all attributes except href should be as HTML i.e. not SVGAnimatedString #315
Description
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;
Activity
AmeliaBR commentedon May 7, 2017
Closing as duplicate of #312. @longsonr, could you please add your suggestions to that issue?
AmeliaBR commentedon May 7, 2017
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.
[-]SVGAElement webidl issues[/-][+]SVGAElement all attributes except href should be as HTML i.e. not SVGAnimatedString[/+]longsonr commentedon May 7, 2017
@AmeliaBR I've narrowed it to just the non-href attributes. Can you reopen it please?
dstorey commentedon Mar 12, 2018
I agree this is a good idea, especially as they're not currently implemented (AFAICT) with the exception of
downloadin 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 commentedon Mar 19, 2018
@longsonr , can Mozilla contribute any tests in this area to wpt for svg, assuming we change them to DOMString?
liamquin commentedon Mar 19, 2018
[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 commentedon Mar 19, 2018
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 commentedon Mar 19, 2018
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 commentedon Mar 20, 2018
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?
liamquin commentedon Mar 20, 2018
A related issue is that href has to remain an SVFAnimatedString. So anythink defined by HTML wouldn't include that. Another is that we need at least a couple of tests. Maybe I'll look at writing one for each attribute, if we agree on a type.
Yes, we need a minuted decision for spec changes, because we're at Candidate Rec, and this one is substantive (although sensible).
I've added Agenda+ as a label to put this on next week's agenda
dstorey commentedon Mar 20, 2018
Presumably target has to remain as that is implemented as specced, unless the usage is low enough we can change that one. Google has a measure on that one: https://www.chromestatus.com/metrics/feature/popularity#V8SVGAElement_Target_AttributeGetter
dstorey commentedon Mar 20, 2018
We should probably adapt the HTML tests for SVG here.
Download (presumably should pass in Firefox) and rel are at https://wpt.fyi/html/semantics/text-level-semantics/the-a-element
There are some rellist tests at https://w3c-test.org/html/semantics/rellist-feature-detection.html
css-meeting-bot commentedon Mar 26, 2018
The Working Group just discussed
SVGAElement all attributes except href should be as HTML i.e. not SVGAnimatedString.Resolution: Change all SVGAElement attributes to be consistent with HTML except for href
The full IRC log of that discussion
<AmeliaBR> Topic: SVGAElement all attributes except href should be as HTML i.e. not SVGAnimatedString<BogdanBrinza> GitHub: https://github.com//issues/315
<BogdanBrinza> https://www.chromestatus.com/metrics/feature/popularity#V8SVGAElement_Target_AttributeGetter
<BogdanBrinza> the usage of the target attribute seems low, but growing
<BogdanBrinza> not sure if that's because of the low absolute value and statistical noise
<BogdanBrinza> Proposal: change all attributes (except for href) to be consistent with HTML
<BogdanBrinza> that includes target
<BogdanBrinza> AmeliaBR: target has been included since SVG 1.1, so the argument could be keep it as it is
<BogdanBrinza> dstorey: Preference to keep consistency and potentially add mixin in HTML
<BogdanBrinza> krit: Generally usage seems to be very low and we might prefer to optimize for the future - which in this case might be aligning with HTML
<BogdanBrinza> Resolution: Change all SVGAElement attributes to be consistent with HTML except for href
boggydigital commentedon Jun 11, 2018
Not blocking updated 2.0 CR publication - assigning 2.0 Recommendation. We would want to fix this before publishing 2.0 Recommendation, but it's not urgent for updated CR
AmeliaBR commentedon Aug 13, 2018
Closing this issue after the changes merged in #409.
Those changes make the spec consistent with the Firefox implementation for all properties defined directly on the
SVGAElementinterface, and make it consistent with HTML for everything excepthrefandtarget.See #526 for further discussion of
target.See #312 for further discussion of
hrefand theHTMLHyperlinkUtilsmixin properties.