Burningbird's RealTech

I'm doing a curriculum outline for a suggested SVG class for the WaSP Education Task Force.

If you were looking for a class on SVG, what would you like it to include? What would you hope to be able to do with SVG, once you came away from the class? Would you be more interested in working with end-user tools that generate SVG, like Inkscape? Or with tools that generate SVG progamatically, such as a PHP library that can create SVG elements given a set of data?

Speaking of learning SVG, I wanted to point you to David Dailey's book on SVG, State of the Art: An SVG Primer, hosted by the W3C. David's included some nice, easy to follow examples, with associated graphics.

I borrowed Jeff Schiller's SVG election map, and added the appropriate "rep" class to Montana, and "dem" class to North Carolina, to preserve Missouri's pristine undecided-to-the end status. Sure is simple to modify an SVG map.

Stuart Langridge's purple map using the same basic map from Wikipedia, but shading the states based on the closeness of the vote. He also provides access to his Python script to generate the map.

I'm incorporating my Just Shelley weblog into my regular feed, and several of the stories showed up "fresh" yesterday. My apologies for your getting inundated with my writing from yesterday.

We resolved the planetsvg.org domain. I will be donating the domain to the SVG Interest Group, and they will be creating a Planet SVG as part of the new general SVG web site. Hopefully, we'll be able to find more SVG-related feeds to add to the aggregation lists, as I know there are sites I'm missing.

I'll keep the current aggregation site up and running until we make the transfer.

I noticed this thread on the SVG Interest Group email list about an official location for the SVG community page. Sounds like the group will be using the planetsvg.com site, though planet sites are typically aggregation sites. However, a "planet" can be many things, and the name is comprehensive.

I still have planetsvg.org created to provide an SVG aggregator site, but I've not had luck finding feeds for people writing about SVG, nor have I received many requests (any) to be included. I'm not an "official" member of the SVG inner group, so I'm not sure about continuing the site. Perhaps if I can find more feeds that actually work and are related, at least in some way, to SVG, I may continue the effort. Otherwise I might as well close the site down.

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.

Several of the papers at the SVG Open have been *posted online, including an interesting paper on bitmap to vector conversion, a topic I enjoy exploring.

It's too bad that WebKit couldn't be there to represent itself as an SVG viewer. It would be nice to see and compare the future of SVG implementation by The Three.

There's a whole section on SVG and graphic design, another area I'm interested in; especially considering that SVG Effects have now been added to the Mozilla trunk. I downloaded the Mozilla Minefield build that included this addition, and hope to have some some of my own SVG Effects examples up soon.

I've also heard rumors (can't find where, now) of funding for an SVG plug-in for IE so that we know we'll have support for SVG in IE going into the future. It would be better to have a native implementation in IE, but with a plug-in we're assured won't go away, we can at least move forward in the use of SVG.

*thx to Michael Bernstein for link

Where I focused on Ian Hickson's statement about extensibility, every other person, and their brothers, sisters, and aunts are throwing a hissy because of the HTML5 timeline.

Scott Gilbertson writes:

Even if your 2022 ronc-o-matic web-enabled toaster (It slices! It dices! It browses! It arouses!) does ship with Firefox v22.3, will HTML still be the dominant language of web? Given that no one can really answer that question, does it make sense to propose a standard so far in the future?

Jeff Croft writes:

I’m not saying the specs should go away. They absolute serve a purpose. I’m just saying that I personally am done paying much attention to them. Instead, I’m reading blogs like Surfin’ Safari and Mozilla Developer News to find out what the new shiny is in browsers, because these are the things I can actually take advantage of in serving my clients and users.

And?

So?

Specification work was never focused on the end users, it's focused at the user agents or others who have to implement the specifications. The Mozillas, Apples, Operas, Microsoft, et al. The only reason I pay attention to any of it is because of my concern about extensibility.

In the meantime, the new stuff that is HTML5 is leaking into browsers now, not years from now. That's part of the specification process—actual implementation on the street in order to "proof the spec", as it were. And pieces of HTML5 are not just showing up in Firefox, Opera, and Safari/WebKit— IE8 has a few HTML5 tricks up its sleeve.

Heck, HTML5 isn't the only longish spec under development. CSS 2 started in 1998, the lost call for CSS 2.1 was in 2002, the candidate recommendation was in 2007, and Microsoft is only now providing CSS 2.1 support. That's ten years, end to end.

In the meantime, I'm using CSS3 stuff that's only supported by a couple of browsers, and the final release of all the CSS3 bits is probably years out, too. Of course, I only play around with my own spaces—professional web designers and developers know that we can't necessarily use the shiny new stuff for client applications, because we're still having to support browsers that are seven years old.

Hey! We're still supporting browsers almost as old as the timeline when HTML5 will be finalized! I guess things aren't as "today" and "now" as we think they are.

The point is, specifications take time, or at least, good specifications typically take time. Any doofus can toss a quick spec out and call it done, but who wants to use the doofus spec?

That schedule part of what Ian had to say didn't phase me. As far as I'm concerned, the group can take as long as it needs. In the meantime, I'll play around with the local storage, and some of the other odds and ends, as I keep putting in my annoying "But what about SVG?" "But what about RDF?" oar; probably helping to slow the development of the spec, even more.