It does, however, support parts of the Shadow DOM. That means we can style this element, and give our users a visible control.

The image below shows a rather garish green-and-orange version of the range user interface widget. This is after adding some styling, as it appears in the stock Android browser.

And below is the CSS that gives us the above image.

input[type='range']{
    background: #0c0;
    height:10px;
}

input[type='range']::-webkit-slider-thumb{
    background:#f60;
    height:30px;
    width:30px;
    border-radius: 30px;
}

To date, this does not affect Chrome or Safari for the Desktop. ::-webkit-slider-thumb does partially affect iOS Safari. I’ve included an image of what it looks like below (not to scale). Notice that the thumb color changes, but the slider background does not.

This may also affect other browsers that use Webkit such as the Web Browser for S60 Nokia and Samsung’s Dolfin. I haven’t tested it yet, but if you have, please let us know in the comments.

Also keep in mind that this element has a pretty poor user interaction in Android browser. It’s not very responsive, and doesn’t operate all that intuitively. This is true of most mobile browsers, but in my opinion (and based on limited experience), Android is worst of all.

HTML5 introduces several additional types for the input element. One goal of these additional types is to offload error checking from the JavaScript layer to the browser. The HTML5 specification includes rules and patterns for data validation, including for URLs with the url attribute value.

According to the HTML5 specification, a URL is valid when it is not an empty string, and is a valid absolute URL. A complete definition of what constitutes a valid URL can be found in RFC 3986 and RFC 3987. The short version is that a valid URL must, at minimum, consist of a scheme (https://, ftp://, gopher://) and a host name. If it does not, validation should fail, and the browser should throw an error.

Now most recent browsers* take the following steps when it encounters an invalid URL such as foo.com or example:80.

1. Fire an invalid event on the element in question.
2. Display an error message to the user.
3. Prevent form submission.

To prevent careless input errors and guarantee validation, Opera will automatically prepend http:// to the value of a URL input field if it is missing when the field loses focus (and if no pattern attribute has been added). This means that the invalid event usually will not be fired.

Of course, “most recent browsers” does not mean “all.” To date, Safari will fire the invalid event, but it will do so silently. No error message will be shown to the user. Form submission will succeed. The value submitted will be the same as what was entered by the user. Android’s WebKit behaves much the same way.

Safari also does something else differently on mobile devices: it shows a keyboard layout that is optimized for typing URLs, complete with a .com virtual button.

Back to my friend’s use case: he wanted the benefit of mobile Safari’s UI sugar, so he was using <input type="url">. He was unconcerned with whether the URL was valid because he was using server-side validation. His primary goal was ease of data entry for domain names on iOS devices.

However: that isn’t really the purpose of <input type="url">. Validation is, and a domain name by itself is not a valid URL.

But since the ship has sailed, the horse has left the barn, and the chickens have flown the coop, let’s talk about how to prevent Opera from automatically prepending http:// to the value of a URL input field.

To do this, we need to do two things:

• Add a novalidate attribute to the form element.
• Add a null pattern attribute to the field element.

For example:

<form action="../form.php" method="post" novalidate>
    <input type="url" name="uri" id="uri" value="" pattern="">
    <button type="submit">submit</button>
</form>

The novalidate attribute turns off client-side validation for the entire form. The pattern attribute override’s Opera’s native validation checking.

See for yourself. This will still trigger the URL-entry keyboard layout in iOS browsers, while killing Opera’s prepending.

If you use this technique, keep in mind that server-side validation is even more important. Because we are not providing any constraints on this data, we have increased our chances of getting invalid or malicious data. You should be validating anyway, however, since it is not 100% possible to guarantee that the data reaching our form script has actually come from our form.

*And by “recent browsers,” I mean the latest versions of Opera, Chrome, Firefox, and the forthcoming Internet Explorer 10, but not IE9.

HTML5 …

• re-imagines HTML as an API with objects, events, interfaces, and methods or a collection of interfaces.
• defines an algorithm for generating a consistent, cross-browser friendly DOM tree, regardless of the quality of the author’s markup.
• adds new elements with semantic meaning and multimedia capabilities.

For more, consult the media events section of the HTML5 specification.

Now what’s less clear is how to send data from multiple files to a server-side PHP script. Turns out, it’s quite easy. Treat it in the same way you’d treat any other array of options (radio buttons, for example) and include square ([]) brackets in the field name. See the code below for an example:

<!DOCTYPE html>
<html lang="en-us">
<head>
	<meta charset="UTF-8">
	<title>HTML5 Multiple File Upload</title>
	<link rel="stylesheet" href="s.css" media="screen">
	<style media="screen"></style>
</head>
<body>
	<form action="processor.php" method="post" enctype="multipart/form-data">
		<input type="file" value="" name="upload[]" multiple>
		<button type="submit">Upload!</button>
	</form>
<script></script>
</body>
</html>

In processor.php, all we’re going to do is print the $_FILES array so you can see what’s happening.

<pre>
<?php
     print_r( $_FILES );
?>
</pre>

Copy and paste this code and save it to your own server to see everything in action.

Related:

• HTML5 Specification
• Slides from my recent HTML5 Forms talk

One of the big misconceptions about HTML5 is that any tag can be self-closed. That’s not true, though it appears that way.

What HTML5 does is provide parsing rules for handling mismatched tags and markup. While it seems like self-closing tags are acceptable, that’s not the case. This post explains what’s really at play. Let’s take a look.

‘Self-closing’? Our old friend />

Let’s separate void elements from empty tags that don’t contain content. You’re probably familiar with "void" elements — elements that can’t have any content. They include the img, br, hr, and meta elements.

In XHTML, we closed void elements according to the rules of XML syntax, which requires all elements to be closed with end tags or self-closing tags. That’s where we get the familiar space-slash ( />) of XHTML. HTML5, however, uses HTML parsing syntax, making the  /> unnecessary for void elements. It is, however, valid to use it. Yes: <meta charset="UTF-8"> and <meta charset="UTF-8" /> are both acceptable.

Here’s the thing: a void element is not the same as an element that doesn’t contain any content. And ‘self-closing’ does not mean the same thing as “the end tag is optional.”

To state it clearly: Most HTML5 elements are not self-closing, but many elements do not require an end tag.

Wait, what? End tags are optional? It’s like HTML 3.2 all over again!

Yes, some HTML5 elements do not require an end tag. Those circumstances are outlined in the HTML5 specification. The p element, for example, does not require an end tag if the p element is immediately followed by an address, article, aside, blockquote, dir, div, dl, fieldset, footer, form, h1, h2, h3, h4, h5, h6, header, hgroup, hr, menu, nav, ol, p, pre, section, table, or ul, element, or if there is no more content in the parent element and the parent element is not an a element.

In fact, some tags can be omitted altogether. Browsers with compliant HTML5 parsers (such as the recently released Opera 11.5 snapshot) will add the end tags to the DOM.

But again: "end-tag optional" is a different concept than self-closing.

How about some examples?

Let’s take a look at the following bit of code:

<!DOCTYPE html>
<html lang="en-us">
<head>
    <meta charset="UTF-8">
    <title>HTML tag example</title>
    <link rel="stylesheet" href="styles.css" media="screen">

</head>
<body>

<header>
    <hgroup>
        <h1>When self-closing tags fail</h1>
        <h2>Not all HTML5 elements are self closing, though some are ‘end tag optional’</h2>
    </hgroup>
</header>

<article>
<p>This is to demonstrate that all HTML elements are <em>not</em> actually self closing. There is a "self-closed" <code>p</code> element following this closed paragraph. And it’s followed by a a "self-closed" <code>a</code> tag and another paragraph.</p>

<p id="notaselfclosinggraf" /><a id="notaselfclosinganchor" />

<p>As you can see, this paragraph is part of the preceeding link.</p>

</article>

</body>
</html>

You can view the code yourself. Notice that the last paragraph is actually treated as the link text of the of the supposedly self-closed link before it.

Let’s take a look at another example:

<!DOCTYPE html>
<html lang="en-us">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width,user-scalable=yes,initial-scale=1.0"/>
    <title>HTML tag example</title>
    <link rel="stylesheet" href="styles.css" media="screen" />
    <style>
        .trigger1{
            background: #369;
            border-radius: 4px;
            display:block;
            padding:3px;
            color:#fff;
        }

        #tvFinderImg{
            background:#0c0;
            display:block;
            width: 10px;
            height:10px;
        }    

        #tvFinderImg h3{
            border:1px dashed #c09;
        }
    </style>
