Browsers HTML5

OMG! Web Developer has to wait! The Horror!

Where I focused on Ian Hickson’s statement about extensibility, every other person, and their brothers, sisters, and aunts are throwing a hissy because of the HTML5 timeline.

Scott Gilbertson writes:

Even if your 2022 ronc-o-matic web-enabled toaster (It slices! It dices! It browses! It arouses!) does ship with Firefox v22.3, will HTML still be the dominant language of web? Given that no one can really answer that question, does it make sense to propose a standard so far in the future?

Jeff Croft writes:

I’m not saying the specs should go away. They absolute serve a purpose. I’m just saying that I personally am done paying much attention to them. Instead, I’m reading blogs like Surfin’ Safari and Mozilla Developer News to find out what the new shiny is in browsers, because these are the things I can actually take advantage of in serving my clients and users.




Specification work was never focused on the end users, it’s focused at the user agents or others who have to implement the specifications. The Mozillas, Apples, Operas, Microsoft, et al. The only reason I pay attention to any of it is because of my concern about extensibility.

In the meantime, the new stuff that is HTML5 is leaking into browsers now, not years from now. That’s part of the specification process—actual implementation on the street in order to “proof the spec”, as it were. And pieces of HTML5 are not just showing up in Firefox, Opera, and Safari/WebKit— IE8 has a few HTML5 tricks up its sleeve.

Heck, HTML5 isn’t the only longish spec under development. CSS 2 started in 1998, the lost call for CSS 2.1 was in 2002, the candidate recommendation was in 2007, and Microsoft is only now providing CSS 2.1 support. That’s ten years, end to end.

In the meantime, I’m using CSS3 stuff that’s only supported by a couple of browsers, and the final release of all the CSS3 bits is probably years out, too. Of course, I only play around with my own spaces—professional web designers and developers know that we can’t necessarily use the shiny new stuff for client applications, because we’re still having to support browsers that are seven years old.

Hey! We’re still supporting browsers almost as old as the timeline when HTML5 will be finalized! I guess things aren’t as “today” and “now” as we think they are.

The point is, specifications take time, or at least, good specifications typically take time. Any doofus can toss a quick spec out and call it done, but who wants to use the doofus spec?

That schedule part of what Ian had to say didn’t phase me. As far as I’m concerned, the group can take as long as it needs. In the meantime, I’ll play around with the local storage, and some of the other odds and ends, as I keep putting in my annoying “But what about SVG?” “But what about RDF?” oar; probably helping to slow the development of the spec, even more.


Chromatic hyperbole

It would be impossible to miss the excitement over Google’s Chrome, though I would assume we would wait to actually see the product, first, before wetting our pants.

Yes, Google entering the browser marketplace is news, but some of the things I’ve been reading are, well, frankly asinine. For instance, Computerworld breathlessly writes, Google’s Chrome aims to kill Windows, make Web the OS of choice. A bit hard, wouldn’t you say, when Chrome requires Windows just to be able to run?

Let's kill off Windows with our Web OS.



Well, Windows is dead.

That's great! 


Uh, where's Chrome?

Well, you see...

Do we also need to remember our concerns about Google? You know, the whole privacy thing? Or are we a modern day bunch of Pavlovian dogs, trained to drool on cue whenever Google is involved?

There are issues associated with this browser, babes. First of all, as great as it is that Google is using Webkit for its infrastructure, it’s also coming out with its own JavaScript engine. My first question is: is Google going to conform to standards? Or is it going to go its own little way, and just assume we’ll tag along? Then there’s the issue of the engine being multi-threaded—and here I thought Photoshop was going to be the only pig on my system.

My concerns aren’t just related to JS. As I read somewhere—who knows where—we can now see why Google is footing the bill for Ian Hickson to head up the HTML5 effort. However, now that Google is “one of the browser competitors”, how will this change the dynamic in all these standards groups? I’m not going to necessarily give HTML5 over to Google to define to its own Chrome standards. I imagine that some of the browser companies would feel the same.

And about those privacy concerns…exactly what kind of information is Google going to be collecting about us as we use the damn thing?

Frankly, I’m all for anything that weakens the abysmally tenacious hold IE6 and IE7 have on desktops, but I’m not sure yet another player in the field is what we need. Especially a player who, frankly, exhibits many of the same tendencies towards arrogance, as well as interest in complete dominance, as the company they supposedly “hate”. I can understand Google’s impatience with the other browser companies—but Google also has a tendency to act impulsively, and leave the rest of us to pick up the pieces.

As for web applications taking over the world, we’re just now starting to hit against issues of broadband caps, not to mention the problems we’ve had with centralized services recently. Does Twitter ring a bell with you folks? How about Amazon’s S3? GMail? In the last month, we’ve seen outages at a considerable number of centralized web services, and we haven’t even started putting our critical operations into “the cloud”.

Do you really want your business to hit a stand still because you’ve lost your internet connection, hit a broadband cap, or “the cloud” is not playing nicely at the moment? Seriously?

Look, yes. Get interested, yes. Peer around under the hood, and take it for a spin, most definitely yes. But get a grip–the web world as we know it hasn’t suddenly come to an end just because Google has decided it wants to play the browser game, too.

