Inkscape SVG unresizable in Firefox (needs viewBox?)

[Colin Finck]

If I embed a SVG file from the Tango Icon Library
(http://tango-project.org/releases/tango-icon-theme-0.7.2.tar.gz), which
has been created with Inkscape, it is unresizable in Firefox (tested with
2.0.0.1).

I looked into the SVG file and found that it defines the parameters
'width="48px" height="48px"'.
If I replace these parameters with 'viewBox="0 0 48 48"', the SVG will be
resized correctly under Firefox using the following syntax:

<object data="internet-mail.svg" type="image/svg+xml" style="width: 32px;
height: 32px;" />

Otherwise the image will be cropped.
See the attached example for more details.

I'm not an expert in SVG, so I cannot tell you the best solution here.
But in my opinion, Inkscape should only use the 'viewBox' parameter and
drop the 'width' and 'height' parameters. Otherwise you cannot scale the
created files in Firefox.
Other SVG files I found, for example the feed icon at
http://www.feedicons.com, also use only a 'viewBox' parameter and no
'width' and 'height' parameters. Therefore they scale correctly under
Firefox.

[fantasai (fantasai)]

Created an attachment (id=169879)
testcase

[Bzbarsky (bzbarsky)]

So to get this to work we'd need an nsIImage implementation for SVG, and an
imgIDecoder. These will have to allow pixel-by-pixel access to the SVG image
data (presumably cached, not computed on every pixel access) and provide some
metadata about the image (notably the intrinsic size).

If that's done, there will need to be no changes to nsImageFrame, since SVG will
just look like any other image. Note that this will not allow interactivity and
such the way <object> does.

[Pavlov (pavlov)]

I don't think it makes sense to "decode" an SVG image in to an nsIImage. Things
like animation, etc won't work if you do this (without a huge amount of extra
work). If we really want this to work, i'd guess that changes similar to those
in the object frame would have to go in to image frame. That kinda sucks though
and isn't very flexable...

[Bzbarsky (bzbarsky)]

Frankly, we want to have SVG working in list-style-image, background-image, etc,
etc, not just in <img>.

So either all images work the same way (and all these places use the image
apis), or we don't support SVG images (just SVG documents) or we hack every
single one of these places somehow, probably implementing the equivalent of
SVG-to-nsIImage glue in 3-4 places.

This is complicated by the fact that for <img> we won't know we're dealing with
SVG until we get it.... For <object>, if it claims to be SVG and comes out HTML
we just render the HTML, but for <img> that would seem to be somewhat
undesirable. 404 pages in <img> tags, anyone? ;)

[Christian Biesinger (cbiesinger)]

note bug 272288 comment 1 and (especially) bug 231179...

[codedread (codedread)]

Any disposition on this bug? It would definitely be an improvement to support
SVG wherever a raster image is allowed (<img> tag, background images, etc).
This could turn out to be a killer feature for a browser to have.

What makes this killer is if the image is a "live" SVG image
(though I will agree with Tim Rowley in Bug 272288, that it is ambiguous in the
SVG spec). Imagine being able to animate your background image while displaying
your HTML over top. Currently this is only possible with a compound XHTML
document or some form of foreignObject within a SVG root document.

[fantasai (fantasai)]

I am sure there was a Gecko demo at some point with animated GIF backgrounds.

[Jerfa (jerfa)]

*** Bug 298682 has been marked as a duplicate of this bug. ***

[Sdteffen-gmail (sdteffen-gmail)]

Would it make things much easier to leave out the animation part for the time
being? I guess that most users are interested in simply replacing unanimated
images with SVG ones (e.g. to improve quality).

[Holger-treebuilder (holger-treebuilder)]

when using <image xlink:href="example.svg"/> in ASV the result is always a
static SVG, no animation no scriting. i think this is the desired behaviour for
<html:img> as well. the interactivity and animation feature for background
images would be cool, but can wait, given that there is currently no animation
support, and i think user events dont make sense on backround images, so
enabling scrips in image is questionable. if you need script access you got to
use <object> because image does not have any scripting interfaces (
contentDocument,contentWindow)
maybe just enable the onload event.
so i guess the solution Boris Zbarsky proposed in comment #2 would be the right
way to go for now.

[codedread (codedread)]