</head>
<body>

<header>
    <h1>Spans aren't self-closing either</h1>
</header>

<div>
<a
class="trigger1" href="#tvFindersrchd">Lorem ipsum <span id="tvFinderImg" /></a>
<p>This is some copy after the "self-closed" tag.</p>
</div>
</body>
</html>

In older browsers — Internet Explorer 8, for example — the supposedly self-closed tags are handled like unclosed tags. In those browsers, you will see a pink border around This is some copy after the “self-closed” tag.

In browsers that do have HTML5-compliant parsers — Firefox 4, the Opera 11.5 labs build mentioned above — the browser re-writes the DOM and adds a closing span tag. Yep. HTML5 saves developers from ourselves by providing rules for handling bad markup. View the DOM of that page in Opera 11.5 with Dragonfly, or Firefox 4 using Firebug (or in Chrome, Safari or IE9 using their developer tools) to see what I mean.

Let me restate this point for clarity: it only appears that self-closing tags are permitted in HTML5. In actuality, the browser parser treats non-void, self-closed tags as start tags and closes them for you.

Don’t believe me? Try running these pages through the W3C Markup Validator.

So I can go back to sloppy code?

Maybe. I think you can make an excellent argument for using relaxed markup rules when targeting end-users who may be paying per byte of bandwidth or who are on slow connections — Canadian mobile users, for example. Send less code. Make the browser handle it.

