Archive for the ‘Browsers’ Category

IE6 and Mobile Sites

IE6 turns nine years old tomorrow. Ironically, it’s now old enough to ride most rides… and those rides are turning it away. The latest is PBworks, formerly PBwiki. They’ve announced that IE6 users are about to start getting a warning message that they have two months to upgrade.

Here’s the intriguing part: after that date, they will be directing IE6 users to their mobile site. And that, I admit, is a solution I hadn’t considered. Most mobile browsers, after all, have stronger standards support (and better security) than IE6. But most mobile sites also offer stripped-back functionality, making them frequently compatible with IE6′s limited standards. If your mobile site has scaled-back features, and those features aren’t especially demanding on modern browser features, punting your IE6 users to m.yoursite.com can be a great way to get rid of headaches.

Here Is Why Web Developers Hate IE6

This humorous graphic speaks 1000 words.

Flash In the Pan

IE9 has announced they’re giving decent support to the <video> tag.  And that, my friends, spells the beginning of the end for Flash.

I’m a Web-standards guy, so my inclination has never been toward Flash anyway.  Admittedly, there are some things for which Flash is ideally suited — namely, for animation and video.  To date, there really hasn’t been a reliable way to do that kind of thing, other than the fairly ubiquitous Flash plug-in.

My big beefs with Flash, though, are:

  • it doesn’t play well with others.  CSS z-indexing is tricky.  It also steals keyboard focus, preventing Tab and (on Windows) Alt-Tab from working normally.
  • that designers use it for things like site navigation and to display text, be that out of a control-freaky desire to control all things related to the user experience, or out of a lazy refusal to learn how to do such things in DHTML/CSS.

The latter has become a real issue now that I have an iPhone.  Sites with Flash splash pages, but no HTML “skip this” link, prevent me from seeing their site.  Sites done up entirely in Flash, as is very common for musicians and artists, prevent me from seeing anything.  Recently, while driving, my wife and I thought about visiting a new restaurant nearby, so we called up their site to see their menu.  The site was all Flash.  That restaurant lost business that day — and we still haven’t eaten there.  If you can’t be bothered to give me your menu in HTML — a text medium! — I can’t be bothered to find ways around the all-too-familiar iPhone brick icon.

Now, when I mention the iPhone, neither here am I defending Steve Jobs.  On the one hand, his public position that the iPhone wants to support HTML5 over proprietary standards is a good one.  His refusal to allow Adobe’s tools to export into an iPhone-friendly format, insisting that iPhone developers use only Apple-endorsed tools, shows his real motives.

But Jobs is right about one thing: HTML5 is a big win.  With it, we get video, audio, and lots of other good stuff that, to date, has required us to use Flash.  IE has, as always, been the laggard; that IE9 will support these HTML5 technologies is a big win for the Web.  Mind you, it’ll be years and years before IE6-8 have been suitably flushed out of our system, but we’ll at least be able to plan for the future.

HTML5 doesn’t do everything that Flash can, as Ajaxian points out.  Flash will do full-screen video, for instance, which none of the browsers will currently do for HTML5 video.  That, however, is a problem for the browser makers, not a problem with HTML5.  Hop to it, ye browser coders!

Google: So Long, IE6

Big news on the IE front, as the 800-pound gorilla of the Web announced that it’s going to start phasing out IE6 support next month:

Many other companies have already stopped supporting older browsers like Internet Explorer 6.0 as well as browsers that are not supported by their own manufacturers. We’re also going to begin phasing out our support, starting with Google Docs and Google Sites. As a result you may find that from March 1 key functionality within these products — as well as new Docs and Sites features — won’t work properly in older browsers.

Meanwhile, noting that IE6 was the weak link in the Chinese hacks on Google, a petition in the UK government is calling for an abandonment of IE6.

In light of those attacks, France and Germany advised their citizens to switch from IE to a different browser altogether; the UK government, in the person of “Lord West of Spithead”*, said that simply upgrading to the latest version of IE would be sufficient.

* no, seriously, that’s his name.

Google Chrome Frame

I’ve of two minds about Google Chrome Frame. On the one hand, it would be great to be able to take advantage of modern Web tech, especially HTML5 features, in Internet Explorer, which forever lags behind. On the other hand, I’m not exactly clear who exactly this plug-in is designed for.

For IE6 users, I guess the logic is that most users (as we’ve seen) are stuck with that browser due to their workplace’s IT department, so this plug-in would let them get around IE6′s limitations. This, however, assumes that an IE department so conservative as to prohibit IE7 or IE8 would also be willing to let users install this plug-in. I’m sure that’s true for some places, but Chrome Frame will hardly be the panacea to the IE6 problem.