Downloaded. Installed. Works fast. Chrome doesn’t work on the Mac. Thanks to WebKit it does support XHTML and SVG. However, I’ve hit an odd rendering error for this page, which I don’t get with my nightly WebKit download.

Matt Cutts did respond to privacy concerns about Chrome, though I wish he wouldn’t categorize these concerns as being the paranoid ramblings of conspiracy theorists.


IE8 Beta 2: first experiences

My first experiences with IE8 beta 2 have been mixed. On the one hand, I like the fact that compatibility mode no longer requires restarting the browser. However, I’ve found it virtually impossible to tell when I have compatibility mode turned on or off. I’ve also found that once turned on, you do have to reload a page in order to turn it off again, because the button disappears.

Sam Ruby wrote about an improved namespace blurb that appeared about IE8 at a Microsoft site, which has since disappeared. In the post, Sam also mentioned that IE8 no longer supports CSS for elements it doesn’t recognize, also detailed in a bug Anne van Kesteren linked in comments.

I went to check out the bug at Microsoft’s LiveConnect with IE8 beta 2, but received an error in the page that I don’t have permission to view the page. Puzzled, I also noticed that the page asked if I wanted to sign out of LiveConnect.

I had originally obtained a LiveConnect login in order to report bugs about Expression Media, which I was testing for my Painting the Web book. I figured that somehow my old account was interacting with the page in such a way as to make it inaccessible. I tried to delete cookies, in fact every kind of storage associated with IE8, but I still received the same page: I don’t have permission to access the bug, would I like to sign out of LiveConnect.

I looked more closely at the IE8 Delete options, and noticed that there’s another option I missed, Preserve favorite website data, with the following explanation:

Keep cookies and temporary files that enable your favorite websites to retain preferences and display faster.

This checkbox overrides the cookie deletion option when login information is stored. *I’m not sure if this option was present with IE8 beta 1, and I’m not sure I like it—one could easily think they’ve cleared all personal information out of a browser by deleting cookies, only to forget to uncheck the favorite site option, and leave critical logins still active.

Hakon Lie wrote about Microsoft’s back stepping on standards mode. Microsoft had originally stated it would support standards mode by default with the first beta of IE8. Now, it supports standards mode by default on the internet, but supports the old IE7 non-standards mode by default for intranet accesses. The setting can be changed via a menu option, but the problem with this approach is that if you develop a web site internally and it works one way, it may break or work oddly once published externally, unless you remember to turn standards mode on when developing the page internally. This adds all new meaning to the term, quirks mode, as this really is quirky behavior.

IE8 does implement the new JSON object, though be forewarned: it treats single quotes as second class citizens. In other words if your application returns strings delimited with single quotes, your application will fail. The JSON with single quotes still works with eval, though, so you could end up with breaking behavior when you switch from one to the other. To be honest, I find this to be a flaw with the JSON “standard”—either JSON is JavaScript Object Notation, or it’s not, and single quotes can delimit strings in JavaScript.

One new feature, or at least another feature I don’t remember from IE8 beta 1 is that when you encounter a runtime error in JavaScript, IE8 now pops up a window with a note about a runtime error, and asks if you wish to debug it. I imagine this will only appear if you have developer tools enabled. The script debugger included with IE8 in beta 1 is still available in beta 2, and is one really nice feature in IE8.

Less nice, though, is Microsoft’s non-support for DOM Level 2 event handling. There’s also no need to go into details about how the browser doesn’t support XHTML and SVG and MathML—Microsoft will never support XHTML, which should be a disappointing given now. In fact, it’s unlikely Microsoft will ever support SVG, even if this gets included in HTML5. Some would say this will kill SVG. I disagree and believe that this will eventually kill IE. Not just the lack of SVG support: Microsoft’s refusal to deal effectively with the issue of XHTML support, DOM Level 2 event handling support, and so on. Too many gaping holes in standards support, and too little commitment on Microsoft’s part to truly be a standards-based browser.

On the other hand, IE8 does have improved support for CSS. It’s now about equivalent to Firefox 2 in CSS support.

Lastly, if you’re a Netflix Watch Now fan, be warned: IE8 beta 2 does not work with the Watch Now feature, no matter what mode you set. Do not install IE8 beta 2 if you use this feature.

All in all, beta 2 has the feel of being a rushed delivery. Not surprising when you consider beta 2 was released on the seventh anniversary of the release of IE6—a day some of us designated as IE6 EOL or Uninstall day.

*The Preserve favorite option is new with beta 2, but is not working as described. It’s preserving data for sites that are not on my favorites list. In addition, Microsoft puts its own sites on this list, automatically making data to them “saved” with this option.


Phasing out IE6

37signals is phasing out support for IE6. The company weblog lists the reasons for this decision, including:

IE 6 is a last-generation browser. This means that IE 6 can’t provide the same web experience that modern browsers can. Continued support of IE 6 means that we can’t optimize our interfaces or provide an enhanced customer experience in our apps. Supporting IE 6 means slower progress, less progress, and, in some places, no progress. We want to make sure the experience is the best it can be for the vast majority of our customers, and continuing to support IE 6 holds us back.

