Showing posts with label ie8. Show all posts
Showing posts with label ie8. Show all posts

Tuesday, October 20, 2009

Don't Dream It's Over



Sometimes you need some 80's music. While you listen to that song, I want you to think about something: the Opera browser. As an OG geek, I used to use Opera -- I even paid for it. It was so much better than IE and that was back in the day when there was just the Mozilla Suite Monster, no Firefox. Sure, there were sites that didn't work well in it, or that actively discriminated against it (including my current employer...) That was ok. It was so much faster than anything else out there, that it didn't matter.

As the world has turned over the years, history has proved Opera right. How fast your browser is does matter. How secure your browser is does matter. There is plenty of room for innovation in the browser space: tabs, download managers, speed dial, magic wand, etc. So many of Opera's ideas have been taken by the Firefoxes, Safaris, and most lately, the Chromes of the world, and touted as innovations -- that were then copied by IE. Meanwhile, what's happened to Opera? It doesn't always pay to be right.

I got news for you, Opera is still kicking butt. There has been a renewed focus on browser technology, and in particular what is collectively known as HTML 5. Apple, Google, Mozilla, and even Microsoft all like to talk about how awesomely they implement the HTML 5 specifications. Turns out they are still way behind Opera. Don't believe me? Take a look at @ppk's HTML 5 browser comparison. Or perhaps you are more visual...

Code (courtesy of a colleague):
<form> 
    <datalist id="mylist"> 
        <option label="Mr" value="Mr"> 
        <option label="Ms" value="Ms"> 
        <option label="Professor"value="Prof"> 
    </datalist> 
    <div class="entry"> 
        <label for="form-1">Name (required) </label> 
        <input id="form-1" name="name" type="text" autofocus required> 
        ← autofocus here </div> 
    <div class="entry"> 
        <label for="form-2">Title</label> 
        <input id="form-2" name="title" list="mylist" type="text"> 
    </div> 
    <div class="entry"> 
        <label for="form-4">Age</label> 
        <input id="form-4" name="age" type="number" min="18" max="25"> 
    </div> 
    <div class="entry"> 
        <label for="form-5">Email (required)</label> 
        <input id="form-5" name="email" type="email" required> 
    </div> 
    <div class="entry"> 
        <label for="form-6">Blogs</label> 
        <input id="form-6" name="url" type="url"> 
    </div> 
    <div class="entry"> 
        <label for="form-7">Date of Birth</label> 
        <input id="form-7" name="dob" type="date"> 
    </div> 
    <div class="entry"> 
        <label for="form-8">Attractiveness </label> 
        <input id="form-8" name="a" type="range" step="0.5" min="1" max="10" value="5"> 
        <output name="result" onforminput="value=a.value">5</output> 
    </div> 
    <div class="button"> 
        <button type=submit>Submit</button> 
    </div> 
</form>
Opera:


Latest Chromium Nightly:

As you can see, Opera does a great job of implementing many of the new markups in HTML 5, while Chrome .... not so much. Big deal, right? You can do all of these things with JavaScript you say. Yeah, but not only will that be a lot of heavy JS, but it will lose semantics. Don't think that matters? Well, not only do those semantics matter to folks who use screen readers, but it also matters to the most important user of the Internet: googlebot.

Anyways, the point is that once again Opera is leading the way, not the folks who talk the loudest about pushing browser technology.

Note: This blog post created with Opera.

Tuesday, June 16, 2009

HTML 5: Don't Believe The Hype

In case you haven't heard, HTML 5 is The New Hotness. I have been watching this tide rising for awhile. There have been many skirmishes between The Unite Emirates of JavaScript and The Kingdom of Flash over how plugin technologies were going to be made obsolete by HTML 5. To hear some folks talk about the future of HTML 5, it is a veritable morality play. HTML 5 is all about the nobleness of open source and open standards. It is democracy and freedom. Everything else is closed and tyrannical.

Things really took off a few weeks ago at Google's IO conference. GOOG officially put its chips in the HTML 5 pot. This should not have been a surprise, as Google has invested in improving browser technology first through Gears and then through its own browser, Chrome. Of course Chrome actually uses the now ubiquitous WebKit for its rendering engine. This is at the heart of not only Apple's Safari browser, but also the mobile browsers on the iPhone, Android, and Palm Pre. Google used the "standardization" of WebKit on mobile devices to deliver mobile versions of GMail and Calendar thus punting on native applications.

So HTML5 is the future, right? Not so fast. I know it seems this way to a lot of people, especially the emphatic fans of open standards. However, those guys live in a different world than I. In the world I live in, browser fragmentation is at an all-time high. In a world of fragmentation, standards are an amusing concept. If history has taught us anything, it is that standards are set by whoever has the most users.

