March 15th, 2008

I've now mapped out a plan for moving forward on the organization of my site, including which tools to use, where and even some preliminary designs. I've also played around more with incorporating SVG into a site design, as well as trying out some of the newer CSS3 design attributes. I'm finding out that one can have one's cake and eat it to.

For instance, you can use SVG for a site design, and the site doesn't have to look either plain or ugly with IE–just different. If you're comfortable with different, this isn't a bad way to move forward with the more advanced browsers, such as Firefox/Gecko, Opera, and Safari/Webkit (the Big Three), while still accounting for a more primitive browser like IE.

Right now, today, at Realtech I have an experimental design up called "World War", featuring both a photo from an air show, as well as three different SVG images. Only the photo shows with IE, but rather than have a completely white page, I added a background color and repeating background pattern, both of which are overlayed by the SVG 'background' image that the Big Three can see.

This is where it gets a little tricky. The SVG element supports both a width and a height attribute. If you specify the width and height in the element as SVG attributes, not in the CSS style attribute, Internet Explorer ignores both, which means the SVG element takes up no page space in IE.

ie2

However, the Big Three understand that width and height are supported attributes for SVG container elements, like the SVG element, itself. All three support the width and height setting directly in the SVG element. Not only that, but both Safari and Opera get a bit snitty if you don't use these attributes and instead set the width and height using CSS, only.

Bb's RealTech

The end result of this mechanization is that the Big Three see the SVG images and override the background image and background color. True, they still load the background image, but since it's so tiny, it's not a significant load on the server or client. Best of all: no conditional references have to be used, either in HTML, CSS, or JavaScript. If IE were ever to support SVG someday, the browser would then process the SVG just like the Big Three.

I continued this concept into using some CSS3 attributes. CSS 2.1 provides the meat of web page design, but CSS3 is the desert, and what's a good meal without desert?

I use the rgba color function when setting the background color for both my sidebar and my article title bars. The rgba function takes four parameters: the three decimal values, in a range from 0 to 255, for the red, green, and blue channels, respectively, and a fourth representing the alpha channel. The alpha channel is what controls the transparency. Using the rgba function allows us to create semi-transparent backgrounds.

I could use a variation of opacity setting, including the CSS3 opacity attribute, as well as the older moz-opacity, filter, thing. However, the opacity settings effect the opacity of the element on which it is set and any child elements. Using the rgba function for the background-color creates a semi-transparent background for the element on which it is set, but has no impact on the child elements. (For more on opacity and rgba, see A brief introduction to Opacity and RGBA.)

What about a gracefully degrading design? For user agents that don't support rgba, what I've found is that we can specify a background color using non-rgba functionality:

.sidebar
{

background-color: #fff;
background-color: rgba(255,255,255,0.8);
}

Either the agent will pick up the non-rgba background color, or it won't pick up any background color at all. In the latter case, the behavior that the browser demonstrates is that it recognizes a supported CSS attribute (background-color), but not the value (rgba). Therefore it flushes the previously set background color, but doesn't apply the new background color.

(I believe the former behavior is the correct, while the latter behavior is the incorrect. If you any input on this, please leave a note in comments.)

Combined, these two CSS background-color attribute settings result in the following: the sidebar and the inner panel background are both semi-transparent with Safari and Firefox, which support rgba; Opera doesn't currently support rgba, but will pick up the earlier, solid white background-color; IE doesn't pick up any background color, and both items are transparent.

Bb's RealTech

Another CSS3 attribute I use that gracefully degrades is the new text-shadow attribute. With text-shadow, I can add shadow to text, such as the title in the page header. If the browser supports the text-shadow attribute, the shadow displays; otherwise, no shadow.

Bb's RealTech

The text-shadow attribute takes four parameters: the color of the shadow, the x coordinate of the shadow as it relates to the original element; the y coordinate; the radius of the applied blur. I currently have the following text-shadow attribute setting on my main title:

text-shadow: #333 2px 2px 4px;

