Categories
SVG

Playing the game

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.

Categories
Graphics/CSS

Gimp 2.6 released

GIMP 2.6 was released this week, with enhanced UI experience, as well as support for 32-bit color. The latter is particularly important as several web designers and photographers have focused on GIMP’s 8-bit support as their main reason not to use the tool. The 8-bit support is still the default, but you can turn 32-bit on, and the next few versions of GIMP should incorporate comprehensive support for both 32-bit and non-destructive editing.

The release is source code only at the GIMP site, though Lifehacker provides links and instructions for installing the tool in Ubuntu and Windows. The application has not been ported to Macports yet, and probably won’t be for some time. I am considering doing a source code build, something I normally wouldn’t touch. However, I really do want to see the new features, and in particular, the 32-bit support.

What makes the timing on GIMP 2.6 especially relevant is the fact that the days when we could spend thousands of dollars on software and equipment in order to work with our photos and web designs are over for most of us. I wasn’t joking when I said earlier that Frugal is sexy. Not buying is the new black.

When I have GIMP 2.6 installed, I’ll be back with a more detailed look. In the meantime, let’s hear it for 32-bit support. Let’s hear it for free.

Categories
XHTML/HTML

Distributed Extensibility

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…