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.

Flash, like JavaScript, more-or-less adheres to a same-origin policy by default. Under a same-origin policy, requests for data must come from the same scheme, hostname, and port. If http://foo.example tries to request data from http://bar.example, the request will usually fail.

Same-origin policies are designed to prevent the unauthorized leakage of data to a third-party server. Without it, a script or SWF hosted on http://mightbeevil.foo could read data hosted on http://goodsite.foo and send it to http://muhahahaevilsite.foo. This kind of cross-domain activity could be used to exploit cookie and authentication data. It’s clearly a bad thing.

Recent browsers have safeguarded against these kinds of cross-site scripting exploits by preventing JavaScript from making cross-origin requests. XMLHttpRequest, for example, will throw a security exception if you attempt a cross-origin request.

Flash, meanwhile has long supported a means for enabling cross-origin requests: the policy file. The policy file is a way of white-listing requests for data or credentials from specific origins. It lives on the server from which you are requesting data, and gives the Flash player a “yay” or “nay” when asked whether the request from a specific origin should be allowed to complete.

Cross-origin restrictions, though necessary, are also quite limiting. You can’t (or couldn’t), for example, request data for a mash-up using XMLHttpRequest. Though there are workarounds — using dynamic script insertion, or using the document.domain — those workarounds also leave the DOM vulnerable to cross-site scripting.

To to mitigate the dangers of cross-site scripting while still enabling it, the W3C is developing the Cross-Origin Resource Sharing (CORS) specification. It functions similarly to Flash’s cross-domain policy file, but uses HTTP headers instead of an XML configuration file.

CORS request headers are automatically generated by conforming browsers when a script attempts a cross-domain request. Response headers must be set in the server’s configuration file, or dynamically per URL using a server-side language.

Let’s compare a sample cross-domain.xml file to how we’d achieve the same thing using CORS.

Cross-origin requests from Flash

To use the domains from our example above, if http://mightbeevil.foo made a request to data hosted on http://goodsite.foo, http://goodsite.foo would need to permit the request by including mightbeevil.foo it in its policy file. For example:

<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
    <allow-access-from domain="mightbeevil.foo"/>
</cross-domain-policy>

This file must be stored in the web root of http://goodsite.foo. It explicitly permits mightbeevil.foo — and permits only mightbeevil.foo — to make requests for its data (from within a Flash movie).

Cross-origin requests from the DOM

To reuse our example from above, let’s use XMLHttpRequest to make a request from http://mightbeevil.foo to http://goodsite.foo.

var xhr, onLoadHandler 

onLoadHandler = function(event){
     alert('It is done!');
}

xhr = new XMLHttpRequest();
xhr.open('GET','http://goodsite.foo/data.json');
xhr.onload = onLoadHandler;
xhr.send(null);

It looks just like a regular XHR request, except for the fact that we’re requesting data from another origin. Let’s take a look at our headers.

Accept:text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.7
Accept-Encoding:gzip, deflate
Accept-Language:en-us,en;q=0.5
Connection:keep-alive
Host:goodsite.foo
Origin:http://mightbeevil.foo
Referer:http://mightbeevil.foo/make_cross_domain_request/
User-Agent: Awesome/9.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0) FantasticEngine/8889876 Awesome Browser/9.0

Notice that our headers include Origin:http://mightbeevil.foo.

Goodsite.foo responds with the following headers.

Access-Control-Allow-Origin:http://mightbeevil.foo
Connection:Keep-Alive
Content-Length:1349
Content-Type:application/json
Date:Mon, 26 Sep 2011 04:44:50 GMT
Keep-Alive:timeout=5, max=100
Server:Apache/2.2.20

Here we see that an Access-Control-Allow-Origin response header is returned by the server. Like allow-access-from, it indicates which domain(s) are allowed to make requests. Here, we want to know whether mightbeevil.foo is allowed to request data. It is, so the request will be completed.

Acceptable values for Access-Control-Allow-Origin include an origin (scheme + host + port), a comma-separated list of origins†, or a wildcard (*). As with cross-domain.xml, if the value of Access-Control-Allow-Origin had instead been http://notevil.foo, the request would have failed. Using a wildcard allows requests from any domain.

Of course, both specifications are more complex than what I have covered here. These examples illustrate how to enable a basic cross-origin request. It is also possible with both CORS and Flash to permit or exclude custom headers. And in the case of CORS, it is possible to use methods such as PUT or DELETE if the user agent supports it.

Learn more

• Flash cross-domain policy file specification
• Cross-origin Resource Sharing
• XMLHttpRequest Level 2