This CSS setting creates a dark gray shadow, offset 2 pixels to the right and bottom of my current text, with a blur radius of 4 pixels–a relatively soft shadow. The shadow shows with Opera and with Safari, though not with Firefox or IE. As long as no dependency is placed on the shadow (i.e. text the same color of the background, depending on the shadow to make the text show), the look degrades gracefully for browsers that don't, currently, support text-shadow.

Bb_s RealTech-3
Uploaded with plasq's Skitch!

Best of all, when the text-shadow attribute is eventually supported by a browser, the shadow is displayed without any further intervention or modification of the page design. All you have to do to is accept that a page will look different in different browsers. Not "bad", different. If you're willing to live with "different", you can have a lot of fun now with new design elements.

Comments
1
Bud Gibson - 7:37 pm March 15, 2008

This post was GREAT.

I'm in FF3 b4 and not getting World War which looks neat. It seems like that experiment might be over.

When you talk about Safari, are you referring to Webkit nightly or the latest shipping version. It seems like some things might be more the nightly. I will note that the background svg on burningbird.net seems to be killing performance on the shipping version.

2
Doug Alder - 7:47 pm March 15, 2008

Using FF 2.00.12
I see the planes but the black line graphic behind them shows at the bottom of the plane graphic. Not seeing any shadows

3
Shelley - 7:56 pm March 15, 2008

I turned it back on Bud so you could see it. I don't plan on using any SVG theme until Firefox 3 releases. Firefox 2.x has some real rendering problems.

Doug, Firefox doesn't support the text-shadow.

I was using a large, complex SVG file at Burningbird. I've downgraded it, so it's faster, but not as pretty. That was an image that works very well for not maintaining aspect ratio.

For the one running at Realtech this weekend, I maintained aspect ratio on the background image.

4
Shelley - 7:57 pm March 15, 2008

PS Thanks for the compliment on the writing, Bud!

5
Bud Gibson - 8:19 pm March 15, 2008

I'm getting the World War theme and like it. I particularly enjoy the airplane outline. I agree that the degraded image on the main site maintains its aspect ratio well. In FF3 b4, it was still a little slow.

If you think about it, anything that requires dynamic image recalculation is going to be a performance hit. I can only imagine what some of these effects would do to machines of the late 90's. Simplifying the image is going to help, but you will eventually always hit a performance wall.

Any thoughts on svg performance? That could make a good post. Has anyone produced an svg mashup?

Finally, I'll note that I tried to edit my previous comment to add a question mark and was sent to a 404 page. It's not a big deal; I just saw that I had asked a question without a question mark.

6
Shelley - 9:12 pm March 15, 2008

That's an extremely large and complex SVG–it's going to be slow. Think of a JPEG that's the same size, and you'll find the same amount of slowness.

So, no, using SVG doesn't have to be a performance hit, any more than a raster image. I'm just trying to play around.

The reason I didn't want to keep this design up, is that it's a copy from the Burningbird site, and has links coded to the Burningbird location. That's why the comment editing gave you a 404.

7
Bud Gibson - 7:02 am March 16, 2008

Interesting that an svg would have no worse performance characteristics than a jpg.

8
Shelley - 2:32 pm March 16, 2008

It's really dependent on the type of SVG, how complex the drawing, the number of gradients used, the original size of the SVG, the size of the display, the optimization used with the JPEG, the circumstances, etc.

Those are all good questions, Bud, and deserve a longer answer than I have time for at the moment. As soon as the site re-org is finished, not to mention the XHTML stuff I've promised, answering your questions will be my first posting.

I did remove all but the simplest SVG background at Burningbird. Firefox 2.x really chokes on anything but the simplest SVG for a background. Luckily, I believe that Firefox 3 is due out in a month or so. Also luckily, Firefox makes upgrading simple.

9
Bud Gibson - 5:31 pm March 16, 2008

Shelley, I for one appreciate your reporting on your tech explorations. We've been taking a standards-based approach in my intro web and capstone courses. The idea of images you could script seems pretty cool, for instance real time data displays where you just add an element to a graph vs. having to replot everything. As a PhD student at Carnegie Mellon in the early through mid 90's, I was aware of html from the beginning. Things have come a long way.

Thanks to all those who have contributed to the discussion. Comments are now closed, but you can contact the author of the post directly.