5

Edit:

How can I detect in php if the client browser is capable of displaying SVG as CSS background ?

I renamed my stylesheet from .css to .css.php. So I can include at the beginning:

<?php
header("content-type: text/css");
?>

and somewhere in the middle

<?php
 if (stristr($_SERVER["HTTP_ACCEPT"], "image/xml+svg"))
 {
 }
 else
 {
 }
?>

Unfortunately, my firefox client does not send out any image/xml+svg string to the server. So, how can I detect if a browser is capable of displaying SVG as CSS background in php ?

Ref: http://www.gabis-bloghaeuschen.de/2006/03/27/php-code-in-der-css-datei/

End Edit.


I experienced (except the few most recent webbrowser) not much of any other webbrowser is capable of displaying an .svg image from withing a .css with the aid of url().

Using the embed tag and its pluginspage attribute, there is the possibility to refer a client to a missing plugin:

<embed src="/svg/simple-example-1.jsp"
       width="300" height="220"
       type="image/svg+xml"
       pluginspage="http://www.adobe.com/svg/viewer/install/" />

Since the adobe plugin is outdated, one can also refer to the corel svg viewer.

What is the best strategy to deal with old browsers ? Is there a mechanism to refer them to a plugin if the .svg image is included from within a .css ?

edit:

#header {
 width: 760px;
 height: 288px;
 margin: 0 auto;
 background: url(images/background.svg) no-repeat right top;
}

How to refer browsers, not able to handle the code above, at least to third party aid, e.g. a plugin ? (Or maybe a .png - but actually, that is not what I want.)

What other possibilities are there to deal with browsers that can't handle svg in stylesheet ?

Iceweasel is able to display background.svg directly but can't display the image if included by style - so apprently it is able to handle svg, but not from within a stylesheet ?

With browsershots I realized, most browsers were not displaying the image in the stylesheet because of it being in Scalable Vector Graphics AND in the stylesheet. So the question is, what is the best strategy here to reach as much viewers as possible with the svg and only use the raster images in emergency ?

Ref: http://tutorials.jenkov.com/svg/displaying-svg-in-web-browsers.html

2
  • What exactly are you doing with your CSS? Displaying the SVG as a background-image? If so, how would a UI for referring them to a plugin work? Aug 31, 2011 at 12:20
  • I don't know - maybe a placeholder with a link saying "you can't display svg images for some reason, do you want to load the raster images or install the svg viewer plugin?" It is kind of a pain since noone wants to invest any time for displaying the style of a website correctly if it doesn't convey any information - so I'm a bit helpless here - should I just add a footer "this site is best displayed with xyz browser" ?
    – panny
    Aug 31, 2011 at 13:01

1 Answer 1

4

Backgrounds are meant to be backgrounds. They're not meant to support interaction.

Your options would seem to be:

1. Do it in HTML rather than CSS.

2. Have your server return different content according to the User-Agent string.

3. If your SVG is rectangular and opaque, you can do fallbacks as

background-image: url(fallback.png);
background-image: none, url(real.svg), url(fallback.png);

4. Forget about Firefox pre-v4 and IE pre-v9. (ref)

5. Use Modernizr and use inlinesvg as a proxy for support for SVG backgrounds. (Note: this doesn't require two versions of the site: just a JS dependency and an extra line of CSS).

6. There may be some approach using JavaScript to provide a more complex fallback.

2
  • This sounds like there is no way around javascript since to parse the User-Agent string alone there needs to be some logic ? The image is opaque but the fallback solution is not optimal since the edges of the image in the raster picture are blurry and "shine" like an eclipse from behind the svg which is definitely not what I want. So in essence, I need to create two versions of the web page ? one real and one fallback ?
    – panny
    Aug 31, 2011 at 15:32
  • 1
    @panny, the User-Agent handling logic would be on the server, so (unless you favour Node.js) it wouldn't be JavaScript but PHP/Ruby/Perl/ASP/Java. Aug 31, 2011 at 15:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.