This has long been a source of pain for Google and others. In all fairness, IE8 implements some of the HTML 5 features, but not all of them. Also, the IE family of browsers has been losing share for several years. However, it is going to be awhile before web developers can forget about IE6, not to mention IE7. Given the update cycle of IE in the past, we can expect the older versions to stick around a long time before IE8 finally becomes the king. Again it does not even implement all of the highly touted HTML 5 features. Maybe more will be supported in IE9? How long before that becomes the dominant browser?

My point is that if you want to hitch yourself to HTML 5, you are not hitching yourself to Firefox, Safari, and Chrome. Well ok, you can hitch yourself to those browsers (or IE+Gears), but you are saying go away to 60-70% of the world. So assuming you don't want to do that, then hitching your app to HTML5 means hitching your app to future IE adoption. That just seems like a scary proposition to me.

But what about mobile devices? Here things are clearly better. Again the standards are set by the dominant player. WebKit is the dominant technology in high-end mobile browsers. Still there is fragmentation. The exact same APIs do not work on Mobile Safari as on the Android browser (don't know about the Pre.) Thus you may have to do some abstractions to smooth over the differences. Oh wait, that is starting to sound a lot like the situation with desktop browsers... Anyways, many HTML 5 features are present on the iPhone and Android browsers, so you have much more latitude to use them. However, there is another, more important question to answer when considering going down the path of GMail/Calendar on the iPhone/Android. Can a browser based be as good as a native app? Probably not, but maybe it's "good enough." However, I have to wonder, how many GMail users use the GMail web app on their iPhone instead of using the native Mail application? The GMail web app gives you all of the features you are used to, like conversations, labels, stars, and awesome search. The native Mail app provides none (or at best much weaker implementations) of this, but yet I would guess that most people still prefer it over the web app.

Thursday, September 04, 2008

JavaScript Benchmarks, now with Chrome

As promised yesterday, I did the JS benchmarks again on a Windows machine so I could include Google Chrome. I tried to be pretty inclusive, adding in IE7, IE8 beta 2, Firefox 3.0.1 (current release), Firefox 3.1 with and without JIT, Safari 3.1 (current release), Safari 4 beta, Opera 9.5 and Chrome. This was all run on my workstation, a 4-core, 3.2 GHz box with 8 GB of RAM. Any add-ons, extensions were disabled. Here is the pretty picture.


Once again Safari is the kind. Safari 3.1 beats everything except for Safari 4 beta, which crushes even Safari 3.1. Opera was a little slower than Safari. Chrome was generally comparable to the various Firefox browsers, but overall slightly slower. Like Firefox 3.1+JIT, it was very on error handling! Of course IE was the slowest by far, but at least IE8 is faster than IE7. Maybe IE8 is shipping with debug symbols included (as Microsoft has often done in the past) and the release candidates will be much faster than the betas. Or not.

Anyways, Chrome, and its V8 engine, does well, but does not seem to be ahead of Firefox and is certainly behind Safari and Opera. Maybe they can do better on the Mac!

Thursday, March 27, 2008

Beta Browsers 2008

This is a big year. Both IE and Firefox will release new versions this year. That hasn't happened ... ever? IE8 had its first beta, whereas Firefox 3 is at beta four. Indeed FF3 is much more polished at this point than IE8. However, I must say that Microsoft has been smarter than the Firefox team in a number of ways.

First, IE8 includes an improved IE Developer Toolbar by default. The IE DevBar is roughly equivalent to Firebug, but Firebug does not work with FF3. Of course you can’t really blame this on FF, but IE8 is much more web developer friendly. Web developers are the primary (only?) audience for beta browsers. IE8 also includes the IE7 emulation mode. Again this is very nice for web developers who have to program for IE7 currently, but need to get a head start on IE8 (wait, isn’t that all web developers?)

Thursday, March 06, 2008

IE-Hell Freezing Over

Even after I heard the rumors, I still never thought I'd see it with my own eyes:

My enthusiasm was quickly curbed when I tried to use IE8 to post this blog entry. Not only did the Blogger interface look crazy, but the upload image link did not work. I tried switching to "Emulate IE7". To do that, you must restart the browser. That's not very practical, and just means that most people will have to default to the IE7 emulator. Oh well, I guess Blogger just needs to fix up their non-standard JS? Maybe I will open up a debugger to figure out what is breaking. Probably some kind of browser sniffing code that picks different JS syntax depending on if it is IE or not. Maybe what is needed is an IE8 add-on that fakes the user-agent so that most sites think IE8 surfers are actually Firefox surfers.