The real benefit, I suppose, is for dealing with IE7 and IE8 users, who still are the lion’s share of the Web. Sites that want to use HTML5 (or CSS3) features, and are willing to force IE users to download a plug-in to access the site, can really profit from this plug-in. I suspect that Google Wave, in particular, was a big driver behind this project; Google seems really avid about the project, but also recognized that trying to code it cross-browser was going to be a losing proposition. So by throwing up a plug-in download screen, they can still bring in the IE users.

Unfortunately, I don’t work for a site that is willing to require IE users to grab a plug-in, and I suspect most sites are in the same boat.

IE6 on CNN

CNN just posted this article on the drive to kill off IE6.

It’s one thing when something like a Digg developer’s blog talks about IE6, but hopefully attention from a major media site will help spur more people to switch!

IE Sicks

It’s been a week of big news on everyone’s favorite albatross, IE6.

First, YouTube is phasing out IE6. Facebook, another big-ticket site, has already been warning users to move away from IE6.

There was a lot of Web buzz about six months ago when a Norwegian site officially stopped supporting IE6. That was all fine and good, but, well, it was a Norwegian site most people had never heard of, and so unlikely to motivate users to switch. By contrast, according to this week’s Newsweek, YouTube is the third-biggest site on the Internet, with 426M visitors per month, so it’s pretty meaningful when a site like that decides it can start dropping support for a browser. When users can’t access YouTube or Facebook with IE6, maybe that will finally be the kick in the pants they need to upgrade.

Second, the crew at Digg did some great research on their IE6 users. They found that IE6 was about 10% of their traffic and was using a lot of development time, but accounted for only 1% of the traffic that was actually using Digg’s bookmarking features. So they polled their IE6 users to find out why they were still using IE6. They found that 69% said that work was forcing them to use it, either by stating they had to or by not giving them admin access on their computers.

Mind you, Digg users are likely to be a tech-savvier lot than users overall, where I suspect you’ll find more users who are naive or stubborn about browser upgrades. Still, this does shine a light on IE6 usage – that it may be corporate IT departments who pose the biggest obstacle to getting rid of IE6, not average users digging in their heels.

Round, round, get a round, I get a round

Inayaili de Leon writes in Smashing Magazine that we should start using CSS3 features. The article’s been reposted lots of places, including MetaFilter. I think my attitude can be best summarized by this MeFi comment from “rokusan”:

Any amateur web developer’s response: Cooooooooool!

Any professional web developer’s response: Yeah, yeah, yeah. Later.

I mean, hell, I’d love to use column-count, but even de Leon concedes its biggest flaw:

Browsers that don’t support these properties render the content as simple text, as if there were no columns.

Those browsers amount to about 70% of the market. Try to imagine a site that wouldn’t look horrible if you pinned its layout to column-count and then fired up IE7, the browser currently holding about a 50% share.

The biggest exception, of course, is border-radius, the key to image-free rounded corners. To quote de Leon:

Currently, it is probably the most widely used CSS3 property for the simple reason that rounded corners are just nice to have and aren’t critical to design or usability.

Indeed, I’ve used it here – and by that, I mean, “I’ve used it here, all over the place.” I’d never do so at work, not when 70% of our users are on IE, but this site has a target audience not known for its love nor extensive use of IE. Besides, IE users just get chunky, square corners, which is not a big lose.

Still, I look forward to the day when IE9 (which, fingers crossed, will have decent CSS3 support) has a large enough share. Rounded corners are something that visual designers just love love love, and drawing them with images is both clunky and a waste of bandwidth. I can’t tell you what a delight it was coding up the CSS for this site, since I’m used to the confines of image-based corners and the associated hacks.

IE, CSS pathnames, and redirects

When a CSS file has pathnames, such as to image URLs, they are supposed to be relative to the URL of the CSS file. That’s why we got utterly baffled at work when our background images looked fine in everything but IE, which didn’t display the images at all. (Here I mean IE7. We stopped giving full support for IE6, and haven’t yet started full support for IE8.)

Here’s what we learned: if the URL of the CSS file has a redirect, IE will use the original URL, the one in the <link> tag, rather than the true, final URL. This remains true even with a 301 on the redirect. This is, well, awful.

Given the project constraints, our best solution was to duplicate the background images from the server with the target URL to the server with the redirecting URL. Thankfully, in a few months time, when the project constraints change, we will no longer need the redirect and can get rid of one set of images.

Still, this bug is so frustrating and so contrary to expectation that when we sent around the solution for internal code review, our front-end system architect needed a lot of convincing since “that couldn’t be it”, and we had to carry him through the same stages of grief we’d just been through.

Word of warning: don’t put a redirect on a .css URL if you have relative pathnames.