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.

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

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.

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.

In order to release an iPhone application without having to submit it to Apple’s insane App Store process, developers could just use Web technologies and create Web apps instead of native apps.

In other words, iPhone developers are doing it wrong. By focusing on native applications, they are subjecting themselves to Apple’s approval process unnecessarily. Safari, he argues, is all most application developers need, and the reluctance of iPhone developers to embrace web technologies has more to do with snobbery than functionality.

The fundamental problem on the iPhone is not Apple’s App Store approval policies, but the iPhone developers’ arrogant disdain for Web technologies. … They dismiss Web technologies as toys for children. JavaScript is just this little language that cannot possibly compare to real technologies such as the one they’re using. HTML is too simple. Real programmers don’t do that stuff. As to Web developers, they are just glorified pixel-pushers that should in no circumstance be taken seriously.

I agree that most iPhone applications don’t need to be native ones. I also agree that many developers — not just iPhone developers — dismiss client-side programming as kid stuff.

I suspect, however, that iPhone developers really prefer native applications because they’re trying to make money. Apple’s App Store lets developers get paid and helps them protect their product with a degree of digital rights management the web doesn’t provide.

TraceMonkey, Resig explains, uses a computing technique known as trace trees (PDF) which adds just-in-time native code compilation to SpiderMonkey, Firefox’s current rendering engine.

What does this mean? As Resig explains:

It means that JavaScript is no longer confined by the previously-challenging resource of processing power. With this improvement it’s leap-frogged any sort of traditional and has gone head-to-head with computationally-powerful languages like C.

In other words, we’ll get JavaScript processing speeds that are Usain Bolt-on-crack fast, opening the door for more powerful JavaScript-powered applications.

Firefox’s announcement comes a few months after the WebKit team’s announcement of SquirrelFish, which will be the JavaScript engine used in Safari 4.

Resig and Brendan Eich also point out that these TraceMonkey improvements (and presumably SquirrelFish’s improvements) in conjunction with HTML 5‘s canvas element will mean we’ll see some slick JavaScript animation and game experiences, such as this one by Zachary Johnson.

The obvious roadblock to widespread adoption of all of this whiz-bangy JavaScript+<canvas> goodness is, of course, Internet Explorer. Internet Explorer 7 does not support the canvas element. Version 8 of the browser will not, although there is a workaround for IE7 available.

Still, without the dominant web browser on board — and conceivably not coming on board for at least a few years — the widespread use of JavaScript animations may not take off for some time.

Want to check see TraceMonkey in action? Download a nightly build of Firefox (codenamed Minefield), and in the about:config panel, set javascript.options.jit.content equal to true.

Also check out Mike Schroepfer’s screencast What can you do when your browser is 7 times faster?

It takes advantage of Firefox’s Gecko rendering engine for an easy-to-use application for making layouts. You can import bitmap images, add rich text or plain text, and when you’re done, export your drawing as a PNG file.

One downside: it runs inside of Firefox. You have to start Firefox in order to use Pencil. It is, however, free and open source. I used it (briefly) on a Mac running Leopard (10.5.4) with no problems. It’s also been tested on GNU/Linux, Windows XP and Vista.

Prism and other single-site / site-specific browsers

The richness of the Pencil Project made me think about the browser as an application environment. And that brings me to Prism (formerly WebRunner), Mozilla’s single-site browser project.

Prism — available as its own package and as a Firefox extension — lets you turn any web site into a quasi-standalone application.

At first glance, a single-site browser seems pointless — dude, just open another tab. But I find that the minimal GUI of an SSB really lets me focus on the task at hand. It’s particularly nice when used with web applications such as Google or Zoho, or blogging interfaces.

Prism isn’t the only single-site browser available. Mac users, can check Fluid, which is based on WebKit/Safari. Windows users have Bubbles.

Browser as platform = The future of applications?

Today, you still need an operating system on which to run Firefox and Prism. But is there room for a super-minimal OS with a Gecko-based (or WebKit-based, etc.) GUI? I’m thinking about one that runs web applications in a single-site browser (gOS is close, as is the iPhone) and still allows for richer applications such as the Pencil Project (Flock skims the surface of this). As both browsers and the languages we use to develop web sites become more powerful and feature-rich, (when?) will the browser truly become the operating system, rather than run on top of it?

Related

• Recommended: “From Browser to Platform: Mozilla Rises”
• Bubbles, a single-site browser for Windows
• Fluid, a single-site browser for Mac OS X
• Prism, a cross-platform, single-site browser and Firefox extension

[Pencil Project found via WebAppers]

Acid1 and Acid2 tested for compliance with CSS 1 and CSS 2 specifications. Acid3 also tests for support of DOM Scripting / ECMAScript, SVG and webfonts.

Safari 3 and Opera 9 pass the Acid2 test, as does the beta version of Firefox 3. Version 8 of Internet Explorer will also pass the Acid2 test.

Here’s how today’s leading browsers handle Acid3 (check out the reference image). Each image links to a larger screenshot.

Firefox 2

Opera 9.26

Internet Explorer 6

Internet Explorer 7

Safari 3

Firefox 3 Beta

The LitePacific hack for example, works well in Internet Explorer 6 and 7, but also affects Safari. If you support Safari, you will also need to create a separate set of style sheet hacks to address differences in the way Safari and IE render pages.

CSS hacks also make your style sheets much harder to read. With conditional comments, you have to maintain multiple style sheets, but each style sheet is cleaner and clearer. Granted, with each new version of Internet Explorer, you have to update your header templates. But updating a header file offers far less risk than integrating new hacks into your style sheets.

Which necessary evil do you prefer? CSS hacks or conditional comments? Speak your piece in the comments.

May I also suggest giving Shiira a whirl? Built on WebKit — the same rendering engine behind Safari — but with some nifty features.

Related: Thoughts on Safari 3 for Windows

Some stuff I missed from last week, and a few tidbits from this morning.

IE7 Is Coming This Month…Are you Ready?

Unless you’re using some serious CSS ninjitsu, you’re ready.

eHub Interviews adaptiveblue

Adaptiveblue is a Firefox extension that uses semantics and context to create a richer browsing experience … er, I think that’s right.

PHP developers most likely to switch to Rails

I suspect that a lot of this has to do with many PHP coders being tinkerers on shared hosts. And RoR is The Hot. New. Thing. in web hosting. But that’s just a guess. I’m not about to fork over $795 to find out for sure . [Via PHPDeveloper.org]

Objectifying JavaScript

How to create and work with objects for cleaner JavaScript code.

For Vista, WGA gets tougher

While I understand Microsoft wants to protect its intellectual property, I just don’t trust them to get their Software Protection Platform right. My current PC may just be the last Windows machine I ever own.

Safari and Javascript debugging

An oldie, but a goodie, particularly if you’re new to front-end development in Safari.

]]> http://tiffanybbrown.com/2006/10/09/links-for-october-10-2006/feed/ 4