Strong opinions, weakly held

Tag: html5

Responsive design is the near future of Web page layout

Where is Web design headed? For a preview, check out the Boston Globe. It looks like a perfectly normal newspaper Web site, until you start resizing the browser window. The page layout is dynamically altered so that it properly size whatever window is being used to view it. There’s no more “click here for our mobile site” button or a link beseeching you to download the site’s app in somebody’s app store. This technique is called responsive design, and its creator, Ethan Marcotte, consulted on the Boston Globe’s implementation. He’s written about his role in the project on his blog.

I suspect that responsive design is going to be adopted widely. The Boston Globe provides a compelling blueprint. The next step will be approachable frameworks that enable people to create responsive designs without having to build them from scratch on their own. As soon as I saw the new site, other sites that redirect you to a special site just for mobile devices or offer links to a mobile version of the site seemed completely out of date.

I want to build everything in this fashion from here on out.

Another theory on Google’s dropping H.264

Horace Dediu has another theory on why Google is dropping support for the H.264 video codec:

I rather think that Google’s decision is a misguided emphasis on technical details in lieu of engaging in a deep strategic re-evaluation.

Don’t miss the interesting comparison to Apple’s decision to go with the PowerPC over Intel processors back in the day.

I’m sort of obsessed with this decision by Google not because of its effect on me personally, but because I’m curious as to how companies come to these kinds of decisions. It’s complex and fascinating.

Google’s decision to drop H.264 support in Chrome

Google’s decision to drop native support for the H.264 video codec in Chrome has generated a number of arguments on the Web. Google’s defenders argue that H.264 is not royalty-free and is thus inappropriate for use with HTML5, since the W3C refuses to mandate the use of royalty-encumbered technologies in its specifications. Google’s critics argue that this doing so is a cynical move aimed at bolstering its own codec, WebM, and undermining vendors like Apple and Microsoft who support H.264 and who don’t support WebM or Theora. It seems inarguable that this decision by Google insures that Flash players will continue to be the primary means of showing video on the Web.

The best overview of this issue that I’ve seen is Peter Bright’s piece at Ars Technica: Google’s dropping H.264 from Chrome a step backward for openness.

The growing misperception of HTML5

Today the New York Times Opinionator blog ran a piece by Robert Wright made the following assertion about HTML5:

In principle, HTML 5 will allow sites you visit to know your physical location and will make it easier for them to keep track of your browsing and shopping history.

That assertion is based on this news article from the Times, which says:

In the next few years, a powerful new suite of capabilities will become available to Web developers that could give marketers and advertisers access to many more details about computer users’ online activities. Nearly everyone who uses the Internet will face the privacy risks that come with those capabilities, which are an integral part of the Web language that will soon power the Internet: HTML 5.

All of this talk is about one piece of HTML5, client storage. For the details, check out Mark Pilgrim’s chapter on local storage in Dive Into HTML5.

There are two points to make. The first is that Web sites won’t have access to any information that they don’t have already already. In that sense, the talk about “access to many more details” is misleading. It’s not that Web sites will have access to new information, but rather that they’ll have a new place to store information that they already collect that may make it more convenient for them.

For example, if I don’t share my current location with FourSquare, they won’t suddenly be able to retrieve it if I use a browser that supports local storage. However, if I do give them access to my current location, they could store it in local storage on my own computer rather than using their own resources to store it on their server. In that sense, the information may suddenly be worth storing and easier to access, but it’s information they could already obtain and store on their own servers if they chose to do so. This aspect of local storage subjects users to no real risk beyond the risk already posed by cookies or other vectors for storing information about users.

What’s really gotten people wound up is evercookie (mentioned in the New York Times story), a proof of concept that demonstrates how the variety of ways Web sites can store information on the client can be exploited so that it’s nearly impossible to delete tracking cookies. Browser cookies are one way to store information on the client, as is local storage. Flash Local Shared Objects (also known as Flash cookies) can also store information on behalf of Web sites on your computer. evercookie uses a number of other methods for storing information as well. The nefarious thing about it is that when the information is deleted in one of these locations, evercookie replicates it again from another location where it is still stored. So if I delete my browser cookie, evercookie will copy that information from Flash and put it back in place. If I delete the Flash cookie, it will look in one of the other locations where it stashes information and copy it back again.