Those are excellent reasons, and ones we should be taking to heart. At issue, though, is the fact that Microsoft has made it very difficult to eliminate IE6.

When Microsoft rolled out IE7, it did so only in newer generation operating systems, such as Windows XP and Vista. This left a large contingent of users of IE6 on Windows 2000, which is still in fairly wide use. The company also didn’t post recommendations for W2K users to switch to a different browser, such as Firefox or Opera. Both actions served to leave a bloc of orphaned IE6 users, many of whom are still haunting our web sites.

I also don’t give much credence to those bemoaning the burden that dropping support for IE6 would have on corporations, libraries, and schools. It is not an onerous task to install Firefox on people’s machines. Nor is it an impossible task for sites to update their software. If two years since the release of IE7 isn’t enough time, what is the right amount of time? Five years? Ten? At some point, we’re faced with biting the bullet, and doing so before IE8 is released seems to be a good time to crunch down.

The single biggest hindrance to expansion on the web today is IE6. We can’t use transparent PNGs because of IE6. Anything but the most rudimentary uses of JavaScript becomes a problem with IE6. Our sites are full of workaround CSS and page markup existing only to support IE6. We are, in effect, grand prix racers stuck behind some old cow left in the road by farmers who have decided they like pigs, better. Oink.

I don’t support IE6, and not just because most of my readers are using new browser versions. I don’t have a separate machine I can keep at IE6 in order to test my pages. Since we can’t run IE6, IE7, and IE8, simultaneously, I made a choice to support the two newer versions of IE, which are, themselves, enough of a challenge. For the older browser users, I provide the printer friendly pages with all JavaScript and CSS stripped out. It may not be an optimum solution, but neither is supporting IE6 until all the older machines are piles of rust.

I do hope that 37signals begins a trend.

(via Simon)


As Ralph points out in comments, yes we can use PNGs with IE6, if we use IE specific filters. I’ve not had the best of luck with IE6 and PNGs, and typically just hide my PNGs from IE6 with CSS. But then, I decided with the first beta of IE8 that I was not going to create specific code for IE6 any longer. Two versions of any browser is enough.

Ralph also notes the PNG8 workaround for IE6. However, using this technique does not ensure that an image is going to look as good in IE6 as it does in other browsers. I’ve not tried this with GIMP, and I don’t have a version of IE6 for testing, but is an option for those still having to support IE6. However, as the Cozi Tech Blog mentions:

We have since decided that we will no longer make heroic efforts to get our web application looking just as good on IE6 as it does in modern browsers. Quite apart from the extraordinary amount of pain we endured in the Affair of the Transparent PNGs, fighting with IE6 has been a huge timesink for us, especially when it comes to working around its CSS bugs.

A significant fraction of our users are still using IE6, so we have no choice but to support it. However, we no longer aim to achieve full parity.

If sites still support IE6, but at a minimum, as I do with my sites, this also may finally force the issue and hasten the EOL for this browser.


Shiretoko: First Looks

I downloaded the first alpha of Shiretoko, or Firefox 3.1, and I’m delighted to see the text-shadow I have attached to my site name showing up in a Firefox browser.

Not just text-shadow, Mozilla has also added JavaScript query selectors to this release, which means that we can query for all elements of a given class name, such as:

var list = document.querySelectorAll(".elements");

A behavior that we also had with the older, supported, document.getElementsByClassName. However, we couldn’t do the following with getElementsByClassName:

    var first = document.querySelectorAll("div > p:first-child");   
    for (var i = 0; i < first.length; i++)   {    

This code snippet accesses the paragraphs that are directly the first child of any div element, using the CSS selector syntax, and sets the background of each returned element to red. You can see it in action with this simple example containing three div elements, each with three paragraphs, the first of which now has a red background. Well, you can see it with browsers that support querySelectorAll, which are Safari/Webkit, IE8, and now Firefox 3.1a. Opera has also committed to the support of querySelectorAll (as well as rgba, we hope).

Of course, I can do something like this with JavaScript by getting all div elements, and then all paragraphs of all div elements, and then accessing the first of the returned set, but how much simpler, and how my more robust will this process be if this type of functionality is built directly into the browser. Especially since my example is quite simple, but other queries on CSS selectors could be quite complex.

Firefox 3.1a also has support for border images, which means no more nested div elements to achieve specialized borders, which is what’s used in the design of this site. However, support for this CSS3 attribute is limited to Firefox 3.1a and Safari; until support for the option reaches three of my four target browsers, I won’t use it for my site designs.

(I felt comfortable using the text-shadow when only Opera and Safari supported the CSS attribute, because it provides such a nice effect, which degrades beautifully if the attribute isn’t supported.)

Firefox 3.1a also supports the HTML5 Canvas Text API, but I haven’t had a chance to play with the new capability, yet. I had rather hoped that the Mozilla team would add a little SMILe to the browser, but I guess it’s not to be with this browser release. Perhaps our man on the SVG street, Jeff Schiller, can update us on a SMIL timeline for the browser.

Oh, and look: anyone can try the browser and report a bug.