HTML5 One Time Submit

One of HTML5’s coolest features in my opinion is that forms are easier to build. Things like required, autocomplete, pattern make it much easier to create an intuitive form without having to jump through hoops and repeating efforts to do some basic form validation.

The one thing that I still see as missing is a one-time submit button. Many sites create transactions that should only be performed once. For example, when you click “place order”, you definitely don’t want your transaction being processed multiple times, so what websites do is disable the button after the first click. I’m not sure why, but this little pattern never quite made it into HTML5. I’d love to see something like this:

<input type="submit" id="process_order" transactionsafe="true"/>

Then when the submit button is pressed, it automatically sets the disabled attribute. Either on the server side (if you submit the entire page), or via JS (for a refresh-less UX) you could unset the disabled property should you want the user to be able to submit again (for example if the order failed).

It’s trivial, but we seem to use this pattern quite a bit. It would be nice to one day be able to do this without an event.

Make Login Pages Autofocus

I see this way too often and it gets on my nerves. If you have a page that’s main purpose is a form, such as a login page, please make the page autofocus to the first field in the form. Having to tab or click on the first field is a nuisance. Even big sites make this mistake.

If you don’t care about IE you can do it as simply as:

<form method="post" action="/">
<p>
    <label for="username">Username:</label>
    <input type="text" name="username" id="username" autofocus="autofocus"/>
</p>
<p>
    <label for="password">Password:</label>
    <input type="password" name="password" id="password" />
</p>
<p><input type="submit" name="login" value="Login"/></p>
</form>

Since autofocus is boolean you technically don’t even need to specify an attribute value.

To do it with IE in mind you could use the following JavaScript below the form (no library needed):

function focusForm(){
    setTimeout(function(){
        try {
            // id of element to focus on
            var elem = document.getElementById(‘username’);
            elem.focus();
            elem.select();
        } catch(e){}
    }, 50); // setTimeout to fix IE bug
}
focusForm();

Note the use of select() so if the form reloads due to an incorrect password the field is not just in focus but the contents highlighted. There is also a setTimeout() since IE, at least some older versions have trouble with this if it happens too quickly. 50 should be fast enough that it won’t be noticed by humans.

See how simple that is? No excuses for not fixing this 😉 .

localStorage With Cookie Fallback

I mentioned the other day that localStorage can be used as an alternative for cookies. The benefit is that localStorage doesn’t sent it’s data back on every request to the server like a cookie. Headers are uncompressed in http making that very costly. However not every web browser out there supports localStorage. Most however do.

Here’s an example based on jQuery and jQuery.cookie. It’s designed to turn objects into JSON and store the JSON representation. On retrieval it restores the object. This doesn’t handle things like expiring cookies (it simply defaults to 365 days). I just had this around from an old project with these very specific requirements and figured I’d post it as-is in case it can help anyone and to demonstrate. This isn’t ideal for reuse, but for someone playing with the idea, maybe it will motivate 😉 .

function storeData(type, obj){
    var data = jQuery.toJSON(obj);
 
    // If using a modern browser, lets use localStorage and avoid the overhead
    // of a cookie
    if(typeof localStorage != ‘undefined’ && localStorage !== null){
        localStorage[type] = data;
    }
 
    // Otherwise we need to store data in a cookie, not quite so eloquent.
    else {
        jQuery.cookie(type, data, { expires: 365, path: ‘/’ });
    }
}
 
function loadStoredData(type){
     var data;
 
    // If using localStorage, retrieve from there
    if(typeof localStorage != ‘undefined’ && localStorage !== null){
        data = localStorage[type];
    }
 
    // Otherwise we have to use cookie based storage
    else {
        data = jQuery.cookie(type);
    }
 
    // If we have data, lets turn it into an object, otherwise return false
    if(data){
        return jQuery.secureEvalJSON(data);
    }
    return false;
}

Pretty simple right? It’s still a key/value API.

Privacy Issues Behind localStorage

Browsers need to overhaul their privacy settings to account for things like localStorage and bring control back to the user. In the days of cookies it was relatively simple for a user to wipe any identifiers (excluding IP address) from their browser. Simply clear cookies.

