Closed Bug 231179 Opened 21 years ago Closed 14 years ago

SVG images in CSS

Categories

(Core :: SVG, enhancement, P2)

enhancement

Tracking

()

RESOLVED FIXED
mozilla1.9.2a1

People

(Reporter: blue_prawn, Assigned: dholbert)

References

(Blocks 1 open bug, )

Details

(Whiteboard: parity-opera [personas-needs] [evang-wanted])

Attachments

(7 files)

User-Agent:       Mozilla/5.0 (compatible; Konqueror/3.1; Linux)
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031217

PNG, JPEG and GIF images are rendered in CSS, but not the SVG images. 
 
With this feature, it could be possible to reduce a lot the weight of the web pages! 
(and in particular for the big background image because today people have bigger screens, 
so web pages are bigger) 
 
For exemple, this works: 
background: #8AC url(image.png); 
But this does not work: 
background: #8AC url(image.svg); 
 

Reproducible: Always

Steps to Reproduce:
1.
2.
3.


Expected Results:  
Have the same CSS, but with weight far more lower.
I trust you're using a SVG-enabled Mozilla ?
> I trust you're using a SVG-enabled Mozilla ? 
 
of course :p 
Status: UNCONFIRMED → NEW
Ever confirmed: true
It can also be widely used in chrome.
We could theme Mozilla/Firefox using scalable graphics as alternatives via XUL +
CSS styling mechanism, which would change the size of icons everywhere.
(In reply to comment #3) 
> It can also be widely used in chrome. 
> We could theme Mozilla/Firefox using scalable graphics as alternatives via XUL + 
> CSS styling mechanism, which would change the size of icons everywhere. 
 
It could even be recursive in a way : 
style-a.css could use image-a.svg for big backgrounds and graphics, 
and image-a.svg could call style-a.css back to unify colors with the web page. 
> With this feature, it could be possible to reduce a lot the weight of the web pages!  
> (and in particular for the big background image because today people have bigger 
> screens, so web pages are bigger)  
>   
> For exemple, this works:  
> background: #8AC url(image.png);  
> But this does not work:  
> background: #8AC url(image.svg);  
 
 
From my point of view the _perfect_ exemple of what could be done with SVG in CSS is this 
: 
http://www.csszengarden.com/?cssfile=/051/051.css 
(here svg is not used because Mozilla** nor IE are able to load SVG images from CSS!) 
**{even the svg enable one} 
 
 
Mass reassign of SVG bugs that aren't currently being worked on by Alex to
general@svg.bugs. If you think someone should be assigned to your bug you can
join the #svg channel on mozilla.org's IRC server ( irc://irc.mozilla.org/svg )
where you can try to convince one of the SVG hackers to work on it. We aren't
always there, so if you don't get a response straight away please try again later. 
Assignee: alex → general
Depends on: 276431
I could see this having declaretive animation - a fade in, or comming from the
side and bouncing or something, although at the moment it's just static
I also find this with 1.5 beta 1 in windows (could the owner change linux to all
in the OS box). I would find it particularly good to put it as the background to
a:hover (with the svg containing declarative animation), to create some nice
flash-like effects when links are hovered over, whilst keeping the markup nice
and clean and accesible (unlike flash).

I've attached a couple of files, which demonstrate how I think it could be useful.

Oh, if anyone has another way of acheiving this effect I'd love to hear it. :-)

Thanks,
    Martin
*** Bug 316257 has been marked as a duplicate of this bug. ***
*** Bug 319267 has been marked as a duplicate of this bug. ***
OS: Linux → All
Hardware: PC → All
Attached image SVG no. 1 for test-case
Attached image SVG no. 2 for test-case
Attached image SVG no. 3 for test-case
Attached file Zajec's SVG text
Test-case that checks support for SVG in CSS's background.
SVG backgrounds would be complemented with CSS3 background-size.
Whiteboard: parity-opera
This bug doesn't really depend on bug 276431.
The discussion on bug 276431 also shows that while some people are reluctant to support SVG in img tags, they're not reluctant to support it for background images.

I therefore suggest those two bugs become independent.
Just want to point out that with FF3s zoom feature svg becomes especially attractive for creating more seamlessly scalable interfaces. Especially where there are many icons used.

With no ability to scale images in css creating oversized images and scaling them down is not a possible short term option.
You can set the size of the image in SVG, so there is no reason not to implement this feature. You don't need to wait for everything. Just implement it. :)
this is my #1 svg bug, because it's the #1 place I want to use svg, is there any way this could make it into 3.1?
"Firefox 3.1 Meeting Minutes: 2008-08-05" at http://blog.mozilla.com/meeting-notes/archives/30 says "SVG image decoding - CUT", which I assume refers to bug 276431 blocking this one :(
Flags: blocking1.9.2+
Priority: -- → P2
Assignee: general → nobody
QA Contact: general
Assignee: nobody → roc
Target Milestone: --- → mozilla1.9.2a1
Whiteboard: parity-opera → parity-opera [personas-needs]
Not making it.
Flags: blocking1.9.2+ → blocking1.9.2-
Would it be possible to know, roughly, what prevented this bug, together with Bug 272288 and Bug 276431, 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!
According to the IE blog [1], SVG images in CSS is planned for IE9. It is also already supported (though not as well as in Opera) in Safari and Chrome, so I really think it's time Mozilla starts prioritizing this. 

[1] http://blogs.msdn.com/ie/archive/2010/03/18/svg-in-ie9-roadmap.aspx
While the current version of Safari does not pass the "Zajec's SVG text" test, the current version of the WebKit nightly does.  So this will also become parity-safari at some point.
Whiteboard: parity-opera [personas-needs] → parity-opera [personas-needs] [evang-wanted]
Safari 5 has now been released and passes the "Zajec's SVG text" test.
https://developer.mozilla.org/en/Firefox_4_for_developers says Firefox 4 will support SVG in CSS background images.  I guess that is not the case, though, since this bug hasn't seen activity for a while?

/me rasterizes some PNG fallback
dholbert actually has working patches in bug 276431. They're pretty close to done.
(Those patches make us support SVG everywhere we support images ... <img>, CSS, favicons, etc)
Oh, sweet!
Should I file a new bug for the following test ?

http://ie.microsoft.com/testdrive/Graphics/SpaceInvader/Default.html
Nope - that demo already works with my patches for bug 276431. (I just tested it.)
bug 276431 just landed, including reftests for using SVG as a CSS background and a list-style-image. Woot! :)

