Making progress with SVG

Web Directions has created a No Bit, Sherlock developer challenge, with nice prizes such as a laptop and XBox for the person or persons who comes up with the most creative variation of SVG progress element. A nice play on the name (“no bit”), but even nicer prizes.

I’m not participating in the contest, but couldn’t resist playing with the idea of creating progress elements with SVG.

One type of progress element is the indeterminate progress, also called a throbber. If you use Twitter, it’s equivalent to the circling animated graphic, and indicates that an event is happening, but the web site can’t determine the exact progress of the event.

When I think of an unending event, I always imagine ouroboros, the serpent swallowing its own tail, and creating an infinite seeming circle. It can represent many things in many different cultures but, to me, represents a continuous cycle with no beginning, middle, or end. It just is, until it is no more.

With that in mind, I thought I would try my hand at creating an ouroboros indeterminate progress element. Luckily for me, I didn’t have to stretch my rather limited graphic skills in order to create the ouroboros: Wikipedia provides an elegant graphic, already formatted as SVG (PNG format), and with a license that allows me to use the graphic for my own work.

My first indeterminate progress element plays on the cyclical nature of ouroboros, by rotating the graphic around its origin, as you can see in the following example if your browser supports SVG. Clicking the start button begins the animation; clicking the end button, stops it. The application makes use of the built-in transformational capability of SVG.

It’s an interesting effect, but a little CPU intensive. In addition, there’s nothing uniquely SVG about the effect. I could have just as easily grabbed the PNG formatted graphic and used the new CSS3 transform attributes to rotate the image. I wanted something that plays on the uniqueness of SVG—that non-bit nature of SVG that forms part of the title of the Web Directions contest.

SVG is a vector graphics language, which means that a graphic consists of various elements, all combined into a whole. The ouroboros I used is actually made up of several path elements, forming the head, the eye, and the different scales along the body.

What if, instead of cycling the entire serpent graphic, I just cycle an effect around the serpent? A popular Ajax-based throbber is the one that Twitter uses, and consists of a animated dashed circle, where the dashes around the circle are hidden and displayed using a circular motion.

I applied the Ajax style throbber effect to my ouroboros graphic to create my next effort, as shown below. In this case, the serpent remains static, and only the scales change color, in a circular motion, to indicate some action is taking place.

I prefer the second approach, and it’s less CPU intensive than using a rotating graphic. You can also play with the colors: just make sure there’s enough contrast between “inactive” scale and active one so that the circular effect is easily seen.

Of course, both of these designs are for an indeterminate progress graphic. What about a deterministic one, where there is a beginning, middle, and end?

Even though I was inspired to use ouroboros because of the cyclical nature of the graphic, I’m also using SVG, which I’ve always felt to be synonymous with limitless possibilities. Ouroboros also means complementary opposites and what is more complementary, and opposite, than an event that’s not started, and an event that’s completely finished?

I made a third progress animation, but this time, there is a beginning, middle, and end. As whatever task progresses, my serpent’s scales turn from gray to black. In order to ensure that my application user knows what’s happening, I also provide a text description of the progress.

One last change for all of the graphics: ensuring they’re accessible.

All three graphics are given a role of progressbar. All three would also normally be associated with the task using other ARIA attributes. In addition, since the third application is a deterministic progress graphic, I also set the aria-valueminaria-valuemax, and aria-valuenow attributes on the SVG element. (I could have also set these values on the g element that groups the graphic within the SVG.)

If you load the graphic within Firefox using the NVDA open source screenreader, you’ll not only “see” the progress, you’ll also be able to hear the progress. And though these variations are a fixed size for demonstration purposes, they can be easily scaled as small or as large as you want, because I’m using SVG.

A fun little challenge. I’m looking forward to seeing the Web Directions “No Bit, Sherlock” contest entries.

HTML5 Technology

Too much crap

I tried to find a web page to link in my last story, about the recent discussion surrounding Apple’s new HTML5 demo that deliberately prevents other browsers from accessing the examples. I finally had to link my own Twitter note about the problem, because every site that wrote about the issue had too much crap in their pages.

Don’t have to take my word, just search on “apple html5 demo blocks”, and you’ll find site after web site that covers the story, true, but the story is pushed down by headers that manage to link in half a dozen ads, and multiple Google links to boot. Or, just as you finally dig out the real stuff, some stupid overlay ad or “survey” hides everything, and you have to search for the little bitty close text, just to get rid of the damned thing.

Then there’s the Twitter tweets, and the Facebook notes, and the links to this application and that application; this widget and that. Are we afraid that people will think no one likes us if our web pages aren’t full of moving, annoying bits?

I watch my browser status bar as dozens of different domains have to be looked up, just to read one or two paragraphs of text. If my ISP’s DNS server is running slow, I never get to the stories.

I’m sure someone is making money from all of this. How much money are these sites really making, though, if after minutes of nothing, I hit the stop button and return to the searches to find a site that may actually provide the story, load relatively quickly, and not exhaust my DNS server in the process.

Folks have talked about wanting native semantics in HTML5 because they don’t want to have to load the big bad JavaScript frameworks, such as jQuery. “Give us date pickers and color pickers”, they say, “Because the JavaScript is too big! It hurts the web!” What’s absolutely absurd about all of this, is that the JavaScript framework libraries are probably the only thing in any of these sites that load quickly.

What Google, Yahoo, and Bing need to start printing in search results is how many domains will have to be looked up, how much external crap will have to be loaded, if we click that link. Frankly, I would find that much more helpful than a warning that the site could potentially be a source of malware. At least malware is a straightforward attack, which is better than this killing of our time waiting on these bloated, useless sites, where every ad company in the entire world has staked a claim, leaving tiny pieces of the page for actual, useful stuff.


HTML 5 update

I’d provide another update on my HTML5 change proposals, but no co-chair decision has yet been published. There was a note in the last HTML WG teleconference minutes that decisions on three of the items, including two of mine, were ready to be published last Thursday, but nothing has appeared in the HTML WG email list.

As soon as the co-chairs publish the results for all six of my change proposals, I’ll post a note.

Regardless of decision, there is an indication, albeit on IRC, which makes it somewhat unreliable, that the browser companies will add the elements, whether they’re part of the HTML5 specification or not.


The HTML WG chairs have written up two decisions. I wasn’t expecting either to succeed, but was extremely disappointed in the weakness of the decision, and the fact that neither decision addressed anything that I brought up in either of my change proposals—the chairs focused purely on the objections to the proposal and counter-proposals, not to the proposals, themselves. (The author of the counter-proposals also noted that neither the proposal nor counter-proposal arguments were addressed in the decisions.)

You can read all the material yourselves, see what you think.

Removing the figure element:

Removing the aside element:

If you’re thinking that the chair decision regarding both change proposals are exactly the same, you’re correct. Sam Ruby duplicated the decision for both items, even though the change proposals were about two different elements.

That, and the fact that the decisions did not once address the concerns I raised, does open the door to formal objections. However, I have lost faith in the W3C. The organization has abrogated its responsibilities to all web communities, including web authors and developers. It is no longer the W3C of the 1990s.