† Most browsers do not yet support multiple origin values. The specification is also a working draft, and subject to change.

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

Not really. Browsers ignore the unit type when the value is 0. That’s why margin: 0 is the same as margin: 0em and margin: 0px. If it’s zero, after all, what does the unit matter? That explains why the second item’s transition worked well.

But when there is a mis-match between the type of unit, most browsers — Firefox is the exception to date — won’t transition between the two values. The result? It jumps. The fix: make sure that you are transitioning between two values of the same unit (or transitioning from a 0 start value).

Since this is better shown than written about, this demo illustrates what I mean.

What is Opera Turbo?

Opera Turbo is a feature of Opera Mobile and Opera Desktop. Turbo compresses data so that pages and images load faster over slower connections.

Compression takes place on one of Opera’s proxy servers. As with Opera Mini, the request goes from the desktop or mobile device to the proxy server. The proxy makes the request to the user-requested domain, receives and compresses the response, and returns it to the browser.

To see this in action, download Opera if you haven’t already. Launch it, then visit Whats My IP Address?. Make note of the reported IP. Then turn on Turbo using the icon in the status bar () and refresh the page.

When blocking by IP goes bad

This generally works smoothly until a server blocks a specific IP address. For example, if you visit Justin.tv, using Opera with Turbo enabled, you will received the following message: You have been blocked from using Justin.tv services, for more information please visit this page to learn more.

A rogue user caused Opera’s server IP address to be blocked, but the IP that originated the abusive request was not. That’s, obviously, a bad thing for Opera Turbo users.

Similar problems occur can occur with sites that geo-restrict content by IP address.

The X-Forwarded-For Header

That’s where the X-Forwarded-For header comes in. When in Turbo mode (or when using Opera Mini), Opera sends an additional X-Forwarded-For header that includes the IP address of the originating device.

The headers below are an example of what Opera desktop sends when Turbo is disabled.

User-Agent: Opera/9.80 (Macintosh; Intel Mac OS X 10.6.8; U; Edition Next; en) Presto/2.9.181 Version/12.00
Host: webinista.com
Accept: text/html, application/xml;q=0.9, application/xhtml+xml, image/png, image/webp, image/jpeg, image/gif, image/x-xbitmap, */*;q=0.1
Accept-Language: en,en-US;q=0.9,ja;q=0.8,fr;q=0.7,de;q=0.6,es;q=0.5,it;q=0.4,pt;q=0.3,pt-PT;q=0.2,nl;q=0.1,sv;q=0.1,nb;q=0.1,da;q=0.1,fi;q=0.1,ru;q=0.1,pl;q=0.1,zh-CN;q=0.1,zh-TW;q=0.1,ko;q=0.1
Accept-Encoding: gzip, deflate
Cache-Control: no-cache
Connection: Keep-Alive

And this next set of headers is an example of what Opera sends when Turbo is enabled.

Host: webinista.com
Accept-Language: en,en-US;q=0.9,ja;q=0.8,fr;q=0.7,de;q=0.6,es;q=0.5,it;q=0.4,pt;q=0.3,pt-PT;q=0.2,nl;q=0.1,sv;q=0.1,nb;q=0.1,da;q=0.1,fi;q=0.1,ru;q=0.1,pl;q=0.1,zh-CN;q=0.1,zh-TW;q=0.1,ko;q=0.1
User-Agent: Opera/9.80 (Macintosh; Intel Mac OS X 10.6.8; U; Edition Next; en) Presto/2.9.181 Version/12.00
Accept: text/html, application/xml;q=0.9, application/xhtml+xml, image/png, image/webp, image/jpeg, image/gif, image/x-xbitmap, */*;q=0.1
X-Forwarded-For: 78.93.91.42

Should you need to block a specific IP, you can check whether the X-Forwarded-For is included as a request header and if so, compare that IP to your list of blocked IPs.

In any case, the slides — which is really just one really long, really heavy HTML file with inline CSS, JS, and images (thanks, data URIs!) — are now available.

Data URIs have been available for quite a while now, though Internet Explorer versions 5-7 don’t support them. They are string representations of file data, typically base-64 encoded. When used as an img or url() source, they reduce the number of HTTP requests. And as we know, making fewer HTTP requests is the number 1 rule of web site optimization … except y’know when it creates a 1.8MB HTML file .

It’s simple enough to convert files to a base64 encoded string with a few lines of code. Let’s assume we want to convert a file named “cars.png.” In PHP it might looks like this:

$filename = 'cars.png';
$ext = pathinfo($filename,PATHINFO_EXTENSION);
switch($ext){
     case 'gif':
          $type = 'image/gif';
          break;
     case 'png':
          $type = 'image/png';
          break;
     case 'jpeg':
          $type = 'image/jpeg';
          break;
}
$fileHandler = fopen($filename,"r");
$data = fread($fileHandler, filesize($filename));
print 'data:'.$type.';base64,'.base64_encode($data);

Despite the ginormous HTML file, I still think it’s useful for it to be a single-file package. After all, you only have to save and keep track of that one HTML file.

Application Cache

Bonus: you can view it offline because I took advantage of Application Cache.

Application Cache is an awesome technique that can speed up load times by caching data locally. But it also ensures that if connectivity is lost or unavailable, you can still visit that URL and have access to the content. This assumes, of course, that you’re using a browser that supports AppCache. The latest versions of most major browsers, including Opera 11+, do.

Application Cache is also quite simple — at least the basics of it are. First, add a manifest attribute to your <html> element.

<html manifest="/path/to/manifest.appcache">

Then create a manifest file. It’s a simple, plain text file that must be sent with a Content-type: text/cache-manifest header. Typically the file name should have an .appcache extension, though it will work (for now, at least) if it’s named foo.manifest provided you send the correct content type header.

A basic manifest — the one I’ve used for the slides in fact — looks like this:

CACHE MANIFEST

CACHE:
index.html

That’s it. We have told our browser to cache this page. You can also specify which files the browser should always retrieve from the server with NETWORK, or which files to use if you need to fall back. It’s fascinating stuff. For more, check out HTML5 Doctor’s post, Go offline with application cache.

I’ll be at Open Web Camp!

I’ll be speaking more about AppCache and other things at Open Web Camp July 16 at Stanford University in Palo Alto. Come say hi.

Opera news, in case you missed it:

• Opera 11.50 was released Tuesday
• Opera Mini 6.1 and Opera Mobile 11.1 were released yesterday (6/29)

I’m most excited that the Opera Mobile rendering engine is now running Presto 2.8 which means it now supports multi-layouts (we run on tablets too!), session history and navigation, and the File API (among other things).

]]> http://tiffanybbrown.com/2011/06/30/xhr2-cors-slides-some-appcache-fu-openwebcamp-and-opera-news/feed/ 3 http://tiffanybbrown.com/2011/05/18/launching-remote-debugging-in-google-chrome-mac-os-x/ http://tiffanybbrown.com/2011/05/18/launching-remote-debugging-in-google-chrome-mac-os-x/#comments Thu, 19 May 2011 01:12:27 +0000 tiffany http://tiffanybbrown.com/?p=5972 So while I was on vacation for Wedding Week, Google done went and made an announcement about new Chrome developer tools. It includes a fancy new remote debugging feature. I will explain to you how to get to it in a bit, since the directions are slightly different for Mac OS X users.

Before I do that, though, let me say something.

OPERA DRAGONFLY HAD REMOTE DEBUGGING FIRST.

Now:

1. Make sure you are running the latest version of Google Chrome (or Chrome Canary).
2. Fire up Terminal.app (or iTerm if that’s what you’re using).
3. Type

   /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --remote-debugging-port=9222

   and hit the return key (note we’re escaping spaces with a \).

This is a feature that has been added to the WebKit core. Expect to see it in Chromium, Safari, and other WebKit-based browsers in due time.

What Mazzola’s CSS3 buttons look like in Opera 11.10.

In January, Chad Mazzola posted a Thoughtbot article titled Make CSS3 buttons like a boss (via nico604). It is a great read for designers, but it does have one glaring omission: no Opera support.* (I know right? Who does that?)

So let’s improve Mazzola’s code to add Opera support and use standard, prefix-less properties where we can.

Opera and Linear gradients

As Mazzola points out, the light source for these buttons is coming from overhead, giving highlights at the top edge, but darkness and shadows at the bottom. He starts with linear gradients for Firefox and Safari/Chrome.

