Replace xlink:href by href?

[pfefferniels]

The SVG that verovio generates seems to make frequent use xlink:href attributes in <use> elements. xlink:href is deprecated in SVG2 and I just ran into a strange bug where SVG.js failed to calculate bounding boxes because of that. Could it be replaced by just href?

[lpugin]

There is no plan to move to SVG2 in the near future. What is SVG.js?

[lpugin]

As far as I remember the xlink:href was chosen because some viewers would not work otherwise. I think it is (or was) the case for Safari.

[pfefferniels]

I see. This page was warning that some browser won't support it anymore in some future point.
SVG.js It's a library for manipulating SVG. I use it server-side in combination with svgdom. It only supports href, not xlink:href ...

[lpugin]

Since you use it server-side the best for now is simply to pipe the output through a simple XSLT that changes the attribute to href. Would this work for you?

I think it will be a long way until most browsers will support SVG 2.0, and until them it will be wiser to stick with the current version.

[lpugin]

As you can see here, href still has lower support than xlink:href:
https://caniuse.com/#search=svg%20xlink%3Ahref
https://caniuse.com/#search=svg%20href

[pfefferniels]

Since you use it server-side the best for now is simply to pipe the output through a simple XSLT that changes the attribute to href. Would this work for you?

I think it will be a long way until most browsers will support SVG 2.0, and until them it will be wiser to stick with the current version.

Yes, that's what I am going to do. Thanks for the information :)

[rettinghaus]

No need for replacement yet. The latest W3C Candidate Recommendation says:

A conforming SVG generator must generate ‘href’ attributes without a namespace. However, it may also generate ‘href’ attributes in the XLink namespace to provide backwards compatibility.

If we simply double the information we should achieve a higher compatibility.

[kepper]

…and we would increase filesizes considerably. I'm frequently running into issues with that, so I'm not in favor. Could that be an option in Verovio?

[rettinghaus]

Just tested it. It increases file sizes by about 2% to 3%.
@kepper compared to the output older versions of Verovio created that's still small. ;-)

[rettinghaus]

@kepper Tried to update Beethovens Werkstatt?

[kepper]

No time to look back at old versions – neither of Verovio nor our own tools. Right now I face files with 750+ measures / 8 staves, and huge amounts of additional (analytical) markup. This mostly affects RAM, but the plain XML easily exceeds 10MB. But that's a different story, and I'm not complaining. I just don't think that duplicating information is particularly clever…