I agree that the simple solution right now would be to do what Holger is
suggesting (a frozen and isolated view of the SVG document) if it will mean
quicker implemention. And while I agree with Holger's interpretations, I would
recommend contacting the W3C CDF working group as they are the definitive source
of answers (even if they don't have all the use cases yet) .

At least in my initial emails with Chris Lilley he felt that scripting and
animation could still happen in a background-image or a <img> (which would be
nice). He did agree that events would not be able to flow from HTML DOM to SVG
DOM through background-image (i.e. SVG is "underneath") but that events might be
able to go through HTML DOM to SVG DOM. The bottom line is that all these use
cases need to be thought out and described unambiguously in the CDF spec.

See http://www.w3.org/TR/2005/WD-CDRReqs-20050404/ and
http://lists.w3.org/Archives/Public/public-cdf/ for more and let's get that
clarified soon so Mozilla has clear direction on implementation.

[codedread (codedread)]

correction:

"...but that events might be able to go through HTML DOM to SVG DOM through an
html:img tag"

[Chris Hubick (hubick)]

A note on perspective and intrinsic sizing, I just wanted to leave a quick
pointer to bug 70978 (and maybe bug 70976). That is to say, it would be (more
than) nice for the ability to include an SVG graphic, say only specifying an 80%
width, and have the height automatically scaled to maintain the image's
intrinsic perspective. If I want to include an SVG banner for a website that
will scale properly when displayed on a 2" Cell Phone screen or 20" Desktop LCD
- I can specify a width of 80% of the page, but there is then no way to specify
a height that will maintain the image's perspective. Em's could be used, but
that's a less than ideal workaround.

[Petr Písař (petr-pisar)]

This missing function really suck. Now when we have native SVG support in stable version of FF. In the bug 320875 is testcase with nodefault object size but with size defined in the SVG file in contrast to the PNG.

[Ian-hixie (ian-hixie)]

(In reply to comment #4)
> This is complicated by the fact that for <img> we won't know we're dealing
> with SVG until we get it.... For <object>, if it claims to be SVG and comes
> out HTML we just render the HTML, but for <img> that would seem to be somewhat
> undesirable. 404 pages in <img> tags, anyone? ;)

If we support SVG in <img> then I see no reason we wouldn't support HTML in <img> (with 404s being handled as failed loads just like for <object> elements -- <iframe> is the only one of these element that ignores errors and doesn't fall back to its fallback for them). In fact, I don't see how we couldn't. Anything that supports SVG automatically supports HTML in our architecture. They're the same thing, for all intents and purposes.

The question is whether we want to support vector graphics in <img> at all. One could argue that <img> (just like <svg:image> in SVG Tiny) should be only for raster images. But then one could also argue the opposite...

[Ian-hixie (ian-hixie)]

I suppose one option (which reading the comments again may have been what you had in mind anyway) is to say that any |Document|s that end up rendered by an <img> are rendered as static bitmaps, much like if they were used in CSS, so that they are image |Frame|s and so we sidestep the problem hyatt would have with all this (namely that <img> should always have the same kind of render frame, and that it shouldn't be able to change from an image render frame to an iframe render frame, for example). Hmm...

[Mattraymond (mattraymond)]

I we should have the following guidelines when using SVG as a graphics format:

1) Scripts should not be executed.
2) Elements in non-SVG namespaces should generally be ignored.
3) Any elements unrelated to presentation should be ignored.
4) CSS should be ignored???

I do not think rendering a one-time static image is a good option, because the image can't be resized. Wasn't that the whole point of vector graphics to begin with? Also, we already allow stuff like animated GIF images (and MNG when using MNGZilla), so I don't see a justification for using a static image for SVG unless animation in SVG cannot be accomplished without scripting. (I admit that my knowledge of SVG is to limited to make a determination on the latter issue.)

[Mauve-mauveweb (mauve-mauveweb)]

Allowing SVG in <img>s is bad news. Many web applications differentiate <img> as fairly innocuous allowing it even from third parties, but not <object>, because <object> holds power.

SVG is incredibly powerful. It contains scripting, hyperlinks, <svg:image> even allows possibly third-party images to make HTTP requests. I also suspect that a fairly small SVG can DoS the renderer by requiring exponential time to render. That is a huge paradigm shift.

<img> tags would require a neutered implementation of SVG to match the security model of most sites, even more so than just dropping scripting and animation - it would need at least to disallow <svg:image> links to third and fourth parties, and have a render timeout.

I would recommend this is not fixed until that stuff can be thoroughly looked at.

[codedread (codedread)]

Agreed. As per comment #10...

[codedread (codedread)]

Btw, I consider this a low-priority bug compared to the SVG CSS one (Bug 231179). The CSS bug prevents us from doing really cool things. This bug would just be a "nice to have"...

You can already do most things you need to do here with the object tag, so it doesn't hurt developers as much. As developers, we can just use <object> anywhere you wanted to use an <img> tag (unless I'm missing something).