But keep in mind that older browsers do not have HTML5 parsers. Internet Explorer 7 & 8 do not. Opera 11.10 beta does not. Opera Mobile does not. (Older versions of WebKit technically don’t either, but WebKit has long supported the /> syntax.) If you have a large proportion of older browser users in your audience, stick to the stricter, XML-style syntax: if you have a start tag, use an end tag. The space-slash is optional for void elements. Don’t forget to validate!

Namespaces can be a great way to build up a pragmatic URL structure that’s easy to remember with continued usage. What do I mean by a namespace? I mean a portion of a URL that dictates unique content.

One of Kyle Neath’s tips from his post URL design.

This. URLs make your site more usable, navigable and extensible, particularly when your site is a RESTful application.

[Via Jeremy Keith]

Heilmann explains:

• Why client-side storage can be a good thing;
• The origins of and need for local storage;
• How to use local storage;
• When to use local storage;

I implemented local storage in browsers that support it for our wedding web site. It saves the open or closed state of each content chunk. It was easy enough to save the data. And it gives the user a bit of added convenience.

Read the piece.

Keep in mind: local storage can be — and will be, and right now is probably being — used to create hard-to-delete “super cookies” for advertising, marketing, and other privacy-eroding things.

The good news is the web storage specification and all browsers that support it restrict local storage data to the originating domain. The bad news is that most browsers don’t offer an easy way to local storage objects. In Safari, for example, you’ll need to fire up Terminal (quit Safari first) and navigate to /Users/tbrown/Library/Safari/LocalStorage to delete items individually or collectively.

This isn’t a new issue. Flash ‘cookies’ have existed for years (view, manage or delete yours). But what is new is that some (most?) browser makers have made it hard to manage and control what gets stored and for how long.

The most important aspect of HTML5 isn’t the new stuff like video and canvas (which Safari and Firefox have both been shipping for years) it’s actually the honest-to-god promise of interoperability. Even stodgy old Microsoft, who has been doing their best to hold back the web for nearly a decade, understands this and you’ll see it throughout their marketing for IE9. … The idea that the same markup, even with mistakes, will be rendered exactly the same. HTML5 represents the chance for browsers to work together and find common ground.

That’s Christopher Blizzard, the Director of Developer Relations and Open Source Evangelist at Mozilla in his June post, intellectual honesty and html5.

He’s referring to Apple’s HTML5 demo. It seems somewhere along the way, HTML5 went from specification to consumer marketing buzzword, and now everyone is confused about what HTML5 is and isn’t, and which browsers support it and don’t.

Thumbs down Apple. Thumbs down.

Only Firefox provides a means to calculate the amount of the video that has been loaded. The progress event object includes total and loaded properties that reflect the total size of the video file, and the amount the browser has retrieved from the server. This is also a reflection of how each browser handles video downloads.

Erm, that’s only sort of true. As zcorpan explained in the comments, the latest version of Firefox implements an old version of the specification.

In the most recent version of the HTML5 spec, the total and loaded properties of the progress event were removed and (mostly) replaced by the video.buffered property.

So while Firefox 3.6.x is still the only browser that provides total and loaded properties in the progress event, the latest revision added a new property to the video element that works similarly — note the emphasis on ‘similarly.’

What’s the difference? Both the total and loaded properties of the progress event express the download’s progress in terms of bytes. The video.buffered property expresses the download’s progress in terms of seconds. They’re similar in that you can determine the status of a download, but using seconds instead of bytes is more relevant for seeking within a timed media file.

