Burningbird

With the growing support for CSS3 in most of the major browsers, including Firefox, Safari, Opera, and now Chrome, I decided to incorporate the use of CSS3 properties into my own site designs. In addition, I also used an SVG graphic whenever I wanted a background that sized with the page.

The CSS3 properties I'm most interested in are text-shadow, box-shadow, border-radius, border-image, in addition to support for RGBA opacity. No more having to use kluge methods to add curved corners, or shadow text; no more stretched transparent PNGs, or layered DIV elements in order to provide border images. Though not all browsers support all of the properties, as long as we use the effects carefully, the designs should degrade, nicely.

Read on for the details.

While I appreciate Mark Pilgrim's This week in HTML5 land weekly reports, there's one underlying thread that occurs every month that Mark doesn't necessarily touch on: the issue of distributed extensibility. You know, the namespace, XHTML, SVG and MathML et al thing that doesn't go away.

For instance, catching up on my HTML5 Working Group public archives reading, I found this gem from Chris Wilson of Microsoft:

You are correct, we cannot definitively say why XHTML has not been successful on the Web. However, I do believe that part of that lack of success is due to the less-forgiving XML syntax, and part of it is due to the degradation story (or lack thereof) in browsers and versions that don't support it. (I don't want to turn this into a pro/con XML debate either.) Part of its success in the future will be due to the important and focus it is lent by all of the major browsers. Perhaps I am misreading the tea leaves; I don't see much interest in XHTML's future from the other browsers. I do think XHTML would have a lot of positives as a basis; however, it does have a few negatives, and it would need to be a universal push if it were to be successful.

I would say that we can definitively state why XHTML has had limited success on the web: lack of implementation and support in IE, one of the web's major browsers. In addition, none of the other browsers have said that they aren't interested in supporting XHTML in the future. The fact that Microsoft's main IE architect would make this statement leads me to believe he should be in politics.

And I'm only up to August in the archives. What other delights await in September and October...

Lars Gunther at WaSP just posted an article on ACID3 and what it really means. Though Webkit may be the first truly out the door, what's really important is playing the game:

In the end the winner is neither Webkit, Opera, Mozilla nor Microsoft, but developers who get more powerful features to work with and more consistency between browsers. And that means that in the long run they are able to focus on user experience, not browser shortcomings. This means that the true winner of Acid3 is anybody who surfs the web.

He also goes on to mention that ACID3 is really only one test, and there are others that test individual components, such as support for JavaScript, SMIL, CSS, SVG, and so on that are more comprehensive.

But the real point of Lars' writing is that the browsers are playing the game, and in the end, we all benefit when they do. However, I am forced to point out one thing missing from his assessment of what each browser supports: IE does not support SVG. IE has never committed to supporting SVG. It's unlikely IE will ever support SVG, as it competes with its own Silverlight implementation.

I'm currently creating a suggested class plan for a class in SVG for the WaSP's web education series. Included in it will be a bullet to cover whatever tools enable an SVG-like experience in IE. However, what works for IE8 probably won't work for later versions of IE, as we don't have a commitment from Microsoft as to what it will support, natively, in the future in regards to vector graphics. We can't agree on what SVG will look like in HTML5 in the future at the moment, true, but we know it will be part of the specification. It will be part of the specification, or the specification won't gain support, period. However, all indications are that SVG will be an optional component of HTML5, and if this is true, we can never expect to see a native implementation of SVG in IE.

Right now, we have decent implementations of SVG in the other three browsers, the Big Three of Firefox, Webkit/Safari, and Opera. More than that, we have a commitment from the Big Three to continue to support SVG in the future—yes even in whatever ends up in HTML5. We do not have the same from Microsoft. I can appreciate Lars wanting to give all browsers their due, and all due appreciations to Microsoft for finally implementing CSS 2.1, and for donating all the CSS 2.1 test cases, but no native implementation of SVG has inhibited the web developer in the past, and will continue to inhibit the web developer, and hence, the user's experience, in the future. Microsoft's checkered implementation of only what it wants to implement in standards makes it more spoiler than player.