[Bzbarsky (bzbarsky)]

The SVG CSS bug is really the same bug as this, basically... That is, the functionality needed from the point of view of Gecko is the same. Some of the security concerns are different, of course.

[Holger-treebuilder (holger-treebuilder)]

(In reply to comment #17)

> 1) Scripts should not be executed.

maybe enable only the onload event, like the batik-rasterizer does.

> 2) Elements in non-SVG namespaces should generally be ignored.

if we could have the onload event and/or XSLT transformations (or even xbl), elements from other namespaces might be usefull.

> 3) Any elements unrelated to presentation should be ignored.
> 4) CSS should be ignored???

no, css stylable images are cool !

>
> I do not think rendering a one-time static image is a good option, because the
> image can't be resized. Wasn't that the whole point of vector graphics to begin
> with?

well, i guess the svg should be re-rasterized when the size changes.

> Also, we already allow stuff like animated GIF images (and MNG when using
> MNGZilla), so I don't see a justification for using a static image for SVG
> unless animation in SVG cannot be accomplished without scripting.
>

yes you could prerender some frames and then display them in a loop,
the problem is that there is no way to determin how long the animation takes.

[Bzbarsky (bzbarsky)]

> maybe enable only the onload event, like the batik-rasterizer does.

From an XSS/security point of view, this is equivalent to allowing all scripting.

[Holger-treebuilder (holger-treebuilder)]