By checking video.buffered.end(), we can determine how many seconds of the video are available to the browser and provide the relevant error handling (if a user seeks too far) or interface changes (such as a loading progress bar).

I am still learning how the video.buffered property works, particularly in conjunction other properties and events of the video object. I will post more about this later.

One thing to remember: Firefox has not yet implemented the video.buffered property. It is only available in Safari, Chrome and (sort of) in Opera (still learning the ins-and-outs). (And Internet Explorer doesn’t support the video element at all, though version 9 should when it’s released.)

The progress event is fired as the browser loads more of the media file. It may not be fired reliably, however. Chrome, for example, will not fire the progress event if it has cached the video file.

Only Firefox provides a means to calculate the amount of the video that has been loaded. The progress event object includes total and loaded properties that reflect the total size of the video file, and the amount the browser has retrieved from the server. This is also a reflection of how each browser handles video downloads.

Firefox requests partial content on the initial page load, then pauses downloading until the play event is fired. After the play event is fired — whether when the user clicks the ‘play’ button or the video tag has the autoplay attribute — Firefox resumes downloading the video file.

Safari, Chrome, and Opera conversely, download the entire video on page load — they automatically buffer by default. Opera and Chrome, however, will make the video available for play almost immediately, while Safari takes several seconds to download a larger portion of the file. Firefox will behave similarly if when the autobuffer attribute is present.

Presumably because they auto-buffer video, neither Safari, Chrome, nor Opera offer a means by which to detect either the video’s size, nor how much of the video has loaded.

Some example code for handling the progress event (assuming we’re wrapping this video element in a <div> tag with an id of ‘container’). This will return the percentage of the video loaded in Firefox (and other browsers that don’t auto-buffer), and fail silently in other browsers.

var container = document.getElementById('container');
var video = document.createElement(video);
// only Firefox and Opera support Ogg ... oh yeah Chrome does too.
video.setAttribute('src','movie.ogv');
function progressHandler(e){
      if(e.total && e.loaded){
           // percentage of video loaded
          var proportion = Math.round( e.loaded / e.total );
          return proportion * 100;
      } else {
           // do nothing because we're autobuffering.
      }
}
video.addEventListener('progress',progressHandler,false);
container.appendChild(video);

We need to do more than just point the browser at a video file like the image tag does – there’s a lot more to it than just retrieving and displaying a video. The <video> tag certainly addresses the basic requirements and is making good progress on meeting others, but the <video> tag does not currently meet all the needs of a site like YouTube.

From the YouTube API Blog: Flash and the HTML5 <video> tag.

Software John Harding says that YouTube’s HTML5 experiment showed that the format isn’t quite ready for prime-time. Among the reasons? HTML5 video doesn’t yet have the robust streaming capabilities, encapsulation capability, content protection, or camera and microphone support. Flash, however, does.

If audience measurement, ad support, and rights management are part of your business requirements, stick to Flash exclusively. HTML5 video does not yet have the ecosystem of services for ad serving, analytics, or streaming that Flash video does.

That’s what I said in my latest post “The Mess and Magic of HTML5 Video,” on the Armchair Media blog.

Our player doesn’t just simply stream video, it must also secure the content, handle reporting for our advertisers, render the video using a high performance codec to ensure premium visual quality, communicate back with the server to determine how long to buffer and what bitrate to stream, and dozens of other things that aren’t necessarily visible to the end user.

In February, I offered four reasons why you shouldn’t count Flash out just yet. Eugene Wei Hulu.com‘s Vice President of Product offers four more in his post Pardon Our Dust about Hulu’s new video player (Via New TeeVee).

Thank you Mr. Wei for writing a follow-up post for me. HTML5 is great way to deliver audio and video to the browser in a way that frees users from having to install a plug-in. What it isn’t so great for — yet — are the things that many content creators and advertisers find important: tracking, DRM and ad serving.

Here’s a business suggestion for Hulu: offer an HTML5 player as a premium upgrade. Hulu plans to charge $10 per month. What if they offered — for, say, an extra $5 or $10 — “iPad-ready” video using HTML5?

Check out Hulu’s video introducing the new player.

So Apple announced the iPad, and it won’t support Flash.

That shouldn’t be a surprise. Neither the iPhone nor iPod Touch support Flash. Indeed most mobile platforms don’t (yet) support Flash. Even the smartest of smart phones have limited processing power and storage space compared to laptops and desktops.

