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
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Reply via email to