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.

Take a look at the following code:

var d = 'test.js';
var s = document.createElement('script');
s.setAttribute("type", " text/javascript"); // note the leading space
s.src = d;
document.querySelector("body").appendChild(s);

That space between the " and text/javascript will cause Opera to fail. The script won’t load and or execute. Other browsers will handle that space with no problem, however. If you aren’t testing your site in Opera, you would miss this issue.

Keep in mind that this isn’t really a bug. It’s a difference in implementation. Opera is more strict about spaces in attributes than most browsers. The specification is either muddy or silent on this issue (depending on which version you consult). Yes, it’s something the development team is aware of and discussing internally. Yes, this also applies to the <script> tag.

In the meantime, make sure that you don’t include spaces at the beginning or end of the value of your type attributes.*

(Or leave it out if you’re using the HTML5 doctype.)

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!

The problem above was caused by three things working in concert.

1. An HTML page was served with a Content-Type: application/xhtml+xml; response header. Here’s what the server response headers look like:

   HTTP/1.1 200 OK
   Cache-Control: no-cache
   Pragma: no-cache
   Content-Length: 4001
   Content-Type: application/xhtml+xml; charset=utf-8
   Expires: -1
   Server: Microsoft-IIS/7.0
   Set-Cookie: ASP.NET_SessionId=x0zeoofiwnk2lmz5q4pcso45; path=/; HttpOnly
   X-AspNet-Version: 2.0.50727
   X-Powered-By: ASP.NET
   Date: Wed, 09 Mar 2011 23:17:34 GMT
   

   Opera then parsed it according to X(HT)ML rules instead of HTML rules. (Note: this seems to be a problem with IIS servers.)

2. An empty element was not self-closed. That <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> tag should be <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />. Remember your space-slashes people!
3. A missing DOCTYPE means that even if errors 1 and 2 were fixed, Opera would still parse the document as XML instead of as XHTML. Opera users (and Firefox users) would get that lovely “This document had no style information” screen.

While many browsers ignore mismatches between the document’s markup and the server response header, Opera does not. You also can’t be sure that future versions of common browsers won’t as more browsers adopt HTML5 parsing rules.*

In the current version of the HTML specification, a document served as text/html is supposed to be parsed according to HTML rules. A document served with an application/xhtml+xml MIME type must be parsed according to the stricter markup rules of X(HT)ML.

Let me emphasize the above point: server MIME types — not DOCTYPES — determine which parsing rules the browser applies.**

So what does this mean? It means you need to be a better coder. Make sure that what your server says agrees with what your document delivers. If you can’t configure the server, make sure you code your documents according to the MIME type your server says it is. Use a DOCTYPE. Understand the differences between XHTML and HTML. And, as always, validate your code.

* This is a bad name for it, but I can’t think of a better one.

** That’s how it’s supposed to work at least.

A little over a week ago, I gave a talk to the Los Angeles HTML5 User Group about forms in HTML. I said something that was incorrect in the talk, and had a faulty example in the slides (that’s what happens when you pull it together in a day!).

First the correction: I had a faulty slide in my talk, so it looked like a semicolon or space were allowable delimiters for <input type="email" mutiple>. That’s not the case. Only the comma is an acceptable separator.

And the clarification: I added a feature check to the fall back demo so that it better demonstrates how to check whether the browser in question fully supports HTML5 form error checking.

Those revisions are in the slides now (a second revision). You can view them or download a ZIP file of the slides and demos.

Using <input type="email"> for their log in form. This is how that attribute works in a capable browser.

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.)

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.

Web applications should have the ability to manipulate as wide as possible a range of user input, including files that a user may wish to upload to a remote server or manipulate inside a rich web application. This specification defines the basic representations for files, lists of files, errors raised by access to files, and programmatic ways to read files. The interfaces and API defined in this specification can be used with other interfaces and APIs exposed to the web platform.

From File API working draft by Arun Ranganathan of Mozilla Corporation.

This API, if adopted by major browser vendors will allow client-side file manipulation and asynchronous uploads.

As far as I know, asynchronous uploads are only possible now using a combination of Flash and JavaScript such as SWFUpload. Flickr’s uploader uses a similar technique. Client-side file processing is impossible without a plug-in.