I wouldn't be surprised if there are edge cases (particularly with -moz-background-*) where we need a few tweaks to get the desired behavior, though.  I'm leaving this open until we've more rigorously exercised SVG with CSS properties, fixed anything that's not quite right, and added more reftests.
Assignee: roc → dholbert
Status: NEW → ASSIGNED
can we also use internal svg images via id tags?
(like it is done when using css filters for html elements: http://weblogs.mozillazine.org/roc/archives/2008/06/applying_svg_ef.html )
Not directly from this bug.  But you could use -moz-element to do that:
  http://hacks.mozilla.org/2010/08/mozelement/
Depends on: 600574
Depends on: 601470
No longer depends on: 601470
That (the -moz-element approach) doesn't do what I was expecting.  I'm not sure if this is what flying sheep was driving at but here's what I'd like to do:  I have a single SVG file, background-images.svg, which contains multiple shapes each with IDs.  Then in the CSS have something like:

header { background-image: url(background-images.svg#circle); }
footer { background-image: url(background-images.svg#rect); }

Where #circle and #rect reference individual shapes within the file.  Essentially a CSS Sprites approach except without having to worry about all that clipping and positioning.  Is this in any way feasible?
Not at the moment, no.  But as I alluded to in Comment 37, you should be able to get a similar effect with moz-element if you directly define those elements (e.g. #circle) in an <svg> block in the same document where you use them, though.  (That doesn't give you the same file-separation as the technique you're suggesting, but it's something.)

In any case, this is beyond the scope of this bug -- further discussion on this point should probably go on a newsgroup like http://groups.google.com/group/mozilla.dev.tech.svg/
that would be a cool syntax:

url(s.svg) means an external svg picture,
url(#boo) means an inline-svg in the current document,
url(x.xml#boo) means a inline-svg in an external xml document.

since svg is a xml format, you can specify svg pictures inside other svg pictures which would provide the functionality rob was asking for.

should i file an enhancement request for this?
It's doable. However, the SVG working group hasn't decided how such references should behave. There's an old SVG 1.2 draft here:
http://www.w3.org/TR/SVGTiny12/linking.html#LinksIntoSVG
which makes such references translate the element into view rather than rendering it as an isolated image.

I suggest bringing this up in www-svg.
1. what is www-svg? a chatroom? a webpage? a usenet-group?
2. mozilla.dev.tech.svg is hopelessly flooded with spam.
Daniel, sorry if I didn't make it clear in my first comment: I tried -moz-element and it didn't work - ie. I inlined my SVG document (HTML5 doctype), put IDs in each shape in the the SVG and then tried to use -moz-element to access them directly as backgrounds on different elements.
You need to put each SVG shape in its own <svg> subtree which is a child of HTML content. Then refer to the <svg> subtree.
shouldn't this bug be a blocker for 2.0?
Daniel, why can't we just mark this FIXED?
because it's not fixed, maybe?
try add an SVG element by CSS with base64 encode. I mean with pure CSS, without HTML.
I left it open per comment 35, but that was probably silly.  Since SVG images in CSS generally works now, images it's probably cleaner to follow this fixed and file followups (like bug 597778) on individual issues.
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
er s/follow this fixed/mark this fixed/

(In reply to comment #48)
> try add an SVG element by CSS with base64 encode. I mean with pure CSS, without
> HTML.

That works for me (see attachment), but maybe I misunderstand you.  Can you file a followup bug? (or at least post an attachment / a link to a broken example, so I can see what you mean?)
It's possible 1luvm0z1l4 is referring to data URL with gradients or use elements not working properly due to bug 308590. 

I suspect that bug will become a bigger issue now people can use SVGs in <img> or CSS backgrounds and will expect the base64 versions to work the same...
(In reply to comment #51)
> It's possible 1luvm0z1l4 is referring to data URL with gradients or use
> elements not working properly due to bug 308590. 

Oh, you are right. My testcase was based on SVG with filters and it doesn't work if used by CSS as data:URL(base64-encoded-file).

I just thought that keeping that keeping this bug as meta for all SVG via CSS bugs would be useful, and it should stay unfixed until all dependent bugs got fixed.
(In reply to comment #52)
> I just thought that keeping that keeping this bug as meta for all SVG via CSS
> bugs would be useful, and it should stay unfixed until all dependent bugs got
> fixed.

That was sort of my intention in Comment 35. But I don't think that's really useful at this point because
 (a) this bug has too many comments / too long of a history to be used effectively as a metabug
 (b) I think mozilla generally avoids blocking on metabugs -- but we can just as easily block (or not block, as the case may be, depending on severity) on individual "this still doesn't work yet" issues with SVG images in CSS.
(In reply to comment #53)
>  (a) this bug has too many comments / too long of a history to be used
> effectively as a metabug

or rather, "to be converted into a metabug at this point"
You need to log in before you can comment on or make changes to this bug.