On Tuesday, 10 April 2018 00:57:43 UTC-7, Gijs Kruitbosch  wrote:
> On 10/04/2018 03:07, Cameron McCormack wrote:
> > On Tue, Apr 10, 2018, at 11:58 AM, Jeff Gilbert wrote:
> >> Do we have a heuristic for when to /not/ include something from HTML in 
> >> SVG?
> > 
> > If it doesn't make two features which already exist in both HTML and SVG 
> > more consistent, then I wouldn't include it.
> > 
> >> More or less, these additions to SVG just strike me as having solid
> >> potential risk (for both spec-interaction and implementation bugs) and
> >> negligible upside. Do we have people asking for this?
> > 
> > I don't know of people asking for this, but I would hope that we could 
> > share the implementations of these properties between HTMLAnchorElement and 
> > SVGAElement.  The closer the two <a> elements are in behavior, and the more 
> > we can share implementation between them, the lower the risk for bugs 
> > between the two.  (Ignoring the general risk of bugs from touching code at 
> > all.)
> I don't know about the C++ side of things here in terms of shared 
> implementation, but *behavior* is already different as per spec. And we 
> (frontend folks who have to make sure things like context menus deal 
> with arbitrary web content) regularly forget that, and then end up being 
> bitten by it. Most annoyingly, for SVG <a> the `.href` property is an 
> SVGAnimatedString object with `baseVal` and `animVal` properties, not a 
> string like it is in HTML.
> I assume that the same thing applies to the properties this is adding, 
> which means this is on the one hand more consistency with HTML (same 
> properties) and on the other hand, less (different values anyway).
> ~ Gijs

Hi, I work on MS Edge and I'm helping drive these changes. 

The idea here is quite the opposite. We're trying to make the same concepts in 
SVG share the same specified behavior as HTML. For example in SVG today these 
say to return an SVGAnimatedString. With this change they return a DOMString 
(except relist which returns a DOMTokenList object) and thus match the HTML 
definition. The defined behavior will be in HTML as Anne mentions. We've 
already made a similar change for SVGElement, where focus() et al were defined 
in the SVG spec with a note that they behave the same as HTML. Now they're 
defined in a HTMLOrSVGElement mixin in HTML and the definition is removed from 
the SVG spec. This one was an easy change as the behavior was already aligned.

Your point about href is a good one. That is one we can't redefine as DOMString 
due to already being implemented and having usage on the web. We're trying to 
avoid future cases like this by aligning behavior/specs. There may be some ways 
we can align href while keeping legacy behavior so things don't break, but 
don't have a concrete proposal for this yet.
dev-platform mailing list

Reply via email to