To recap my weekend effort with the WebKit nightly implementation of the HTML5 progress element:
- I created a application that uses the progress element and provides a text-based fallback for the element. You need to use setAttribute and getAttribute to get the progress element’s value attribute, as accessing the attribute directly on the object only works when progress is implemented in the browser. Apple’s VoiceOver seems to only audibly announce the state of the progress bar when it first receives focus. I can’t test with Firefox and NVDA on Windows, as Firefox has not yet implemented the element.
- I created another application that provides a graphical progress bar fallback using two div elements. I also use ARIA to provide audible signals of progress bar state. During this experimentation, I found that you can’t change the background-color of the progress element, as this will wipe out the progress effect.
- I created a third application, this time embedding the graphical progress bar fallback directly in the progress element. This approach works, but is invalid, since the progress element does not allow flow content. The assumption we take from the allowable content is that we’re supposed to accept a text-only progress bar fallback. This assumption of text-only fallback completely disregards the state of the art when it comes to progress bars that exists today.
- I created a indeterminate progress bar application today. I discovered that you can’t change height or width of the progress element after all. If you do change the progress bar’s style setting, it adversely impacts on the indeterminate progress bar display. You have to accept the exact presentation of the progress bar, as determined by the browser. Frankly, I’ve never been overfond of the “blue gel” progress bar for Apple, and I think the progress bars, as implemented in WebKit, are ugly. Again, the indeterminate progress bar completely ignores the state of the art of “throbbers” that exists today. Can you see using this progress bar in Twitter?
I would move on to testing other new HTML5 elements, except for one small problem: the majority of new HTML5 elements have no real world implementation. Even many of the input elements, which have been around for six years have no implementation, or only partial implementation in one user agent, Opera.
As I wrote in an email to the HTML WG:
There are many new and modified elements in the HTML5 specification that do not have any implementation, and several that only have partial implementation by one User Agent. There are no implementations of any of the new or modified elements by any User Agent other than browsers (such as in authoring tools, or WYSIWYG plug-ins). Lack of implementation, or plans for implementation, especially when an element has been part of the WD for years, seems to meet the criteria for “features at risk”. Features at risk are those most likely to be challenged during Last Call, which could impede progress of the document through the Last Call process.
We get so caught up in the gee whiz newness of HTML5, and all its perceived glamor and sexy techiness that we forget that, for all intents and purposes, three-quarters of the specification is untried.