I remember when Ajax started gaining traction on the web and in the minds of developers. One of the factors that web developers suddenly had to think about was giving feedback to the user when a request was made to the server.
Normally this is something that the browser takes care of (with its rotating letter “e” or its sweeping lighthouse fresnel lens or whatever method your chosen browser uses). But once you decide to use Ajax to make a request to the server, you’re effectively saying “Hey browser, it’s okay; I got this.”
And so web developers everywhere began to recreate loading indicators that were so popular on Flash sites. Some of them are very clever, created entirely in CSS.
This is a pattern that has been codified into HTML itself. We now have a
progress element. This can be used to display fine-grained progress if you give it
max attributes, or you can simply use it without any attributes to indicate that something is happening …perfect for those Ajax requests.
What I like about this element is that you can put fallback content in between the opening and closing tags. So let’s say you’re currently using an animated .gif to show that some content is being requested via Ajax:
<img src="spinner.gif" alt="Loading...">
Now you can wrap that within a
<progress><img src="spinner.gif" alt="Loading..."></progress>
Modern browsers show the native
progress indicator. Older browsers show the animated .gif.
Of course, right now your ability to style that native
progress indicator is limited (the shadow DOM may change that) but, as I pointed out in my book, that may not be a bad thing:
Remember, the web isn’t about control. If a visitor to your site is familiar with using a browser’s native form doodad, you won’t be doing them any favors if you override the browser functionality with your own widget, even if you think your widget looks better.