According to Steve Jobs, Apple doesn’t support Flash on its mobile devices because “it’s buggy.” But I’d guess their decision has as much to do with Flash’s capabilities. Many of the products in that cash cow known as the Apple App Store could be developed using Flash instead.¹ Supporting Flash would undermine that billion-dollar revenue stream, piss off iPhone / iPad developers, and also put Apple at Adobe’s mercy.

Besides, everyone’s moving towards HTML5, right? Well yes they are, but not so quickly. I wouldn’t rule Flash out for another 3 to 5 years.

Why do I say this? Four reasons:

1. Flash has inertia on its side. Major content sites such as Disney and Hulu still use Flash to deliver video, animation, and interactive experiences. According to Adobe’s statistics, Flash has over 90% penetration in mature markets. Developers already know how to use Flash and ActionScript to create these experiences. In short: there are a lot of folks invested in Flash as a platform.

2. HTML 5 isn’t quite ready for prime time. It’s a shifting standard, a work-in-progress. Though even Internet Explorer 8 supports some significant HTML5 features, Internet Explorers 6 and 7 do not. And both browser versions are still used widely enough that dropping support is not an option for most developers.²

3. Flash is still the best cross-browser, cross-platform way to serve audio and video. Safari / WebKit, Firefox / Mozilla and Opera all support the HTML5 video element. They do not, however support the same codec.

   Apple is squarely in the H.264 camp. Google paid a licensing fee so that it could include an H.264 decoder in Chrome. H.264 is a patented codec. Any browser that wants to enable H.264 video will need to pay a licensing fee.

   Licensing fees and patent concerns are why Opera and Mozilla are backing Ogg Theora. Ogg Theora is an open sourced codec with no known patents. I should add here that Chrome also supports Ogg Theora. Google, perhaps wisely, chose to include both.

   The big monkey wrench in video element adoption, however, is Internet Explorer. Internet Explorer is waiting for them other fools to work out that default codec business before it implements support for the element.

   And all of this is before we get into the differences in how browser vendors will execute the specification. That’s a whole ‘nother headache.

   We will be using Flash until clients are willing to pay for separate Safari, Firefox and Internet Explorer video integration or until the HTML5 working group agrees on a default codec.

4. Adobe is working to bring Flash to other mobile platforms. As Adobe’s Chief Technology Officer Kevin Lynch explained, We are now on the verge of delivering Flash Player 10.1 for smartphones with all but one of the top manufacturers. This includes Google’s Android, RIM’s Blackberry, Nokia, Palm Pre and many others across form factors including not only smartphones but also tablets, netbooks, and internet-connected TVs. Could the iPhone and iPad’s lack of Flash support be a deciding factor in consumers’ decisions not to buy an Apple device?

My Prediction for Flash

I suspect that as HTML5 gains prominence, Flash will — eff that, it should — shift from an authoring environment for its proprietary SWF format to one that generates HTML, CSS, JS and SVG code for the browser. I think the building blocks for such software are in place. Flash Builder (formerly Flex Builder) for example, eliminates (most of) the need for FLA files. Perhaps developers will one day use a mix of ActionScript and JavaScript in the Flash Builder authoring environment to create web-ready assets and animation that don’t require a browser plug-in.

Mobile-friendly Web Development Right Now

Despite the fact that Flash is supposed to come to every other mobile platform, Apple’s decision to keep Flash off of the iPhone, iPad, and iPod Touch is not without impact. Apple still runs the smart phone market; in some ways they drive the mobile web. That means the prudent path is (still) progressive enhancement, and ensuring that your critical content and navigation are built using HTML.

So will I buy an iPad?

Nope. I have a laptop, a smart phone (a T-Mobile G1), a desktop and an iPod Touch. To me, the iPad is that weird spot between my smart phone or iPod Touch and a laptop with the convenience of neither. It doesn’t have the pocket-sized portability of my iPod Touch or my phone. And it doesn’t (yet) have the robust features of a laptop — USB ports, optical media drives, and the ability to install any app. I can’t justify the value for the price.

Besides, I still much prefer books to e-readers. I can sell books, trade books, leave books, loan books, and get books wet. I am not about to soak in the tub with a $300 device, but I would with an $11 book.

What do you think about the iPad, Apple’s decision, or the future of Flash and HTML5?

¹ Many of these apps could also be built using HTML, CSS and JavaScript, but there’s no money in that either.

² There are scripts available to make IE act right, of course. ExCanvas, for example, mimics support for the canvas element in IE. Simple HTML5 isn’t much different from HTML 4.01. You can actually forge ahead with HTML5 now if you don’t need advanced features like DOM Storage.