Firefox has two basic abilities, you can clear cookies, or you can browse and delete cookies. That’s great but not terribly clear that there’s more than cookies.

Firefox Cookie Privacy

Chrome as far as I know has no cookie browser like Firefox has, but (edit: Erunno notes in the comments you can via chrome://settings/cookies) explicitly lets you “Delete cookies and other site and plug-in data”. That’s pretty good.

Chrome Cookie Privacy

Today, I think Safari’s UI is the closest to perfect. Each hostname shows exactly what it has. My only gripe is that Safari doesn’t let you see what’s there. That’s a “power-user” feature however and I think it does an adequate job regardless.

Safari Cookie Privacy

Websites use more than just cookies these days. I discussed this a little over a year ago. The reason evercookie is controversial is that browsers don’t quite give users the level of control (real or perceived) that they expect for objects other than cookies.

Here is another use case for why this is needed. Google Analytics is used on perhaps half the internet’s websites. It sets a cookie every time. That means 230 bytes added to every http request for a lot of websites. Google could switch to localStorage and free up that 230 bytes. While they technically could do this, in practice, this could create a firestorm of attacks against them. The problem is it would be spun as Google trying to evade cookie deletion and and a privacy violation. The same storm that evercookie created. I suspect that’s why it hasn’t been done to date. The truth is the Google Analytics team has done a lot for improving performance including making it entirely async. But this move would be controversial.

It’s no longer about “cookies”, but “user data”.

How Google Music Works

Google announced Google Music. Needless to say I was curious how they implemented an audio player in the browser. Most of the application is your run of the mill modern Web Application with lots of JavaScript. It looks like pretty much anything Google’s built in recent years. It doesn’t do anything really out of the ordinary for the most part. Until you get to the audio playback.

How the audio is played is interesting:

<div id="embed-container">
  <audio autoplay="autoplay" id="html5Player"></audio>
  <div class="goog-ui-media-flash">
    <embed wmode="window" pluginspage="http://www.macromedia.com/go/getflashplayer" type="application/x-shockwave-flash" seamlesstabbing="false" allowfullscreen="true" allowscriptaccess="sameDomain" bgcolor="#000000" flashvars="" src="r/musicplayer.swf" class="goog-ui-media-flash-object" name=":0" id=":0" quality="high" style="width: 1px; height: 1px;"></embed>
  </div>
</div>

You’re reading that right. That’s a HTML5 <audio/> tag. First time I’ve seen it appear in a major product. However as of this writing in Firefox, Safari, and Chrome on Mac OS X the Flash player seems to be used. I suspect, but can’t confirm that this may indicate a future intent of using HTML5 <audio/> in place of Flash. Flash is likely the default for now. But it’s still very interesting to see.

The audio itself seems to be 44,100 Hz 320 kb/s MPEG Layer 3 (MP3) audio. The samples I’ve looked at were encoded with LAME 3.98.2. Obviously if they intend to use HTML5 audio they will need to offer something other than MP3 at least for Firefox users. It’s not currently possible to serve everyone without multiple encodings. I don’t see that changing anytime soon.

The servers serving the media seem very similar to YouTube’s delivery servers for H.264 video. It’s progressive download, again just like YouTube. No DRM. I suspect there’s a shared history between this delivery system and YouTube or a very strong influence. But knowing how Google works, there’s likely a shared backend.

It’s pretty good stuff. I highly recommend checking it out. Google built a decent mp3 player in the cloud.

On The Future Of Flash

Adobe is killing Flash, as a plugin for mobile. This shouldn’t come as a surprise to anyone who works on the web. Anyone who knows me knows I’ve bet on HTML5 since the beginning and haven’t been ashamed to say it. I don’t do Flash. To quote Adobe:

Our future work with Flash on mobile devices will be focused on enabling Flash developers to package native apps with Adobe AIR for all the major app stores. We will no longer continue to develop Flash Player in the browser to work with new mobile device configurations (chipset, browser, OS version, etc.) following the upcoming release of Flash Player 11.1 for Android and BlackBerry PlayBook.

I strongly suspect that even this use case is limited and will experience the same fate as the Flash plugin within the next 24-36 months. HTML5 is supported by browsers, a browser is shipped with the OS and is highly optimized for what it’s running on. It’s also the ultimate in cross-platform. Why write Flash when you can do something for every platform and not rely on a vendor to abstract you?

Platforms like PhoneGap bridge the world of Apps and HTML5 quite nicely. Adobe bought Nitobi which develops PhoneGap, but PhoneGap is also going to Apache Software Foundation which means Adobe’s ability to derail the project would be somewhat limited if they wanted to go that route.

Quite a few Apps use HTML/JS extensively already. HTML5’s success is despite Apple essentially crippling the use of HTML5 in native apps by preventing UIWebView from taking advantage of the Nitro engine. If/when Apple gets to fixing this another barrier will be gone. I suspect Apple will eventually make scrolling that doesn’t suck on iOS easier. Right now Joe Hewitt’s Scrollability is likely your best bet.

Adobe goes on to say:

However, HTML5 is now universally supported on major mobile devices, in some cases exclusively. This makes HTML5 the best solution for creating and deploying content in the browser across mobile platforms. We are excited about this, and will continue our work with key players in the HTML community, including Google, Apple, Microsoft and RIM, to drive HTML5 innovation they can use to advance their mobile browsers.

Interestingly they left out that little browser vendor Mozilla. Perhaps because they are most likely targeting WebKit on mobile and that’s the common tie between those companies sans-Microsoft which they need IE support. If Adobe wants a future here they should learn quick that you can’t ignore platforms. My advice to Adobe is to make sure their solution allows developers to bring their product to any modern browser on any device.

Flash is the last plugin with real usage even on the desktop. This is the first step towards the concept of plugins in the browser going away. It’s unlikely many will see a need to go HTML5 on mobile and develop a separate Flash code base to do the same thing on a desktop. The name of the game these days is write once, run anywhere (credit to Sun for the slogan). Today marks the start of the decline of Flash.

As Brendan Eich best put it: “Always bet on JavasScript“. I have and I continue to do so. The Open Web is winning. Slowly but surely.

Things You’ll Love About Firefox 4.0

It’s that time again. Here’s my list of awesome things you’ll love about Firefox 4:

For Users

New Look For Tabs

New Tabs For Firefox 4
One of the first things that you’ll notice is tabs on top. This paradigm really makes more sense since the tab defines not just the content but the environment it’s viewed (prev/next button, URL bar). It’s also just much sleeker looking. After a few minutes you’ll likely agree this is a better approach than tabs under.

Another nice touch is if you enter a URL that’s already open in another tab, you’ll be given the option to switch to that tab. Perfect for those of us who end up with 50 tabs by lunch time.

It also just feels tighter and less intrusive on the web browsing experience.

Continue reading

On HTML5 And The Future Of Privacy

Today’s alarmist without much research news is “New Web Code Draws Concern Over Risks to Privacy” about HTML5 and its threat to privacy. How evil of HTML5 and its creators.

The Real Deal

Persistent cookies are nothing new. Essentially the strategy works like this: Store data everywhere you can on the users footprint, and if data it deleted in a few locations, you copy it back from another location the next time you can. It’s regenerative by design. A popular example is evercookie which uses:

  • Standard HTTP Cookies
  • Local Shared Objects (Flash Cookies)
  • Storing cookies in RGB values of auto-generated, force-cached PNGs using HTML5 Canvas tag to read pixels (cookies) back out
  • Storing cookies in and reading out Web History
  • Storing cookies in HTTP ETags
  • Internet Explorer userData storage
  • HTML5 Session Storage
  • HTML5 Local Storage
  • HTML5 Global Storage
  • HTML5 Database Storage via SQLite

Note that several of these aren’t HTML5 specific. More than one of which isn’t cleared by just “erasing cookies”.

HTML5 does add a few new possibilities, but they are also by design as easy to control, monitor and restrict as your browser (or third-party add-on) will allow. HTML5 storage mechanisms are bound to the host that created them making them easy to search/sift/manage as HTTP cookies. Much worse are some of the more obscure cookie methods (Flash Cookies, various history hacks). They don’t really provide any more of a privacy risk than what the browser already has been offering for the past decade.

To Shut Up The Geolocaiton Conspiracy Theorists

Before someone even attempts the “Geolocation API lets advertisers know my location” myth, lets get this out of the way. The specification explicitly states:

User agents must not send location information to Web sites without the express permission of the user. User agents must acquire permission through a user interface, unless they have prearranged trust relationships with users, as described below. The user interface must include the URI of the document origin [DOCUMENTORIGIN]. Those permissions that are acquired through the user interface and that are preserved beyond the current browsing session (i.e. beyond the time when the browsing context [BROWSINGCONTEXT] is navigated to another URL) must be revocable and user agents must respect revoked permissions.

Some user agents will have prearranged trust relationships that do not require such user interfaces. For example, while a Web browser will present a user interface when a Web site performs a geolocation request, a VOIP telephone may not present any user interface when using location information to perform an E911 function.

To my knowledge no user agent implements Geolocation without complying with these specifications. None.

No HTML5 Needed For Fingerprinting

Even if you do manage to wipe all the above storage locations, you’re still not untraceable. Browser fingerprinting is the idea that just your system configuration makes you unique enough to be traceable. This includes things like your browser version, platform, flash version, and various other bits of data plugins may additionally leak. The EFF recently did a rather impressive study to learn about the accuracy of this technique. Computers with Flash and Java installed sport 18.8 bits of entropy and result in 94.2% of browsers being unique in the EFF study [cite, pdf]. Of course their data was likely skewing towards more experienced web users who are more likely to have an assortment of customizations to their computer (specific plugins, more variety in web browsers, operating systems, fonts) than the average internet user. I’d wager that their data downplays the effectiveness of this technique.

The idea that HTML5 is a privacy risk is FUD. It doesn’t provide any worse security than anything else already out there. It’s actually easier to counteract than what’s already being used since it’s handled by the browser.

The Future

I still believe all browsers out there can do a much better job of protecting privacy when it comes to local data storage for the purpose of tracking. What I believe what needs to happen is web browsers need to start moving away from the “cookie manager” interfaces that are now a decade+ old and move towards a “my data management” interface that lets users view and delete more than just cookies. It needs to encompass all the storage methods listed above as supported by the browser. Hooks should also exist so that plug-ins that have data storage (like Flash) can also be dealt with using the same UI.

Additionally it needs to be possible to control retention policies per website. For example I should be able to let Google storage persist indefinitely, Facebook for 2 weeks, and Yahoo for the length of my browser session should I wish.

My personal preference would be for a website to denote the longest storage time for any object on a webpage in the UI. Clicking on it would give a breakdown of all hostnames that makeup the page, what they are storing and let the user select their own policy. With 2 clicks I could then control my privacy on a granular level. For example visiting SafePasswd.com would give me a [6] in the UI. Clicking would show me a panel this:

+------------------------------------------------------------------------------+
| My Data Settings for SafePasswd.com:                                         |
|                                                                              |
|  Host                        Longest Requested Lifespan    Your Choice       |
|                                                                              |
| *safepasswd.com              2 years                       [site default]    |
| googleads.g.doubleclick.net  6 years                       [browser session] |
|                                                                              |
|                                                                              |
|                                                       (Done)  (Cancel)       |
+------------------------------------------------------------------------------+

I could then override googleads.g.doubleclick.net to be for the browser session via the drop down if that’s what I wanted. I could optionally forbid it from saving anything if that’s what I wanted. I could optionally click-through for more detail or view the data to help me make my decision. Perhaps this would also be a good place for P3P like data to be available. One of the notable failures of P3P that impeded usage was it was never easy to view so it never caught on.

The browser would then remember I forbid googleads.g.doubleclick.net from storing data beyond my browser session. This would apply to googleads.g.doubleclick.net regardless of what website it was used on.

This model works better than the “click to confirm cookie” model that only a handful of people on earth ever had the patience for. It provides easy access to control and view information with minimal click-throughs.

It also makes a web page much more transparent to an end-user who could then easily see who they are interacting with when they visit one webpage with several ads, widgets, social media integration points etc.

One click to view data policies, two clicks to customize, three to save.

HTML5 is not a risk here. The web moving to HTML5 is like going from the lawless land to a civilized society where structure and order rule.

About HTML5 Boilerplate

I wanted to take a few minutes to discuss HTML5 Boilerplate, a template that’s rapidly going around the web development community. I’ve had a few email threads and chats about this recently and thought I’d just put all my thoughts together in one place now.

I’ll start by saying it’s not a bad template. It’s actually quite good and encompasses many best practices as well as incorporates fixes for many common problems (clearfix, pngfix). What I’d like to make note of is that it’s not really bringing you HTML5 and lots of what it does has nothing to do with HTML5.

Not Really HTML5

For starters you’re not really getting HTML5. HTML5 Boilerplate uses JavaScript library called Modernizr. As their website explains:

Modernizr does not add missing functionality to browsers; instead, it detects native availability of features and offers you a way to maintain a fine level of control over your site regardless of a browser’s capabilities.

It also lets you apply styles to the new semantic HTML5 elements like <header/>, <footer/> <section/>.

What don’t you get? Well for starters you’re missing <canvas/> and <video/>. Other than tag elements you’re also missing things like Gelocation, Drag&Drop, web storage, MathML, async attribute on <script/> to name a few. SVG?

Pretty much all the headliners in the HTML5 spec aren’t included. Some like <canvas/> could be helped by way of explorercanvas, but that’s not in there by default.

HTML5 Boilerplate also makes reference to things like Access-Control which still doesn’t work in older browsers. They also suggest setting mimetypes for HTML5 video. This isn’t by any means bad, but hardly makes <video/> useful to everyone. Browsers are still pretty fragmented between webm, ogg, and h.264 (mp4). Then you have older versions that support none of these.

Using gzip on ttf,otf,eot files seems to be a good idea. WOFF however are compressed and correctly excluded.

WTF Does This Have To Do With HTML5?

There are lots of things that I would consider best-practices, but would hardly consider to be HTML5. For example pngfix for IE6, .clearfix, apple-touch-icon, console.log wrapper being the most obvious.

Setting far-future cache times are good, and disabling Etag is a good idea, assuming you rename the file every time it updates. But what does this have to do with HTML5? Is this even practical for everyone?

Then there is some interesting css work like inline print block. There are also a couple of nice usability fixes that I like. Regardless, they are just good design and UX. Not HTML5.

As for the graceful degradation and mobile optimization… that’s design and css. There is no reason why any HTML4 or XHTML site couldn’t do that today. Most choose not to do so in favor of serving different content (including ads) to different devices.

Options -MultiViews… grumble. I’m not particularly fond of it, but again if it works for you, I wouldn’t push you away from it.

Removing www… I hate this one. In my experience the only people who insist upon this have never dealt with websites with high volume and had the requirement of using a CDN by way of a CNAME in front of your site (your domain must be an A record). What is the real benefit here other than some sort of URL ascetics? I’ll let you in on a little secret: The IP address for this blog is hardly maximizing feng shui.

Best Practices != HTML5

Many of these things are best practices. Some of these depend on your application. Most of these aren’t HTML5.

Lets just clarify that HTML5 is not about disabling MultiViews getting rid of the Etag header and being able to style <section/> elements. HTML5 is more than that.

Your ability to use HTML5 still depends on widespread adoption of modern browsers like the latest and upcoming versions of Firefox, Chrome, Safari, Opera, and even IE 9.

Again, HTML5 Boilerplate is not a bad starting point. My point is you’re not really getting as much as it initially sounds like. It’s a bunch of fixes you likely already have in your toolkit already assembled. If that’s helpful: great. But don’t think your missing out on a new era of the Internet by not adopting it. Most good web developers have done these things for a long time now.

Steve Jobs: Thoughts On Flash

Apple today published a letter from Steve Jobs aptly title “Thoughts on Flash“. What’s interesting isn’t so much what he said, but what he alluded to. This letter is about Flash, but it’s also about the future if the iPhone platform strategy. It also alludes to the future importance of WebKit and the open web. Lets walk through this. From his points:

First, there’s “Open”.

Steve is right. Flash isn’t really “open”. The iPhone isn’t either by any means. In fact it’s the most restricted computing platform in the world as far as I know. What he did note is that the iPhone uses WebKit and by proxy the web is the most open platform on the planet. That’s very noteworthy.

Second, there’s the “full web”.

Flash video itself isn’t that great by todays standards. That’s why sites like YouTube are serving HD video in H.264 rather than VP6. H.264, VP8 and Theora are the future. If all 3 or just one will survive remains to be seen. Regardless any of them can be played outside of Flash. The dependency on Flash to build a player is going away more and more each day.

Regarding games, this is a silly point. Almost all Flash games need a keyboard or mouse to work. They would never work with a touch screen. Nor would they scale to fit the screen. They would need to be significantly reworked/rewritten.

This is yet more alluding to WebKit and HTML5 where there are solutions already in place.

Third, there’s reliability, security and performance.

It’s pretty hard to dispute the reliability of Flash. It’s by far the driving force behind things like out of process plugins (OOPP) in Firefox among other browsers. It’s also been subject to lots of security vulnerabilities.

Fourth, there’s battery life.

The WSJ quotes Adobe’s Shantanu Narayen as saying the claims of Flash being battery draining are “patently false” but if you look at a CPU monitor while browsing a page with Flash, you can see the load increase quite a bit. Blocking flash on your browser does speed things up and keep your system cooler. I’m very suspect that Adobe has solved this in cell phones when they don’t even seem to have it under control in Windows.

Fifth, there’s Touch.

I already mentioned that mouse/keyboard interfaces just don’t work on the iPhone. No need to rehash that.

Sixth, the most important reason.

That’s actually a vague header. The reason is that they don’t want a third-party sitting between the iPhone API’s and developers. If that happens, developers are limited to what that third-party decides to implement. At the very most developers on the Flash platform get whatever is supported on all Flash platform (greatest common denominator).

That leaves Apple in a stupid position. They could implement killer features in the iPhone and create amazing API’s to take advantage of the features. But if Adobe doesn’t see a way to support things across platforms, or just doesn’t see the cost/benefit of implementing that feature, developers can’t use it. That marginalizes the product for Apple as well as developers.

Conclusion

I found this very interesting that he closed it like this:

New open standards created in the mobile era, such as HTML5, will win on mobile devices (and PCs too). Perhaps Adobe should focus more on creating great HTML5 tools for the future, and less on criticizing Apple for leaving the past behind.

In February of 2007 Steve Jobs wrote another letter on DRM. It’s noteworthy because in January 2009 Apple launched the ability to buy non-DRM protected music. The letter was really a hint at where things were going. He’s repeating the PR strategy that he used then, make no mistake of it.

I have a feeling the day will come where the App Store is deprecated in favor of promoting HTML5 based Applications either directly off the web or packed similar to how Dashboard Widgets are done now on Mac OS X. The App Store will be around for quite some time, but it will eventually morph.

That is why WebKit is so important to Apple. They want to abstract their OS to the point where they can provide very high level hooks into features they want developers to be able to use. The current iPhone App SDK was a solution created by Apple as a way to let developers put applications on the iPhone as an afterthought. The moderation is so that they can keep their security record intact and could shut down a malicious app before trouble becomes rampant. That puts them in the position where they can either approve all content and be viewed as sleazy by more conservative folks, or they can let everything go and accept that reputation. They obviously made their decision. Developers and some geeks hate it, but 99% of the rest of the world doesn’t even know about the process. Nobody wants to know how sausage is made.

The App Store will likely morph to feature Dashboard Widget like applications (not to different from Palm’s WebOS). Apple will still be able to cash in via that distribution point since they can use DRM giving them the only way to actually sell a protected application. You can view them online via you’re browser.

That’s my prediction. The day will come when the iPhone SDK that we know today will be deprecated. WebKit and HTML5 aren’t there today, but the day will come when they will be the tier 1 development platform for the iPhone. Steve Jobs is just laying the groundwork today.

For desktops, other platforms and browsers it’s worth noting that there’s a lot to gain here.