(In reply to comment #23)

> From an XSS/security point of view, this is equivalent to allowing all
> scripting.

i see :-( , so what about xslt/xbl then ?

[Bzbarsky (bzbarsky)]

Probably OK, though most of XBL would not work (no scripting, so no constructors, etc). You could still create anonymous content, though. That seems reasonably safe.

[Millennium-spoonybards (millennium-spoonybards)]

What if the img tag supported only SVG Tiny, with the object tag required to use full SVG? This seems to (at least theoretically) answer the security concerns, while still allowing a well-documented subset of SVG in the img tag. I can see only two clarifications which would need to be added: foreign namespaces are not recognized when included through the img tag, and svg:image would not support SVG (but would support, for example, JPEG and PNG, and possibly other bitmap formats) when included through the img tag.

SVG Tiny doesn't support scripting, it doesn't necessarily have to support elements from other namespaces, and it doesn't necessarily have to support SVG in the SVG:image tag. Would an implementation of SVG Tiny which didn't support these two optional things be safe? Obviously you couldn't do everything with this that you could with full SVG, but I'm not sure this is a Bad Thing, since the object tag still exists to handle full SVG.

It seems to me that if this method can be shown safe then it would provide, if not necessarily the best of both worlds, then at least a decent compromise. The full power (and danger) of SVG would not be available through the img tag, but a well-documented standard subset would be. Tiny is, by itself, powerful enough to handle most aspects of vector graphics, and what it can't handle could be dealt with through the object tag.

It's just a thought, anyway. I might even be wrong about Tiny being safe, in which case the whole thing is moot. But if it would be safe, then might it be satisfactory?

[Bzbarsky (bzbarsky)]

> SVG Tiny doesn't support scripting

You must mean SVG Tiny 1.1 or something? SVG Tiny 1.2 most certainly does.

More to the point, implementing both SVG profiles in the same code is a lot of work -- about twice as much work as only implementing one and putting some restrictions on it.

[Holger-treebuilder (holger-treebuilder)]

(In reply to comment #26)
> What if the img tag supported only SVG Tiny, with the object tag required to
> use full SVG?

i would object to that, i think this feature would be nice to have especially where you need a complex graphic, but you dont need a dom and stuff.
especially the most expensive features of SVG like filters would benefit most from solving this bug, because then i could pack tons of filters in a file,
without loosing performance of the browser, but filters are not part of SVGT. using SVGT would cost to many features, like clippathes, masks, opacity, gradients, filters.
i recently had a little project where this would come in handy, i wrote an XSLT to create a barchart on the clientside. the largest benefit here is
the saved serverload and bandwidth. so only a small chart description is send to the browser. with xslt, i turn that description into a complex barchart graphic with 100s of objects with grandients , opacity, strokes and filters
this works great, but try embeding this chart in a html file; firefox nearly
dies when you try to scroll. as i dont want to change the chart via script, a one shot still image would be enough for me. having this bug fixed would gain me the best of two worlds: decreased server load and bandwith, and good performance on the client while still providing graphicly rich content.
(here is an example: http://www.treebuilder.de/default.asp?file=172558.xml i had to revert to a prerendered image because of the performance issues, and this is only a small example )

also i think it is not neccesarry to revert to SVGT because SVG allows for sub profiling via modules. so we could have an SVG full implementation without the scripting module.

[Arpad Borsos (swatinem)]

What exactly are the security concerns? I mean what can be exploited via scripting that can harm the user or steal his data? An SVG embedded via img does not have any relation to the parent document so it can't steal any data. And XmlHttpRequest does only work on the same domain name anyway so there is no way to send any stolen data.
And how do these security concerns relate to svg images in css? (#231179) CSS is used by the site author and is not meant to harm anybody, whereas the img tag can be used by and 3rd person in message boards for example.

[Christian Biesinger (cbiesinger)]

there are other ways to send data than XMLHttpRequest... (forms, <img src="....?data=whatever"> come to mind)

[Bzbarsky (bzbarsky)]

> I mean what can be exploited via scripting that can harm the user or steal
> his data?

Simple example: an SVG image posted as part of a MySpace (or LiveJournal, or whatever) page that steals other MySpace users' MySpace cookies and sends them to some other server by any of the various means that can be used to send text data (biesi mentioned some, there are others).

The same-domain restrictions of XMLHttpRequest are not so much there to prevent info being sent to a site that wants it, but rather to prevent attacks against web services via sending them XML they do not want and do not expect.

In general, I suggest that anyone planning to comment on this bug take a few hours to read up on the current state of XSS exploits on the web before doing so. It would help make the comments much more constructive.

> CSS is used by the site author and is not meant to harm anybody

Many sites of the sort we're talking about here allow users to upload CSS to style their page.

[Bugzilla-dolphinling (bugzilla-dolphinling)]

Hmm... what about foreignObject? Could it (reasonably, by a human) be implemented so that it would be safe, or would it open social engineering attacks that couldn't be stopped by simply blocking script? I'm thinking here of a full-page SVG with embedded HTML that looks like a login screen, complete with form submitting to the outside. Would it work to just block forms in <img> as well as script? Would that be reasonably doable? If not, would other content types be safe (audio, video)?

Note that some sort of descending into referenced objects to block script will have to be done, as when bug 231179 and bug 272288 are fixed, otherwise one could just include script in the svg-referenced-by-svg. So that descending should also work to block scripts in other file formats. But would that be enough?

[Holger-treebuilder (holger-treebuilder)]

i think a static snapshot image of the svg, with all scripts ignored, coud not
be any more or less secure than any other image format. in the end its all just pixeldata, even the forms in foreignObject. or am i missing something ?

[Leffeman (leffeman)]

The only scripting support I can see a need for in simple images (img and CSS) is simple DOM manipulation (deletion, creation and read-write access to objects, no events). Why not simply block anything else, and not allow the SVG to access anything outside its own document (no cookie access, I can't see an use for it either in simple images)?

For SVG applications that will take user input, ordain the use of the object element.

[Bzbarsky (bzbarsky)]

> Why not simply block anything else

Because that involves making an exhaustive list of "everything else" and adding checks to all of it. It's very very hard to get this right without leaving any holes, and places a burden on implementations of every single DOM method to check for this case.

I'm not really sure what the discussion is about. There's pretty much agreement that SVG in <img> means no script, last I checked. The remaining questions are how to actually best do the rendering.

[Bugzilla-mytsoftware (bugzilla-mytsoftware)]

Being able to display SVG from untrusted sources without the risk of running embedded scripts sounds to me like a good idea in general, and shouldn't be limited to the <img> tag. Maybe some requirement like 'scripted="yes"' could be added to both the <object> and <img> tags.

[peepo (j-chetwynd)]

Mozilla supports SVG natively
could svg code and attachments display inline?

this could be a considerable enhancement for everyone.
But particularly for people with low literacy who prefer illustrations or symbols with their text.

web examples include http://www.peepo.co.uk and http://www.peepo.com

there have been attempts to develop specialist email clients for symbol users in the past.

[Colin Finck (colinfinck)]

If I embed a SVG file from the Tango Icon Library
(http://tango-project.org/releases/tango-icon-theme-0.7.2.tar.gz), which
has been created with Inkscape, it is unresizable in Firefox (tested with
2.0.0.1).

I looked into the SVG file and found that it defines the parameters
'width="48px" height="48px"'.
If I replace these parameters with 'viewBox="0 0 48 48"', the SVG will be
resized correctly under Firefox using the following syntax:

<object data="internet-mail.svg" type="image/svg+xml" style="width: 32px;
height: 32px;" />

Otherwise the image will be cropped.
See the attached example for more details.

I'm not an expert in SVG, so I cannot tell you the best solution here.
But in my opinion, Inkscape should only use the 'viewBox' parameter and
drop the 'width' and 'height' parameters. Otherwise you cannot scale the
created files in Firefox.
Other SVG files I found, for example the feed icon at
http://www.feedicons.com, also use only a 'viewBox' parameter and no
'width' and 'height' parameters. Therefore they scale correctly under
Firefox.

[Horkana-users (horkana-users)]

Originator: NO

Please include a link to the corresponding bug report in Firefox.

The Firefox SVG implementation is far from finished, most definately a
work in progress.
They might be in the process of fixing their implementation to allow
scaling too.
How does Opera or Internet Explorer with the Adobe SVG plugin handle this?

[Toni Ruottu (toni-ruottu)]

I'm experiencing the same problem on Ubuntu 7.04. Please add Ubuntu into the OS field. I don't seem to have permissions required for doing that.

[L. David Baron (dbaron)]

So, is there any reason that this should work other than that some spec says so? Is there a reason it would be useful to authors? Is there a good reason that the spec asks for it other than somebody's idea of theoretical purity? Some use case that it satisifies, that using object doesn't?

SVG, in reality, is a document format, not an image format, and I don't see why we shouldn't just treat it like other document formats.

[L. David Baron (dbaron)]

(I'm asking because fixing this seems like a good bit of work and a good bit of extra security exposure, and doing that requires a good reason.)

[Jwalden+bmo (jwalden+bmo)]

While SVG may in reality have been designed as a document format, its uses in practice are primarily as an image/graphics format, whose natural home in the mind of a web developer has always been in <img>. I don't think you can reasonably fight this intuition, particularly without support from other browsers.

[Fonseca-cs (fonseca-cs)]

Let's look, for example, at the following wikipedia image page:

http://en.wikipedia.org/wiki/Image:Hexahedron.svg

It contains a PNG preview of an SVG image and a link to it. I believe that it would be cleaner if the preview used the svg image itself, and left rendering of the SVG for the web browser.

[Jwalden+bmo (jwalden+bmo)]

(In reply to comment #43)
> I believe that it would be cleaner if the preview used the svg image itself,
> and left rendering of the SVG for the web browser.

It would indeed, but I don't think that's quite the distinction being made.

The question is whether it's worthwhile to support <img> when perfectly adequate support already exists in <iframe>, <object>, etc. with understood and effective security mechanisms in place to prevent the SVG (or any other document format loaded instead) from escaping its prison. (There's no reason Wikipedia couldn't do that now, with Accept or user-agent detection.) Those security mechanisms would have to be modified or reinvented for supporting SVG in <img>, or the document-support code would have to be modified to provide an <img>-style context; implementing either is a decent-sized task with lots of potential for regressions (and security ones, at that).

[Chris Hubick (hubick)]

As a web author who has basically been waiting for this for 6 years now (see bug 70978), and since this blocks bug 231179, I will comment...

I don't author many pages with bar charts or anything where you would put the graphics as actual content of the page... like most authors, I use graphics mainly for logos/themes/styling via CSS image replacement - I write device independent semantic pages, and *all* the style goes in the CSS.

I want to author a *single* web page which will display on both my cell phone browser and my 30" LCD - and right now such a page can only contain text. I can author one version of a page, along with a separate CSS theme for each media type, guessing at suitably sized bitmap images for each type, but this is, simply put, a hack, and a lot of extra work, and can never properly scale for all devices. Without support for referencing SVG graphics from CSS, I can never create a truly device independent theme for my pages without compromising them semantically (which I am not willing to do).

[Dao (dao)]

There's quite a difference between IMG and OBJECT/IFRAME. As with SVG loaded from CSS, IMG should limit graphics to be non-interactive, whereas OBJECT would always support the full set of SVG features (scripting in particular). Intrinsic sizing is another point.

[Dao (dao)]

See also http://blog.vlad1.com/archives/2006/10/07/125/

[Toni Ruottu (toni-ruottu)]

 (a general comment)

 - img -

img-tag is an old design error in html,
reminding us from times when other media types
were not widely used. Sometimes it is very
annoying that only text can be used as
alternative representation. alt-attribute is also
often used for something else than an actual
alternative representation for the idea that the
image is used for. Correct alt for a flag picture
in language selector would be something like...

<img src="fr-flag.png" alt="display the page in french" />

 - object -

While it is possible to use object tag for the
same purpose and thus create greater alternative
representations. It doesn't always work because
of lacking browser support. If img-tags had
never been invented this would of course not
be a problem. Anyway, if a web designer wishes
to go for object tags he can do e.g.

<object data="fr-flag.png">
  display the page in <em>french</em>
</object>

 - xhtml 2 -

When it comes to the future, I think xhtml 2
team has finally dropped img-tag completely.

Iirc the idea is that videos, images, etc.
would be themselves alternative representations
for something. The code would look something
along these lines... (pardon me for not checking
the actual syntax)

<p src="map.png">
Germany is located at the center of Europe.
</p>

In the light of this (imo sane) notation paradigm,
even the object tag is questioned, as it might
be by people as a null-tag just to have some tag
to attach the media to. There are already general
null-tags (div and span) and the question is whether
or not use of object adds any useful semantics.

[Me-martineyles (me-martineyles)]

(In reply to comment #45)
> As a web author who has basically been waiting for this for 6 years now (see
> bug 70978), and since this blocks bug 231179, I will comment...
>
> I don't author many pages with bar charts or anything where you would put the
> graphics as actual content of the page... like most authors, I use graphics
> mainly for logos/themes/styling via CSS image replacement - I write device
> independent semantic pages, and *all* the style goes in the CSS.

<snip>

I agree with the above, I want bug 231179 to be implemented, which is why I want this blocking bug also resolving. Like Chris Hubick, I would like to have svg as background images. Unlike Chris, I would also like to use svg for graphs etc. - however, for this purpose I find the object tag to be appropriate, using something like a table to represent results.

Therefore, I would be happy to drop this bug *IF* 231179 could be achieved a different way that did not require this.

[Me-martineyles (me-martineyles)]

using something like a table to represent results.

should have been

using something like a table to represent results when the svg of the graph cannot be handled, rather than being limited to the img tag's alt keyword and a link to tabulated data.

[codedread (codedread)]

If this means anything - I agree with Martin - SVG as background-image is more important to me than using img

[vonHalenbach (lustik)]

I agree. Inkscape needs to give the user the choice between viewbox and the absolute with and height parameters. I don't think this is very difficult to implement. Bumping the importance up to high.

[amphi (i-launchpad-kaioa-com)]

Will be addressed with the save for web extension.

[Joe-drew (joe-drew)]

This is required for bug 435299, and so it should be on the wanted-1.9.1 list (at least).

[Andreas Schildbach (schildbach)]

I'd like to add that Opera 9.5 supports this properly.
Using <object> as an alternative is not an option, because an object is not sensitive to a surrounding <a> tag (<a href...><object .../></a> is not clickable).

[Brett Zamir (brettz9)]

I wonder if this could also be made to work in XUL, if that's not made inevitable when this may be fixed. For example, it'd be great to have (localizable) SVG available within <toolbar image=>, etc.

[Tim Besard (maleadt)]

Is there any news about this bug? Because I'm looking for a way to make SVG files clickable, and as comment 53 describes: <object> tags doesn't seem to be sensitive to surrounding <a> tags.

[codedread (codedread)]

Questions about this.

I think there is agreement that no scripts will be run in SVG files included with HTML:img elements. But what if you have:

<a href="blah.html"><img src="foo.svg" /></a>

and foo.svg has clickable regions in it (svg:a links of its own). What should happen? What does Opera do? Is the whole region just treated as a rectangular blob of pixels? This would seem to make sense as that is what web developers expect from the HTML <img> tag.

What does the HTML5 spec say?

[Roc-ocallahan (roc-ocallahan)]

The image is treated as a unit. I seem to recall some spec saying this, but I don't know where. Anyway it's the only reasonable thing to do.

[Tomek (tomek-k)]

Hello,

I've investigated how Opera handles the SVG inside <img> tag and I think they do this quite reasonably. If this would be helpful, here is a short summary (when refering to "foo.svg" I mean a "foo.svg" inside HTML img: <img src="foo.svg" />):

-First of all, as already decided about the eventual Firefox implementation - all scripts in "foo.svg" are ignored.

-In response to comment #56 - internal links in "foo.svg" are always ignored, whether <img> is surrounded by <a> or not.

-Animation - of course, scripted animation is not being executed, but the SMIL animation is, so if "foo.svg" contains declarative animation, then it's being animated (in my opinion this is something that web developers would be very glad to see once the bug #216462 is resolved).

-The <svg:image> tag - all images inside "foo.svg" are being rendered, whether this is "bar.png" or "bar.svg". But animations in "bar.svg" are ignored (even the declarative ones). So if "foo.svg" is included using HTML <img> then all internal images are treated as rasters (contrary to the situation when "foo.svg" is included using HTML <object> - then the "bar.svg" is animated, as expected).

[Thomas Holder (speleo3)]

this is not a bug but a feature request. Importance should be "wishlist" rather than "High".

[ccprog (ccprog)]

I'd like to argue that this is, in fact, a bug. It is the central purpose of SVG graphics that it is usable on the web, and especially embeddable in web pages. Therefore, the behavior in case of page embeddings needs to be what web authors expect.

Browsers are not required to rescale graphics that are referenced via an <object> tag, as this element only provides a generic mechanism for calling a rendering agent, which could have no resize mechanism at all. On the other hand, "It is often desirable to specify that a given set of graphics stretch to fit a particular container element." (cited from http://www.w3.org/TR/SVG11/coords.html#ViewBoxAttribute) It is even what everyone would expect. Not providing the needed information to do so is a failure to behave as expected.

Here is a (not completely irrelevant) example: Wikipedia uses literally millions of SVG graphic files. At present, they are rendered server-side to produce scaled versions that can be embedded in the encyclopedia's pages. At least two different sizes are needed: a thumbnail and one that fits the user screen. They are done according to on user preferences.
If ever there is sufficient browser support to think about delivering SVGs directly, resizing is an indispensable requirement. The majority of SVG files on http://commons.wikimedia.org are produced with Inkscape, without viewPort attributes on the root element, with the result that none of them could be used any more. So, what the omittance of the attribute achieved is, that Wikipedia will never be able to switch to full SVG use without abbandoning a major part of its graphic stock.

[lucideer (lucideer)]

I agree with Thomas Holder, I don't see it as a bug in Inkscape, rather a bug in Firefox (listed here: https://bugzilla.mozilla.org/show_bug.cgi?id=276431).

"behavior in case of page embeddings needs to be what web authors expect." - as a web author, I would expect to embed a graphic in the same manner that all (raster) graphics are currently embedded.

[Jayk (jakob-ullmann)]

I agree that it is a bug in Firefox. But it should actually be very easy to implement a corresponding option in the page setup dialog. And Firefox is more than an SVG viewer. This is not the worst problem at time. On the other hand, Inkscape want's to implement the SVG standard. In my opinion, this includes the viewBox element as well as individuality of which element should be used.

[jtakalai (jutakala)]

As I see it, if you say 'width="48px" height="48px"' is your SVG, then it's 48 pixels or nothing. I mean, SVGs and HTML and whatnot should live in the same DOM, it's not like you save a raster image (even though they also have dpi's, but no one really cares about them...), so if you specify a new width and height via CSS, they just replace those and thus the image gets clipped.

I'm not sure what the idea of viewboxes are, but since they seem to define a "viewing region" in the picture's coordinates (even though they are pixels) and not its "width" and "height" in real browser pixels like CSS does, it seems semantically like the option Inkscape should use.

From http://www.w3.org/TR/SVG/coords.html#ViewBoxAttribute:

<quote>
It is often desirable to specify that a given set of graphics stretch to fit a particular container element. The viewBox attribute provides this capability.
All elements that establish a new viewport -- have attribute viewBox. The value of the viewBox attribute is a -- rectangle in user space which should be mapped to the bounds of the viewport established by the given element.
</quote>

this clearly states in my opinion that Inkscape should give the "picture coordinates" in viewBox, and CSS can then specify the width and height in the browser.

-- sigs

[Tomek (tomek-k)]

I've checked also WebKit (527). It behaves the same way as I described in previous comment, except for the last case - if the foo.svg is embedded into HTML using <img> tag, then WebKit doesn't display the internal bar.svg. Perhaps it's a bug, because bar.svg is being displayed (and animated) if foo.svg is embedded using <object> tag.

However, I've also repeated the tests in Opera, and this time the bar.svg is being animated (SMIL, of course) even if foo.svg is embedded using <img> tag. Don't know, maybe the last time I was checking I made some mistake, but I'm pretty sure that the bar.svg is being animated in both cases (foo.svg embedded using both <img> and <object>). Checked with Opera 9.50 and 9.60.

And there's a weird thing in Opera 10 beta: also in the last case, in this version of Opera, bar.svg is not being animated at all (neither for foo.svg in <img> nor for foo.svg in <object>). Maybe it's a bug, but maybe they decided to change the behaviour for some reason?

So summarizing, Opera and WebKit behave the same way for cases 1, 2 and 3, as described in comment #58. For case 4, Opera (9.5, 9.6) does animate the bar.svg embedded in foo.svg (using <svg:image>) in all cases (foo.svg in <img> and in <object>). However, Opera 10 beta does not. As for WebKit, it has problem with displaying the bar.svg when foo.svg is embedded using <img>, but for foo.svg in <object> everything works fine (the animation also).

Hope I didn't complicate it too much;)

[Tomek (tomek-k)]

Created an attachment (id=392530)
testcases for comments 58 and 59

attached testcases that I used to check what's described in comments 58 and 59. It consists of an html file and several svg files, thus I've put it into an archive.

[lucideer (lucideer)]

To add to my comment above, it seems this also affects setting SVGs as CSS background images as they behave in a slightly similar way to object (displaying the image actual size rather than resizing to fit the bounding box) - testing in Opera this is particularly apparent when zooming a page with SVG CSS background images lacking viewBox.

Adding the viewBox attribute does seem to suit the use of SVGs in CSS a lot more than the fixed height and width does as far as I can tell.

[Roc-ocallahan (roc-ocallahan)]

Not making it.

[Adeveria (adeveria)]

Does "Not making it" mean it won't be in 1.9.2a1 (the target milestone) or is the feature not expected to make it for 1.9.2 at all?

[Joe-drew (joe-drew)]

This will not make it for 1.9.2.

[worms_x (wormsxulla)]

Would it be possible to know, roughly, what prevented this bug, together with Bug 231179 and Bug 272288, to make it in 1.9.2, as we were expecting it so much, and when would its new estimated time of implementation be, if it's already known?

Thank you!

[Joe-drew (joe-drew)]

The changes in bug 753 and bug 435296 were being made at the time that svg-in-img development would have been happening, and the two pieces of work would conflict with each other (or, more specifically, depend on each other), so we opted to delay implementation until the other imagelib work was done.

[Stefan Roettger (stefan-stereofx)]

I have the same problem with Firefox. I've read the according bug report on mozilla bugtracker relating to html:img not supporting svgs and it does not look like it is going to be solved anytime soon. With Safari svg images work flawless and I can rescale them to any size. With Firefox I have to use embed or object which does not provide scaling of svg images with the output as is currently produced by Inkscape.

So my suggestion is as simple as this (sorry if this has been suggested already in a different post):

Provide something like a checkbox in the Inkscape preferences that when enabled writes an additional viewbox tag into the svg file with the viewbox corresponding to the actual document size.

I've simulated this by hand by adding "viewBox='0 0 500 500'" to my svg file, for example. With that the svg does display and scale nicely in both Safari and Firefox and it is scalabe by setting the width attribute of the embedding object, e.g. <object width=100 data=file.svg />.

Without the viewBox tag I get the ugly scroll bars when I resize the embedding object. That's not exactly the behavior I would expect of a __Scalable__ Vector Graphics. Without the viewBox tag, the Inkscape output is merely a VG without the S, which makes a vector graphic basically useless.

So in summary, I do propose a "Make viewbox fit document" checkbox by exporting the corresponding viewBox tag!

Sure, I can add the tag by hand, but it is sooooo essential for a vector graphic to be scalable and such a checkbox would be soooooooo nice and easy to implement, not even a GUI required ;-)

Thanks,
Stefan Roettger, www.stereofx.org

[jazzynico (jazzynico)]

Inkscape 0.47 provides an Optimized SVG output (in File>Save as) which already replace the Height and Width attributes with a viewbox. Do we need to implement viewbox directly in Inkscape SVG output, or can we consider that this extension fixes this issue?

[ccprog (ccprog)]

This only replaces one problem with another. Optimized output provides no absolute height and width, which poses problems with a number of renderers when trying to display the svg file as a standalone. For example, page scaling in most Browsers will not work any longer.

From my viewpoint it would be clearly preferable to have a checkbox in the document preferences, or even two, stating "set page size/set viewbox size", so authors have full control.

[Martin Owens (doctormo)]

~ccprog - Are there any drawbacks to saving all svg files with viewbox _and_ height and width attributes?

[ccprog (ccprog)]

Luckily, browser support for svg has greatly improved since 2010...

The rules for the establishments of an initial viewport in http://www.w3.org/TR/SVG11/coords.html#ViewportSpace are fairly clear: if an embedding document sets width and height properties, stated values on the outermost svg element are overwritten. On the other hand, without viewBox, no size transformation can be applied to the content.

Modern browsers implement this (with minor discrepancies, but these fall into their own realm), so there is no longer a problem with always stating both viewBox and width/height.

[Matthew Petroff (matthewpetroff)]

Fixed in r12557.