HTML5

A common UI pattern for a range slider is to allow the user to move the slider and display the value of it somewhere on the page, changing the displayed value as the user moves the slider.

I think the expected behaviour in such a case is that the value should display instantly, as the user is moving the slider, rather than the page waiting for the slider to finish moving before the displayed value is updated. I suppose there could be cases where you prefer a delay over instant results, but I think the expected behaviour is to display the results instantly.

As you’ll see in the videos below and in your own testing, the behaviour of the input event compared to the change event is not exactly the same in different browsers when applied to a range slider.

Before I get into the meat of this post, I’ll just provide some context. Last week, Harry Roberts posted a fantastic article discussing his view of bad CSS. In that article, as he’s done before, he disourages the use of IDs as selectors.

In response, Jeffrey Zeldman tried to defend the use of ID selectors. I posted a few comments in response to Jeffrey and another commenter, explaining why their views were wrong.

Where would the web be without links? Links are what hold together what we know as the World Wide Web. Without links, the World Wide Web would be more appropriately called the World Wide Set Of Unrelated Pages, or, incidentally, WWSOUP.

While it’s great how simple and effective the process is of “linking” pages together, I think there’s room for improvement.

As the weeks go by, I find tons of new developer resources, tools, and things worth looking into.

I wrote a similar roundup of JavaScript resources, so this time I’m covering stuff related to what we commonly call “HTML5″ (even though a lot of this stuff could easily fall under a “JavaScript” umbrella too).

This is a question that has been answered in a number of different places. Unfortunately, the answers in some instances have not been good ones. In fact, they’ve either been way too optimistic and/or presumptuous — or else just downright wrong.

Also, when we use the term “HTML5″, what exactly are we referring to? HTML5 covers a number of different features and technologies, some of which have nothing to do with SEO. So, generally speaking, when people ask this question, they’re usually referring to HTML5’s new semantic elements. So, I’ll primarily focus on those here.

A few months ago, after helping to co-author HTML5 & CSS3 for the Real World, SitePoint asked me to do a related video screencast series on their new Learnable.com website.

I agreed, and the course has been available online now for a few weeks. It was a fun experience, and it’s motivated me to plan for some screencasts here on this site, too. I won’t go into great detail on the course here — you can review the course contents on Learnable.com at your leisure.

Basically, the course consists of 28 separate video tutorials that make up 9 full lessons. Most of the videos are about 10 to 15 minutes long, with a few under 10 minutes, so they’re pretty easily digestible. Lesson 10 is a “resources” section that I’ll probably continue to add to, and Lesson 11 is a “bonus voucher”.

Choosing the right element for your markup is not a life-and-death situation. Nonetheless, I think HTML becomes easier to maintain and easier to read when content is marked up in a more meaningful manner, in line with the new developments in HTML5.

HTML5 has, as most of us know, introduced a new <aside> element, which I feel can replace the <blockquote> element in specific places where we would normally think a <blockquote> is more appropriate.

As much as we would like to turn a blind eye to the large number people using Internet Explorer and thus take advantage of CSS3 and HTML5 in all its glory, with certain projects, we really don’t have much of a choice.

If the traffic in a particular niche is IE-heavy, then you have to deal with that accordingly. If you go the Andy Clarke route then you may choose to use those new enhancements to the full, but allow a degraded experience in IE.

If you go the traditional corporate route, then you do everything you can to get IE to look and behave the same as the other browsers. That could mean ignoring a lot of new CSS3 and HTML5 stuff, or else it means filling in the gaps with scripts, hacks, and IE-only filters.

Two other authors took part in this exciting new project: Estelle Weyl — who probably doesn’t need much of an introduction if you’re familiar with many conference speakers in the web standards world — and Alexis Goldstein, a well-rounded programmer from Brooklyn.