Linking: ID + SVGViewSpec?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Linking: ID + SVGViewSpec?

Paul LeBeau
Hi all

I noticed while testing an idea the other day that the fragment identifiers spec is now a little deficient, in that it assumes the other SVG is in an external document.

Given that pages containing multiple SVG elements are becoming very common.  It might be nice to be able to reference another SVG within the document and supply an SVGViewSpec.

An example use case could be:

<svg id="main-image" width="1000" height="1000" viewBox="0 0 1000 1000">
   ...
</svg>

<svg id="zoomed-detail">
  <use xlink:href="#main_image#svgView(viewBox(100,200,20,20))" width="100" height="100"/>
</svg>

Thoughts?  Would it be useful to extend fragment identiers in some way in order to allow an ID plus an SVGViewSpec etc?

Paul

Reply | Threaded
Open this post in threaded view
|

Re: Linking: ID + SVGViewSpec?

Nikos Andronikos
Hi Paul

On 18 Feb 2016, at 6:33 AM, Paul LeBeau <[hidden email]> wrote:

Hi all

I noticed while testing an idea the other day that the fragment identifiers spec is now a little deficient, in that it assumes the other SVG is in an external document.

Given that pages containing multiple SVG elements are becoming very common.  It might be nice to be able to reference another SVG within the document and supply an SVGViewSpec.

An example use case could be:

<svg id="main-image" width="1000" height="1000" viewBox="0 0 1000 1000">
   ...
</svg>

<svg id="zoomed-detail">
  <use xlink:href="#main_image#svgView(viewBox(100,200,20,20))" width="100" height="100"/>
</svg>

Thoughts?  Would it be useful to extend fragment identiers in some way in order to allow an ID plus an SVGViewSpec etc?

Paul


That seems like a reasonable use case.

We’re currently trailing github for issue tracking, so I’ve copied this there:

We’ll follow up on github.

Thanks,
Nikos.





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.
Reply | Threaded
Open this post in threaded view
|

Re: Linking: ID + SVGViewSpec?

Amelia Bellamy-Royds
Hi Paul,

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 [1], and am copying them below for you.  For now, I think you can workaround you primary use case with nested coordinate systems.

Amelia




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:

```html
<svg id="main-image" width="1000" height="1000" viewBox="0 0 1000 1000">
   ...
</svg>

<svg id="zoomed-detail" viewBox="100 200 20 20" width="100" height="100"
        style="overflow: hidden" >
  <use xlink:href="#main_image" />
</svg>

```

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.