Two questions about the `<a>` element about svgwg

[nikosandronikos]

http://www.w3.org/Graphics/SVG/WG/track/actions/3825

[heycam]

For 1., the HTML spec has an authoring requirement that <a> elements are not nested, so I think we should do the same.

[heycam]

Regarding the action, quick testing shows that in HTML the inner link is activated, so again I think we should just require that.

[nikosandronikos]

Think I'm missing some terminology here.
What do you mean by activated? That the inner link is treated as a well formed link and not ignored? That's what I'm seeing, but it seems to contradict making the requirement that not be nested.

[heycam]

Activated as in when you click it it's that element's href that is navigated to.

[nikosandronikos]

RESOLUTION: the content model of the a element in SVG will allow nested a elements
https://www.w3.org/2016/02/18-svg-minutes.html#item02
Decision based on the following points:

• This is a useful semantic tool and there's no reason to forbid it
• Browsers do support this even though the HTML spec disallows nested a elements so interop already exists

The plan is also to bring the other attributes onto the SVG a element.

[AmeliaBR]

Looking again at @heycam's test. I'm assuming the reason the nested link is inserted by script is because the HTML 5 parser would treat this as an authoring error, and close off the outer link when you start the inner link. So I don't think that should really be used as an example of "it works in HTML, so it should work in SVG".

That said, the HTML 5 parser is much less fussy once it gets to SVG, so if we say it is OK, it's OK. It is definitely useful to be able to define an image map with specific link regions as well as a generic "background" link. (Although that doesn't require nested links, it could be done simply with layering.)

[AmeliaBR]

Test case for SVG links inside links: http://jsbin.com/nidixomute/1/edit?html,output
Variation with focus styles: http://output.jsbin.com/quvuyaxace/1

Currently, Chrome and Safari do not render the content inside the nested link (the orange ellipse is visible, no blue link to the GitHub issue). Firefox, Edge, and Batik Squiggle render the blue ellipse and link it as specified by the nested <a>; they also have no problem with the tab order (nested link comes after outer link). rSVG and Inkscape also render the blue, although Tav said the nested links seemed to confuse element selection dialogs.

Technically, Chrome & WebKit are correct by SVG 1.1: don't render SVG elements that are in places they don't belong, and don't put a link inside a link. However, given the lack of compatibility, I don't see a problem with making the Firefox/Edge/etc behavior correct for SVG 2.

[AmeliaBR]

On adding attributes: the whole purpose is consistency with HTML, but we already have an existing inconsistency that href and target are implemented on SVGAElement as animated strings, so the IDL is of the form linkElement.target.animVal = "_blank".

Which means either I introduce the new properties in a way that's inconsistent with HTML (make them also animated string) or inconsistent with the existing properties).

[AmeliaBR]

Closed by 33f85d2

I made the new IDL attributes consistent with the old SVG ones; see #175 for a possible way to address this mess.

I added a "at risk" warning for nested links. I'm worried it could cause problems in the accessible representation.

[AmeliaBR]

Important: The resolution above about "allowing nested links" was revised based on accessibility testing:
#178 (comment)

Current advice (and SVG 2 spec) is that the nested link should render but would not be treated as an actual link.