button {
  background: #3b88d8;
  background: -moz-linear-gradient(0% 100% 90deg, #377ad0, #52a8e8);
  background: -webkit-gradient(linear, 0% 0%, 0% 100%, from(#52a8e8), to(#377ad0));
}

We will add a linear gradient style for Opera.

button {
  background: #3b88d8;
  background: -moz-linear-gradient(0% 100% 90deg, #377ad0, #52a8e8);
  background: -webkit-gradient(linear, 0% 0%, 0% 100%, from(#52a8e8), to(#377ad0));
  background: -o-linear-gradient(90deg, #377ad0 0%, #52a8e8 100%);
}

Note that Opera’s syntax is different from that of WebKit’s or Firefox‘s implementation. It’s closer to the current version of the specification. Since this is a simple gradient, we could also use a simpler syntax for Opera: -o-linear-gradient(#377ad0, #52a8e8). Read more about linear gradients in Opera.

The syntax for borders is the same in Opera as it is in Firefox, Internet Explorer, Safari and Chrome. We can skip that section. But we can adjust Mazzola’s box-shadow styles to reflect current browser support.

Browsers have pretty much standardized their implementations of box-shadow. The appearance varies slightly, but the syntax is the same. That means this code:

button {
  -moz-box-shadow: inset 0 1px 0 0 #72b9eb, 0 1px 2px 0 #b3b3b3;
  -webkit-box-shadow: inset 0 1px 0 0 #72b9eb, 0 1px 2px 0 #b3b3b3;
}

can become:

button {
  box-shadow: inset 0 1px 0 0 #72b9eb, 0 1px 2px 0 #b3b3b3;
}

The above works in the latest versions of all major browsers, including Internet Explorer 9. If you’d like, you can retain the -moz- and -webkit- prefixes for older versions of those browsers.

Now let’s look at the styles for the :hover state. Here, Mazzola has applied a linear gradient and a box shadow. Again we will add a gradient for Opera and change the prefixed box-shadow properties to use the unprefixed ones. For future-compatibility, let’s also add an unprefixed, spec-compliant linear-gradient (which we can also do above).

button:hover {
  background: #2a81d7;
  background: -moz-linear-gradient(0% 100% 90deg, #206bcb, #3e9ee5);
  background: -webkit-gradient(linear, 0% 0%, 0% 100%, from(#3e9ee5), to(#206bcb));
  background: -o-linear-gradient(#206bcb, #3e9ee5); /* using the simpler syntax */
  background: linear-gradient(#206bcb, #3e9ee5);
  border-top: 1px solid #2a73a6;
  border-right: 1px solid #165899;
  border-bottom: 1px solid #07428f;
  border-left: 1px solid #165899;
  box-shadow: inset 0 1px 0 0 #62b1e9;
  cursor: pointer;
  text-shadow: 0 -1px 1px #1d62ab;
}

Repeat these replacements for the button[disabled] state.

Though Internet Explorer 9 doesn’t support CSS gradients, you could use an SVG gradient as a background image. You can also use a bitmap image file for older versions of all browsers.

And that’s how to make CSS3 buttons like a boss.

*To be fair: Opera didn’t support linear gradients at the time. Support was added in Opera 11.10, released in March 2011. But Opera did support for prefix-less versions of box-shadow and background-clip. You do not, however, need to use background-clip to make these buttons work in Opera.

Last week’s big news in browser land: the release of an Opera development channel version: Opera Next. In April, Firefox announced its rapid release channel browser Aurora. And last week, Chrome/Chromium finally released Canary for Mac (Canary for Windows was released in July, 2010).

What does this mean? In all three cases, it means we can now run pre-beta versions of browsers alongside stable versions. Upgrades to the dev channel happen automatically and won’t affect our main installations. Finally, we can run multiple browser version installs without tricks, hacks, or running a browser from a disk image.

Download Opera Next from our snapshot server.

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

• don’t require the additional HTTP request of an image file.
• are easier to modify than image files.
• “weigh less” than most image files.

That’s the ideal, at least. In their current state, gradients are actually a hot mess. The reality?

• The specification is still in flux.
• Full gradient support is not available in all modern browsers. (For now, Opera 11 only supports linear gradients.)
• Many older, though relatively recent versions of browsers (Internet Explorer 8 & 9, Opera 10 Desktop, Opera Mobile, and Opera Mini, for example) don’t suport CSS gradients at all.

So, how can developers take advantage of gradients and still support older browsers? Let’s look at some approaches.

Set a background color

Take a look at the following CSS:

#linear{
    width:400px;
    height:300px;
    background-image: -moz-linear-gradient(top left, #f60 0%, #c09 50%, #fc0 100%);
    background-image: -webkit-gradient(linear, 0% 0%, 100% 100%, from(#f60), to(#fc0), color-stop(0.5,#c09) );
    background-image: -o-linear-gradient(top left, #f60 0%, #c09 50%, #fc0 100%);
}

This is a fairly common scenario. The developer (*cough*me*cough*) covered most of her bases, but forgot one: browsers that don’t support gradients at all. You can see what this looks like in Internet Explorer 9 (see Figure 1).

Figure 1. Internet Explorer 9 doesn’t yet support CSS gradients. This is what it looks like if you don’t supply a background color.

Now look at the following CSS:

#linear{
    width:400px;
    height:300px;
    background-color: #333;
    background-image: -moz-linear-gradient(top left, #f60 0%, #c09 50%, #fc0 100%);
    background-image: -webkit-gradient(linear, 0% 0%, 100% 100%, from(#f60), to(#fc0), color-stop(0.5,#c09) );
    background-image: -o-linear-gradient(top left, #f60 0%, #c09 50%, #fc0 100%);
}

Here we’ve set a background image, but we’ve also set a background color. Browsers that don’t support CSS gradients will ignore the last three lines. (Note: each browser also ignores the other browsers’ vendor-specific prefixes.)

Setting a background color is the easiest fall back for older / less modern browsers.

Set a background image using an external file

Consider the following CSS.

#linear{
    width:400px;
    height:300px;
    background-image: url(migas.jpg);
    background-image: -moz-linear-gradient(top left, #f60 0%, #c09 50%, #fc0 100%);
    background-image: -webkit-gradient(linear, 0% 0%, 100% 100%, from(#f60), to(#fc0), color-stop(0.5,#c09) );
    background-image: -o-linear-gradient(top left, #f60 0%, #c09 50%, #fc0 100%);
}

In this example, we’re taking advantage of how browsers apply the cascade. As it turns out, Opera 11, Chrome whatever-the-heck-version-it’s-up-to, and Firefox 4 will not make the HTTP request for the external file. Safari, however, does (see Figure 2). Internet Explorer 9 (and less-modern browsers) will only load the external file. Depending on your audience, this may be an acceptable alternative.

Figure 2. Safari downloads all images. Click to embiggen.

Note: I have just barely tested this in mobile browsers. (Opera Mobile 11 doesn’t support gradients. Users will see the external image).

Use SVG gradients to create a background image

Internet Explorer 9 and Opera 10 (including Mobile) do not support CSS gradients. They do, however, both support the use of SVG images as background images. Another alternative to using external images, then, is to use an SVG file.

#linear{
    width:400px;
    height:300px;
    background-image: url(gradient.gif);
    background-image: url(gradient.svg);
}

This example works in all current desktop browsers, and most mobile browsers. Safari 5, again, will download both images. Most others will download the latter SVG image. The advantages here are clarity and (arguably) ease of maintenance. Want a different gradient? Change the images.

You should be aware, though, that some recent(-ish) versions of mobile WebKit — such as the T-Mobile myTouch 4G browser — don’t support SVG backgrounds. You’ll still need to add a linear gradient for those browsers, or set a background color.

Or keep doing what we’ve been doing

Of course, the growth of SVG and CSS gradients support doesn’t preclude using GIF, PNG or JPG gradients. The biggest point in favor of using bitmap images is that they still work in older browsers and current ones.

As with any aspect of web development, the right approach should balance concerns of maintainability, file size, and the browser distribution of your audience.

You left out linear-gradient!

I left it out of the examples above for two reasons: (1) simplicity; and (2) the syntax could change (though if I had to predict, it won’t change by much). Be forward-thinking! There are very few reasons not to include the proposed linear-gradient syntax in your code.

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.

That means the specification is stable. Browser vendors can implement these features without a vendor prefix if they haven’t already.

border-radius support

Preceding to this move from Working Draft to Candidate Recommendation: support for border-radius (and border-top-right-radius, etc.) in Opera 10.5+ (current version is 11.01), Safari 5+ and Chrome 5+ (current version — as of February 12, 2011 — is 9.0.597.102 beta).

That means this*:

div{
	-moz-border-radius: 10px;
	-webkit-border-radius: 10px;
}

Can safely become:

div{
	-moz-border-radius: 10px;
	border-radius: 10px;
}

Yep. You can drop -webkit- from your border-radius properties long as you don’t mind your sexy rounded corners not appearing in older versions of WebKit-based browsers (and you’ve been able to do so since June 7, 2010).

Versions of Opera prior to 10.5 didn’t support border-radius, even with a vendor prefix. Ditto Internet Explorer 7 and 8.

Internet Explorer 9 and Firefox 4 will both support border-radius. IE9 pushed its Release Candidate February 11, 2011. Firefox 4 released its 11th beta February 8, 2011.

* But the cool, forward-thinking kids were already including border-radius, even before Opera 10.5 supported it.