Using tricks like this to make it difficult for users to prevent Web sites from tracking them is unethical. Web sites who take this approach should be classified as spyware. But the existence of these techniques has nothing to do with HTML5.

What concerns me is that we’re on a path toward HTML5 being perceived negatively by regular users because the only thing they’ve heard about it is that it is likely to compromise their privacy. This perception could become a major stumbling block on the road to wider usage of browsers with HTML5 support. As developers, it’s important to educate users and perhaps more importantly, the media, so that people don’t conjure up risks where they don’t exist and damage the HTML5 brand in the process.

It isn’t too early to start using HTML5

A representative of the W3C says it’s too early to start using HTML5. Scott Gilbertson of WebMonkey argues to the contrary. Given the pace at which Internet Explorer users upgrade, if you are opposed to using HTML5 now, you’ll probably still be opposed to it a decade from now:

The fact is HTML5 is here and you can use it today, you just need to use shims, fallbacks and workarounds for older browsers. Yes, that’s unfortunate, but that situation isn’t going to change any time soon. If IE8 — which lacks support for most of HTML5’s features — has even half the longevity of IE6, we’ll still need fallbacks even when 2022 rolls around and HTML5 is, in the W3C’s opinion, finally ready.

In the meantime, developers are building awesome things with HTML5, CSS3, and JavaScript. Check out PaintbrushJS, a new library written by Dave Shea that enables you to apply filters to images using CSS and JavaScript. Not only can you change the way images appear on the page, but you can also allow users to save the filtered images.

Obviously we can’t just migrate to HTML5 wholesale yet (unless we’re creating Web sites optimized for iOS and Android), but the time to weigh whether using HTML5 and compensating for old browsers makes more sense than using older techniques that work in all browsers has arrived.

How The Wilderness Downtown was made

Ricardo “Mr.doob” Cabello headed up the programming behind the amazing Arcade Fire interactive video The Wilderness Downtown, which was built using HTML5 and JavaScript. He’s documented how the video was made on his blog, and it’s worth reading for JavaScript hackers. A few years ago, I worked on a project that replaced a Flash-based promotional application for a health insurance company with a version built using JavaScript and HTML. The end result wound up being pretty decent, but my main impression at the end was that it was a ton of work for results that fell short of the original Flash application in terms of dynamic impact. I attribute their more impressive results to the fact that they didn’t have to deal with Internet Explorer 6. Hat tip, Webmonkey.

The state of the video tag

YouTube’s developer blog has a sort of state of the video tag post, explaining why the HTML5 approach works for experimental purposes but isn’t going to soon displace Flash as the default for their service. The problem of browser makers not agreeing on a single video standard to support is huge:

First and foremost, we need all browsers to support a standard video format. Users upload 24 hours of video every minute to YouTube, so it’s important to minimize the number of video formats we support. Especially when you consider that for each format, we also provide a variety of sizes (360p, 480p, 720p, 1080p). We have been encoding YouTube videos with the H.264 codec since early 2007, which we use for both Flash Player and mobile devices like the iPhone and Android phones. This let us quickly and easily launch HTML5 playback for most videos on browsers that support H.264, such as Chrome and Safari.

Just supporting one more format will roughly double the amount of storage they need for videos. (The exact amount will vary based on the effectiveness of the compression algorithm.)

Their full list of reasons why the video tag is not ready for prime time is worth reading, and it underscores a larger point with regard to standards as well. The bottom line is that it’s easier for Adobe to iterate on Flash than it is for browser makers to iterate on HTML. Adobe can add new features and push them out in an update that works in all of the popular browsers. And it seems like it’s easier to get people to update their Flash player than it is to get people to upgrade or switch from Internet Explorer. That’s what leaves us stuck on the least common denominator when it comes to implementing things with HTML. In other words, Flash isn’t going anywhere anytime soon.

My prediction is that the trend over the next few years will be Flash on the desktop and more robust HTML5 applications for mobile platforms, thanks to the lack of Flash on iOS and strong support for HTML5 on both iOS and Android.

© 2024 rc3.org

Theme by Anders NorenUp ↑