Tag: web browsers

Categories
Mozilla Web Development

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.

Categories
Apple Mozilla

Mobile Browsing UI

It’s interesting to watch mobile web browsing UI develop. This is really the first time since web browsers existed that they have received a large overhaul. Sure things like tabs are “major”, but when you really look at it, Safari, Chrome, IE, Firefox are all strikingly similar to the original Mosaic (this is 1.0 running on Windows XP):

NCSA Mosaic UI

I’m not sure who’s idea it was to put the title in the UI like that, especially in a time when displays were small. That was a gigantic waste of space. The address bar in this version is read only, you need to select open and enter your URL there. Other than that, it’s pretty much the same browser UI since 1993. That’s right, 15 years of really the same user interface. The window to the web has always looked that way. There’s now bookmarking, a fancier address bar, favicons, and a search box. Firefox goes nuts by letting users install add-ons. Overall: Not very different.

There’s a few reasons why it hasn’t changed too much. First of all, it’s a pretty good design. Minus some quirks which were worked out pretty fast, it’s effective. If it wasn’t the web wouldn’t have caught on. Secondly, people know how to use it already. Why make people re-learn?

The mobile space is different yet surprisingly the same. Like days of old there’s a need to conserve screen space. Unlike days of old there’s no reason to believe it will get bigger since small phones are always desirable. Until screens are foldable, the iPhone is about as big as you’ll see. Even when phones get thinner and lighter, the screen size won’t likely get any larger since it will be awkward to hold and put in your pocket.

With a touch screen you can only make items in the UI as small as a fingerprint. Any smaller and they are unusable to people. A stylus while clunkier and more awkward allows for a much more compact UI. This leaves very little space to get a lot accomplished. Too add to the complexity of the problem websites are designed for big displays meaning there’s a lot to cram into a small space.

Apple’s allegedly making a pretty interesting change to iPhone 2.2. Safari will break out the search box into a more desktop-like separate box. This results in a smaller address bar and the reload icon being moved inside the url bar. I think the reason for this is to better parody the desktop, and remind users they can search from the browser chrome.

iPhone 2.2 Safari With Search Box

To be perfectly honest, I’m not sure the address bar is even needed in a mobile browser on a touchscreen device. Unlike a desktop you can’t type directly into it because of the small size. Your essentially going to another UI to enter the text anyway. Why not just make it a button? You could argue you need the address bar as a way to know where you are. Of course you can likely merge it with the Title to accomplish that. All that’s needed in the main UI is the title and hostname. That can be all in the title of the window. I think I’d prefer a back button more than the address bar on a mobile device. Of course if I could tap or tilt the device to go backwards or forwards that would be cool too. One less thing for the UI.

The most similar to this is Fennec.

On a side note, thanks to Apple’s insane SDK licensing and app store policy it is unlikely to ever live on an iPhone. Maybe one day Apple will realize that just like 3rd party applications (something they were originally against), an even more open device would be even more enticing. But I digress.

Nintendo DSAnother concept I’d really love to see and experiment with is a dual screen format. Similar to that of the Nintendo DS. This would be perfect for a flip phone style smart phone. As phones can be made thinner folding them over is an option to keep the physical device small enough for portability but the display size can then be doubled. By the time the iPhone can be made half the thickness (remember the iPod G1 was much thicker than it is now) this is feasible.

There are several fun things about this design. First of all you essentially Optimus Maximus keyboard on your phone. Secondly you can now separate the content from the chrome in applications. Perfect for things like web browsers. This is also handy for watching movies as controls don’t overlay video but are still available. It also would be great for multi-tasking.

That’s where I predict things will ultimately go. We’re once again in the era of Bar form phones. Anyone remember the Nokia 1100/5110/3210/3310 fad a few years ago? Then flip phones came back in style. The flip phone style also has the advantage of protecting the internal display from scratches and involuntary button pressing.

It will be fun to see how the interface evolves. I’m relatively certain despite all the different UI prototypes surfacing right now regarding web browsers, as they mature they will adopt features from each other and become surprisingly similar to each other.

iPhone Safari image via Wired. Nintendo DS image via Wikipedia Commons]

Categories
Apple Mozilla Security

Safari Redux

I said yesterday:

  • Security – I have a feeling this will make it much more of a target to hackers. So far Safari has fared pretty well. I guess we’ll see.

Well, that didn’t take long.

The bottom line is: web browsers are complicated pieces of software that deal with a ton of different technologies and render code written by people you shouldn’t trust. While countless security measures are taken, nothing short of floating a hard drive in outer space will be secure, and even then… you never know.

Security is partially about preventing problems, and largely about dealing with them.