March 28th, 2008

Now, this is what I hoped to see when the Acid3 test was first announced. Not the macho posturing I saw yesterday.

The WebKit folks published a writing at the Surfin' Safari site that details the challenges met by Cameron McCormack associated with the last test. To me, the story is a fascinating look into browser development. I hope we can see something similar from Opera about that organization's own effort.

I particularly like, and want to highlight, the writing at the end of the post:

Web standards can often seem boring compared to super fast performace, whizzy new features, and even the basic Web compatibility work of making sites work properly. Interoperability is critical to the Web as an open platform, but it can be difficult to explain to regular users why it’s so important. The Acid tests make web standards fun, for browser developers, for Web designers, and for regular users. Whatever the intrinsic value of the tests may be, I think we should all thank Ian Hickson and all the test contributors.

I’d also like to thank Opera for giving us some serious competition and making this a real horse race. We have huge respect for their developers and all the work they do on Web standards.

As for Firefox 3 not "passing" the Acid3 test, I'd rather hear Firefox explain its future development goals such as when it plans on incorporating SVG animation and text-shadow and the like, than having to worry about the test. The test brought about awareness. We're aware. Now, let's move on.

It's with relief that I can now say congratulations sans any reservations to WebKit/Safari and Opera. Below is my first 100/100 snapshot, using the WebKit nightly on my PC.

safari100

update

And Opera's result, using the special Windows build:

opera100
Uploaded with plasq's Skitch!

(via Anne, who hasn't quite decided to move on from yesterday's querulousness, albeit defense of a friend is noble.)

March 26th, 2008

I was quite pleased to see all of the activity related to SVG in the HTML5 working group's public email list. I agree with those who say that HTML5 needs to be able to work with any unknown vocabulary via namespaces, rather than try to coerce a HTMLized version of SVG and MathML. A case in point is the vocabulary items providing metadata information about the image that Inkscape puts into SVG documents. Creative Commons, Dublin Core, its own stuff–Inkscape believes in metadata.

In the meantime, I will continue using XHTML with my SVG design integration. I was momentarily peeved about the repetition of the "draconian" error handling of XHTML every time anyone even mentions the topic. However, I've since decided that rather than be peeved, I should feel flattered. According to the people who talk about the "draconian" nature of XHTML, I must then be some kind of superwoman to be able to support it. Hey, go me.

Burningbird currently demonstrates my new philosophy of design, though not necessarily using a specific design I will keep–though it is bright and cheerful in a "Horton Hears a Who" way, and I need bright and cheerful with all the rain and flooding we're having. As I've mentioned in a couple of earlier posts, the site uses a relatively simple SVG image as flexible background, in addition to other SVG for decorative accents. For IE or other user agents that can't process SVG, I provide a tiny repeating blue striped background, so that they don't get a plain page. Different but decent.

different

Though I use the rgba function to set the semi-transparent background of the center column and sidebar, I first define a background color using hex notation:


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

Browsers that don't support the rgba function yet will pick up the hex notation, getting a nice coordinated blue center column, with white for content and sidebar; otherwise, they'll pick up the rgba notation, with a completely transparent center column, and semi-transparent sidebar and entry area.

Safari and Firefox support rgba, but Opera doesn't at the moment (it most likely will in the next beta release). However, again the design is such that it degrades gracefully and looks decent even without support for this CSS3 color module attribute. Or I think it looks decent, though lord knows I'm not a web designer. Let's say my use of the technology is sound, but my design sense may suck, depending on your perspective.

Burningbird

I've also implemented text-shadow, in this weblog and at Burningbird. The sub-headings have a very tiny text-shadow, which really makes the text pop out nicely:


        text-shadow: #ccc 1px 1px 2px;

Opera and Safari both support text-shadow, but there's no adverse impact with browsers that don't. It adds a nice polish, but that's all it is, polish. I really like it, though, and can't wait until Firefox implements it.

All in all, Safari is currently the browser with the most advanced support for my design concepts, with Firefox a close second.

Burningbird
Burningbird
Uploaded with plasq's Skitch!

Another interesting point on the design is the flexibility as to scale. The background scales large for larger monitors, but the entire content will resize based on browser window size, as well as font size and resolution. If you resize the window small enough, the sidebar pushes to the bottom. This is not a bug–the sidebar gets pushed out of the way when the web page is accessed by a smaller device, such as an iPhone. It's still there, but not taking up valuable real estate.

Window

In fact, the photo and the bright yellow box currently showing also demonstrate the scaling–the yellow box is a SVG element that is constrained to size to the parent container, but preserve aspect ratio; the photo will display at its maximum width, but scale down as the window scales. All in all, the site can scale to an infinite width or down to a minimum 40em in width, and still be readable. The site even works with my Kindle, either using the mobile CSS, or when using the Kindle's advanced web browsing, the scaled down width and the blue stripe background (though in gray tones, of course).

Best of all, you can zoom the text and the whole site zooms out, so that the words per line length is consistent.

Burningbird
Uploaded with plasq's Skitch!

That's the key to my site designs in the future–not trying to get the sites to look the same in all devices, but looking good for each. Or at least good enough while still giving me the opportunity to try out new technologies. We've fixated too much in the past on making sure a site looks "the same" in all browsers. We've crippled our creativity trying to make sites look "the same" in all browsers. This was someone's anal design "rule" set out long ago, and it's time we toss the bugger aside.

I promised Bud a writing on SVG and performance, especially as compared to raster images (such as PNG, JPEG, and GIF). I actually checked out the WebKit code to see how it manages graphics, and was surprised at how easy I was able to follow the code considering that I haven't worked with C++ since my old Windows programming days. The WebKit code is well organized and documented, with a minimum of tricksy coding. It really is an excellent product–not the least of which that it will probably be the first browser to pass Acid3. It or Opera, they're both very close.

Anyway, the writing will be coming after my site redesign, after I finish proofs, after I get the next book started, but I wanted to quickly mention my discovery, in the course of my explorations, how committed Apple is to the use of SVG–in browser and out–because of the scalability. Think of it: if you have a desktop icon that you want to look good in a tiny screen, as well as a monster 60 inch television, would you want to use raster images? Of course not. OK, then, would you want to invent a graphics format, or use one that already has extensive tool support, as well as earning you brownie points with the development and open source communities?

*beep* time's up

Apple chose wisely. Still, I was surprised at the strength of commitment Apple has to the integration of SVG into its products. And this despite HTML5 disapproval. Hey, go fruit.

Update Opera is stating they've reached 100/100 on Acid3. Congratulations Opera! Can't wait to get my hands on a working tech preview. When I do, I'll run it against the *Firefox Minefield edition, and the latest WebKit build and we'll see how they're all doing. The real test is getting 100/100 with a publicly accessible browser version.

I will declare a winner in my Acid3 races once I've seen the 100/100 with my own little eyeballs. Being as I'm superwoman and all.

*Oh, and IE8, too.

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.