HTML5 Specs

Is the Progress element truly progressive?

One of the new HTML5 elements is the progress element. It’s an element that allows the web page developer to provide minimum, maximum, and current value attributes, and the browsers update the appearance accordingly. If the value attribute isn’t present, the progress element is considered an indeterminate progress element. In other words, a throbber, such as this example, created using one of the many online throbber generators.

The default appearance of the element is a long bar, with the current value represented in some way. The browsers provide a default appearance based on the following directive:

When the progress binding applies to a progress element, the element is expected to render as an ‘inline-block’ box with a ‘height’ of ‘1em’ and a ‘width’ of ’10em’, a ‘vertical-align’ of ‘-0.2em’, and with its contents depicting a horizontal progress bar, with the start on the right and the end on the left if the ‘direction’ property on this element has a computed value of ‘rtl’, and with the start on the left and the end on the right otherwise.

User agents are expected to use a presentation consistent with platform conventions for progress bars. In particular, user agents are expected to use different presentations for determinate and indeterminate progress bars. User agents are also expected to vary the presentation based on the dimensions of the element.

For example, on some platforms for showing indeterminate progress there is an asynchronous progress indicator with square dimensions, which could be used when the element is square, and an indeterminate progress bar, which could be used when the element is wide.

Requirements for how to determine if the progress bar is determinate or indeterminate, and what progress a determinate progress bar is to show, are included in the definition of the progress element.

You’ll probably have some ability to change some visual aspects of the progress bar, but doing so will probably require that you use a combination of browser-specific CSS property values: -o-progress-fill, -webkit-progressbar-fill, and so on.

One of the reasons given for the progress element is that it is more semantically meaningful than using existing web page elements (typically a div element nested within another). As with the details element, this is another case of attaching semantics to a behavior, when what is semantically meaningful is the overall event taking place. When I brought up the fact that there is no way to associate the progress element with a specific element and action, the HTML5 editor made the progress element into a form element, of all things, so that we could then attach a form label. However, rather than make the element more meaningful, all that’s been accomplished by this change is to make the element that much more kludgy. Case in point: what happens if the progress element is actually added to a form? Is its current value sent with other form element values to the server application?

Accessibility folk seem to like the element because of its supposed built-in semantics. In the ARIA mapping table in the HTML5 specification, the element is mapped to ARIA values: the element’s role is progressbar, the minimum value attribute is mapped to aria-valuemin, the maximum value to aria-valuemax, and the current value to aria-valuenow. What is not happening, though, is that the action that’s taking place is not associated with the progress; just providing a label for the progress element is not sufficient.

I created a very simple progress bar example that updates the progress bar each time a button is clicked. The region related to the progress element is another div element that is updated to reflect the progress value. It could easily be a canvas or SVG element where a complex graphical operation is being performed that could take a considerable amount of time, or a long Ajax query or update.

I mapped the impacted region and the progress element using the aria-describedby attribute, and I note that the region is “busy” using the aria-busy attribute.

The progress indicator in the example is just a simple div element nested within another. As the action “progresses” (the button is clicked), the progress is noted, both visually and via setting ARIA attributes on the element. When the progress is complete (100%) the aria-busy attribute on the active region is set to false. Since I’m using the progressbar role, when the page loads in IE8 or Firefox 3.6 in Windows using the open source NVDA screen reader, an audio cue is provided in addition to the visual cue as the progress bar progresses.

The same visual and audio cues should also happen with the built-in progress element, supposedly with less need for code. However, as the example demonstrates, only two lines of code are necessary in order to manage the visual appearance of the bar—all the rest of the code should be the same regardless of approach:

