The information contained in this email message and any attachments may be confidential and may also be the subject to legal professional privilege. If you are not the intended recipient, any use, interference with, disclosure or copying of this material is
unauthorised and prohibited. If you have received this email in error, please immediately advise the sender by return email and delete the information from your system.
We discussed this issue on the call today & decided that it is definitely interesting, but should be deferred until we have time to consider all the complications.
I've added detailed comments to the GH issue thread for future reference , and am copying them below for you. For now, I think you can workaround you primary use case with nested coordinate systems.
The argument I made on today's call (which no one objected to) was essentially:
- yes, this could be a useful feature
- but it's not something simple to spec or implement,
- and therefore it should be deferred until after SVG 2 work is complete.
Target fragments (the part after `#` in the URL) are currently interpretted based on the document language. HTML has rules (scroll the targetted element into view) that are quite different from SVG.
The SVG rules are based on the assumption that you are viewing a complete SVG document, either in a stand-alone viewer (e.g., browser tab), or embedded in a different document (e.g., HTML `<img>` or `<object>`). If you use SVG view target fragments (or SVG `<view>` elements) with inline SVG in an HTML document, it has no effect.
I like the idea of having more control over `<use>` element embeddings, to be able to create a zoomed-in view. However, there are already different rules for `<use>` based on what you're embedding: plain graphics, `<symbol>` elements, `<svg>` elements. For re-using `<symbol>` and `<svg>`, the `width` and `height` attributes have an effect, for ordinary graphics they don't, which would need to be factored in.
A more general concern is that overloading the `href` attribute with two different target fragments is semantically confusing and would probably be difficult to animate with good performance.
Another way to achieve this goal may be to add a `viewBox` attribute to `<use>`. Like the `width` and `height` attributes, it could override the corresponding attribute on re-used `<svg>` and `<symbol>` elements.
In the meantime, I think a workaround would be to re-use the content (with its original coordinate system) element into a new SVG that has the coordinate system you want:
Because there are no `width` and `height` attributes on the `<use>` element, the reused content will be drawn as 1000*1000 units starting at (0,0), but it will be scaled and translated to the new coordinate system.