var bar = document.getElementById("bar");
  var action = document.getElementById("actionhere");
  var progress = parseFloat(bar.getAttribute("aria-valuenow"));
  if (progress >= 100) {

  // following two lines of code are what's necessary to implement
  // the visual display
  var width = progress * 4 + "px";
  bar.setAttribute("style","width: " + width);

  // a little extra
  action.getElementsByTagName("p")[0].textContent = "Action is " + 
                 progress + "% complete";
  bar.innerHTML = progress + "%"; 
  if (progress == 100) action.setAttribute("aria-busy","false");

So, you say to yourself: six of one, half dozen of the other. If the code difference is so small, then it doesn’t matter which you use. However, you would be wrong with this assumption, and the reason why is the very semantics the progress element supposedly provides.

In the example page, I have an action region associated with the progress element. I need to associate the two with additional ARIA attributes. The implication with the progress element is that no other modification to the application is necessary in order to provide an accessible solution. However, the progress element by itself is not semantic—it is the progress in association with the impacted page region and action that is semantically interesting. The progress element is nothing more than a visual indicator.

True, people could still use the additional ARIA attributes to make the necessary associations whether you use the built-in progress element or a simple custom widget, like my example. However, the implication has been with the progress element that no additional ARIA or other markup is necessary in order to form a complete semantic behavior. This isn’t true, but that is the impression given: by using a built-in element all the accessibility requirements are met.

This assumption about the superiority of built-in versus “bolt on” traces back to a decision about philosophical direction made years ago: providing built-in elements over library-enabled alternatives is the preferable approach, because web developers and designers don’t have to do anything special in order to make a page accessible. No offense to the many good people relying on this approach, this assumption falls short of reality. Regardless of how many of these elements become built-in—and the web space could become mighty cluttered if we try to create every possible variation of built-in element—you can’t bypass involving the web page author/designer/developer when it comes to making a page accessible. You have to engage people and provide the necessary tools and clear, unambiguous instruction regardless of how many elements get built-in. You can’t hope to make a page completely accessible by making an end run around the web community.

The progress element only provides part of the accessible solution, and frankly, the least important part of the solution. It is the association between the visual/audio indicator and the action and the page element(s) that’s really important, especially if the action makes the page unresponsive for a period of time.

Let’s say you have a HTML table with a set of values and you want to perform various calculations on those values, and have the results displayed. If the computations are complex, it may take some time to display the values and you want to provide some indicator that something is happening. You could overlay the page and display a throbber animated GIF, which is common now. This works, but if you can track the progress of the application, then you’ll want to provide some indicator of how far along the process is.

Providing a progress element and a label doesn’t hack it. You need to associate the action with the indicator, and you need to do so in such a way that everyone knows that this is the application progress for that element/action pair.

You may also want to take additional actions. If the element behavior results from an action on the part of the user, you’ll want to stop them from doing the action again until the current action is finished. This, too, is part of the “semantics” associated with the behavior. You can even pair semantic rendering with behavior and appearance, by pairing CSS settings with the region’s aria-busy value.

Again, there is nothing stopping you from using the progress element with this type of behavior, but using the element doesn’t suddenly make this all more simple. On the contrary, what the progress element provides is actually the simplest part of this combined element/behavior semantic.

There is also an associated cost for this new element: yet another element for HTML authoring and WYSIWYG tools to implement; for form generation tool developers to have to incorporate (since it is a “form” element); for designers and developers to have to figure out how to use, or style. Styling of the element is a particular issue, because each browser vendor will provide its own default styling, which we may, or may not, be able to override. Whatever we’re given, though, can’t hope to match the various and sophisticated JavaScript/CSS enabled progress bars we use in our applications today.

What happens, too, while we wait for progress to be implemented in our target browsers? Unlike the input fields, there is no “fallback” behavior for this new form element. We could give it a style and set its width, just like we do with the div element, but what happens when the progress element is implemented in some browsers, but not in others? Setting the width would set the width for the element, not the bar value amount, so we’d have an ever expanding bar of which a certain percentage is filled in. To work around this problem, we have to build in tests to see if the progress element is supported or not and perform whatever functionality based on the test—making the element that much more difficult to support. In reality, too difficult to be appealing to a lot of developers, especially those using framework libraries such as YUI or jQuery, where the developer can implement a progress bar with one line of code, and be able to style and design the progress bar however they want.

The progress element just doesn’t add anything new or interesting to provide an incentive to use. We can just as easily create an accessible version with what we have now, without having to incorporate functionality to test for element support, or wait for older browsers to fall into disuse. The use of the element isn’t, by itself, overly accessible, since it only provides part of the overall semantics. More importantly, it ignores the progress we’ve made when it comes to framework libraries and dynamic applications. Most of the major UI libraries already have ARIA built into the existing progress bar widgets, and are prettier and much more interesting: the jQuery progress bar is accessible, easy to use, and themable; the YUI progress bar can be customized; other libraries provide even more packaged behaviors. We’d be better spending time providing tutorials on how people can use these libraries, accessibly and semantically, then to push the use of an element that’s not very useful and is dated even before it hits the street.


Dad’s WWII Gun

Dad's WWII Gun

Dad's WWII Gun

Burningbird Just Shelley


Just realized that my redirected feed was no longer being redirected. Though I haven’t been writing much, I have been writing at some of my sites. I’m also redesigning again, based on the work I’m doing creating an ePub theme and application for Drupal. Needless to say, the design is clean. Very, very clean. One could even go so far as to say stark.

I have linked all my writings in this space, except for my more personal site, Just Shelley. I haven’t written at that site since Just a Cat. When I do, I’ll link the stories here, too. I promise: no more sending you all over hell and gone trying to find what I’m doing.

Haven’t been taking many photos, either. What pictures I have taken I’ve uploaded to my newly renamed MyGreen site (formerly MissouriGreen). Some new Spring flowers, new orchid shots, but nothing that makes me want to go, “Hey, look at this!” Photographically, I’m in a rut.

It’s been a quiet winter, focused on the new book and my work with the HTML5 working group. Now that I’m done with both, I hope to be a little more active here.

Money People Technology

An Appleless future

It is time to buy new computers.

My desktop Windows computer is a 4+ year old Dell laptop with a burnt out LCD that I hook up to an external monitor. It’s running Windows XP, and could potentially be upgraded to Windows 7, but only with much wailing and gnashing of teeth.

My laptop is the last of the PowerPC PowerBooks running Leopard, since Snow Leopard only runs on the Intel machines. I’ve had to replace the Airport card, and the hard drive, but both were covered under warranty. The keyboard is starting to get mushy, but still works. The real problem is the growing lack of support for the old PowerPC architecture.

If July royalties go well, then I’ll look at replacing at least one, possibly both. When I do, though, I won’t be replacing either with an Apple computer.

Why an Apple-free future? One reason is cost: I can replace both my desktop and laptop with good, relatively powerful Windows machines for the cost of one 13 inch Macbook Pro. The days of having money to burn for “sexy” machines are over—now I want solid machines with good software support that are competitively priced.

Another reason to move from Mac back to Windows is I don’t need a Mac. All of the applications I use have a Windows-based version. I stopped using MacPorts a while back when I got tired of the continuous round of upgrades. I don’t run a web server on my home machines anymore, doing all my development out at my web site. Besides, you can run a web server on a Windows machine as easily as a Mac.

Ease of use isn’t an issue for me, as I’m comfortable with both environments. I haven’t tried Windows 7 but whatever quirks it has, I’ll learn and adapt. I used to be able to work with DOS and the old VAX/VMS—I can handle a new operating system.

Security used to be a big reason to stay with the Mac, but nowadays Apple is as much of a target as Windows. Besides, most security problems arise because of applications, and cross OS boundaries. Relying on using a lesser used OS to protect you from problems isn’t an effective approach: a secure system is 95% common sense, 5% other. So, save some money and use common sense.

My Photoshop installation is CS3 on the Mac, but supposedly I can cross-grade my license, and swap it for a Windows license. If I have spare change from buying a new machine (i.e., you all buy more of my books) I’ll upgrade to CS5, and cross-grade the license to Windows. If Adobe doesn’t let me port my license to Windows, well, then it’s time to move all of my graphics work to GIMP. Besides, I primarily like Photoshop because I like Adobe Bridge for editing metadata and viewing my images. There are alternatives.

A last reason for not staying with Apple is I’m tired of the company. I’m tired of hearing about it. I’m tired of seeing people in line, waiting for a phone. I’m weary of the Apple cult, Apple lawsuits, Apple prototypes, Apple mystic, and stark black and white.

I am no longer enamored of devices where form takes precedence over function. What other manufacturer could get away with providing devices where you can’t replace the batteries?

Worse is the lock-in. If you want to develop for the iPhone or iPad, you have to own a new Macbook Pro just to use the relevant SDK, and then you have to purchase the SDK. It also peeves me to see people buying into what is nothing more than a horrifically closed, obsessively controlled environment. You have to use the Apple code, develop to the Apple model, think the Apple mindset, which embraces puritanical censorship and nowadays lacks both perspective, and sense of humor.

The Steve Jobs of yesteryear was arrogant, but innovative. The Steve Jobs of today is just plain arrogant. I don’t want to give him my money.


Skewing old

Amazon released a Kindle 2.5 update this week. The big news about the software upgrade is that it finally includes support for collections—being able to group books based on some criteria. This is the functionality we’ve been asking for since the Kindle was first released. Great!

Great, except that the software upgrade is for Kindle 2 and DX owners, not the Kindle 1. Amazon seemingly perceives the Kindle 1 as an early, failed experiment, and Kindle 1 owners, early adopter guinea pigs who should be content with just being there in the beginning.

When Kindle 1 owners expressed disappointment in the Kindle owner discussion forums, we were told that this is the way it is; that companies don’t support old, obsolete equipment. Instead of bitching about the software update, we were told to upgrade to a shiny new Kindle DX. One wit even quipped that yes, he also wanted support for his Commodore 64.

Ignore for the moment that the Commodore 64 is 28 years old, and my Kindle 1 is a little over 2 years old…