CSS Zen Garden is ten years old. If you started coding recently you may not have heard about the site, but Zen Garden was a defining moment in web history.

Zen’s developer, Dave Shea, had a simple objective: to illustrate why CSS should be taken seriously and inspire designers. The concept provided a static HTML page and allowed developers to apply and submit their own styles. The only restrictions were that the CSS should validate and the resulting page worked in IE5+ and Mozilla (Firefox’s predecessor).

The number of submissions increased exponentially and there was a sudden realization that CSS could do more than just apply color to H1 titles. To put it into historical context, by 2003 CSS techniques had been viable for several years but tables and spacer GIFs remained the predominant page layout methods. Tables worked in all browsers and were well understood.

Zen Garden did for CSS what Jesse James Garrett’s A New Approach to Web Applications did for Ajax a couple of years later. The technologies already existed, but it required a spark to ignite developer passion and revolutionize its application.

Zen Garden 2013

Zen Garden achieved its goal — who isn’t using CSS layouts now? To celebrate an amazing ten years, Dave Shea has re-released Zen Garden, put the code on GitHub and started work on a new HTML5 version. A lot has happened in the past decade, so the modern requirements permit:

• CSS3 transitions, transformations, animations, shadows, gradients and effects. Remember to prefix properties where necessary but Webkit-only designs will be “discarded with prejudice”!
• Responsive Web Designs
• Web fonts
• Support for IE9+, recent versions of Chrome, Firefox and Safari, and iOS/Android

New designs can be submitted now. Please send us the URLs of your groundbreaking examples or designs you like.

An interesting point was raised by Brendan Davis in my recent post “Responsive Web Design and Scrollbars: Is Chrome’s Implementation Better?”: are RWD breakpoints affected by high pixel-density screens?

The short answer is: no — but we need to delve a little deeper and look at the problems they can cause.

What is Retina?

“Retina” is Apple’s brand name for double-density screens but other manufacturers are creating similar displays. The technology is used in recent iPhones, iPads, MacBook Pros and other high-end devices.

For example, the MacBook Pro 15″ has a resolution of 2,880×1,800 or 220 pixels per inch. At this scale, most people are unable to notice individual pixels at typical viewing distances — applications and websites would be too small to use.

Therefore, the device reverts to a standard resolution of 1,440×900 but the additional pixels can be used to make fonts and graphics appear smoother.

What’s the Problem?

Standard-resolution bitmap images can look blocky on a Retina display. A 400 x 300 photograph is scaled to 800 x 600 pixels but there’s no additional detail. This can be noticeable when compared to smooth fonts and other high-resolution images.

Real-World Usage

If you look around the web, you’d be forgiven for thinking everyone has a Retina display. Currently, it’s only available in high-end devices, but these are coveted by developers so it leads to a disproportionate volume of online discussion. In the real world, the percentage of people using similar displays is in low single figures.

Let’s put it into context: if you’re not developing for the 1% of IE6/7 users, you probably shouldn’t be too concerned about people using Rentina — especially since they can still view your website.

That said, Retina-like screens will eventually migrate to all devices. There’s little reason to fret now, but there’s no harm in some forward planning. Let’s look at the options in order of recommendation…

1. Use SVGs and CSS3 Effects

The clue is in the name but Scalable Vector Graphics are … scalable! It doesn’t matter how big an SVG becomes — it will always be smooth because it’s defined using vectors (lines and shapes) rather than individual pixels.

SVG is not practical for photographs but is ideal for logos, diagrams and charts. The primary drawback is a lack of support in IE8 and below but you could always provide a PNG fallback or use a shim such as Raphaël or svgweb. See also: How to Add Scalable Vector Graphics to Your Web Page.

You may also be able to replace some images entirely. For example, titles, gradients, corners or shadows defined as graphics can be reproduced using CSS3 alone. They will render at a better quality, result in fewer HTTP requests and use less bandwidth.

2. Use Webfonts Icons

The more I use webfonts icons, the more I love them. Like SVGs, fonts are vectors so they’re scalable so you can use font sets which contain icons. They’re ideal for small, frequently used shapes such as email envelopes, telephones, widget controls and social media logos. They also work in every browser including IE6+.

There are plenty of commercial and free icon font sets available:

• Typicons
• Font Awesome
• Iconic
• Foundation

Or you can use a hosted font service such as We Love Icon Fonts.

I recommend creating your own small set of custom icons using online tools such as Fontello or IcoMoon.

3. Use High-Resolution Images When Practical

Retina has four times more pixels than standard screens. If you have a 400 x 300 image (120,000 pixels), you’d need to use an 800 x 600 alternative (480,000 pixels) to render it well on a high-density display.

However, the high-resolution file size may not necessarily be four times larger. Every image is different but if it contains solid blocks of color or details which can be omitted, it may be practical to use a 800 x 600 image and scale it in the browser.

Be pragmatic: if the standard image is 200Kb and the high-resolution version is 250Kb, there is negligible benefit using image replacement techniques. Use the better version throughout.

4. Use CSS Image Replacement

There will be times when high-resolution versions of your image are four times larger — or more. In those circumstances you may want to consider image replacement techniques, i.e. the standard image is replaced by larger alternative on Retina displays. The following media query code could be used:

#myimage {
	width: 400px;
	height: 300px;
	background: url(lo-res.jpg) 0 0 no-repeat;
}
@media
screen and (-webkit-min-device-pixel-ratio: 1.5),
screen and (-moz-min-device-pixel-ratio: 1.5),
screen and (min-device-pixel-ratio: 1.5) {
	#myimage {
		background-image: url(hi-res.jpg);
	}
}

The drawbacks:

1. You will need to create and maintain two sets of images.
2. Some browsers will download both images.

Remember that many of these users will be using smartphones or tablets on slower mobile networks. Detecting the connection speed would be more beneficial than determining the pixel density.

5. Use JavaScript Image Replacement

Retina display detection can be implemented using the following code:

var isRetina = (
	window.devicePixelRatio > 1 ||
	(window.matchMedia && window.matchMedia("(-webkit-min-device-pixel-ratio: 1.5),(-moz-min-device-pixel-ratio: 1.5),(min-device-pixel-ratio: 1.5)").matches)
);

Once a Retina display is determined, you could:

1. Loop through all page images and extract the URL.
2. Append ‘@2x’ to the file name and attempt to load the resulting image URL using Ajax.
3. If found, replace the current image with the high-resolution alternative.

Fortunately, the hard work’s been done for you at retinajs.com. While it only adds 4Kb weight, high-density display devices will download images twice — although the second time will occur as a background process after the page has loaded.

My advice: be practical and keep it simple. Don’t spend inordinate amounts of time attempting to solve minor rendering problems on devices with proportionally few users. Of course, none of that matters when your boss receives his new iPad and starts to complain about image quality…

We’re one third of the way through 2013 and an interesting battle has commenced between the two leading vendors. These are the latest figures according to StatCounter…

Worldwide Browser Statistics March 2013 to April 2013

The following table shows browser usage movements during the past month.

Worldwide Browser Statistics April 2012 to April 2013

The following table shows browser usage movements during the past twelve months:

The tables show market share estimates for desktop browsers. The ‘change’ column is the absolute increase or decrease in market share. The ‘relative’ column indicates the proportional change, i.e. another 10.3% of IE6 users abandoned the browser last month. There are several caveats so I recommend you read How Browser Market Share is Calculated.

Chrome jumped another 1% during April. That growth can’t continue, but there’s no sign of it stopping yet. Only one application managed to put up a fight: IE10. Microsoft’s browser grew an impressive 4% in one month following the automated update for Windows 7. While the other versions all dropped, IE10 more than made up the difference.

Talking of which, IE8 had a 1% drop and has fallen below 10%! While the browser did much to rectify the issues in IE6 and IE7, development will be far easier when we can depend on widespread HTML5 support without shims. It still has a healthy percentage but many businesses will be forced to consider alternatives when Microsoft drops Windows XP support next year.

IE6 and IE7 have become mostly irrelevant. I’m tempted to remove them from the chart, but…

1. some developers use the figures as justification for dropping the decrepit browsers, and
2. it gives me a smug sense of satisfaction to watch the numbers tumble.

However, I’m relieved Microsoft can take on Google because the others are struggling.

Firefox holds just over 20% of users but is likely to fall below that threshold next month.

Safari didn’t have a great month and fell 0.5%. It’s a reasonable browser but would it be so popular if Apple didn’t enforce usage on iOS? Users could fall further if Webkit development falls significantly behind Blink.

Finally, 14% of Opera users switched last month and it’s dropped to 1%. Perhaps that’s understandable; Presto has been abandoned for Blink so is there any point sticking with a browser which will soon be superseded?

Mobile Browser Usage

Mobile usage decreased slightly to 13.9% of all web activity in April 2013.

The primary mobile browsing applications:

1. Android — 30.96% (up 0.18%)
2. iPhone — 23.94% (down 0.50%)
3. Opera Mini/Mobile – 15.35% (down 0.19%)
4. UC Browser — 8.74% (up 0.47%)
5. Nokia browser — 7.03% (up 0.07%)

In comparison to the desktop market, there’s very little to report. I guess it’s a quiet time of year with no significant releases or disruptive technologies. Nothing to see here. Please move along and return next month!

HTML5 introduced a few semantic elements that are not supported in older browsers. Some of these new elements are no different than generic block elements so they don’t pose any compatibility problems. All you need to ensure compatibility is to add a CSS rule to your website that causes the relevant elements to behave like block elements.

But Internet Explorer versions 8 and under pose a challenge. Any element not in the official roster of elements cannot be styled with CSS. That means we cannot make then behave like block elements or give them any formatting.

For example, the following code will not work.

<style>
section {display: block}
</style>
<section>This is on its own line.</section>
<section>This should appear on a separate line.</section>

But that’s not all. These new elements behave as if they don’t exist. For example, the following CSS won’t work, since the section element won’t match the universal selector.

<style>
body * span {color: red}
</style>
<body>
  <section>
    <span>This should be red, but won't be red in IE 8.</span>
  </section>
</body>

Fortunately for us, a workaround exists that allows Internet Explorer (IE) to recognize these new elements allowing them to be styled, and thus giving us full use of these new semantic tags. It’s a tool called HTML5Shiv.

As noted on the linked Google page, “shiv” and “shim” are interchangeable terms in this context.

But how did we go from IE not even acknowledging the existence of this element, to now being able to use it?

The trick is that calling document.createElement("section") will suddenly cause IE to recognize the section element. No one knows why, but it works and you don’t even need to use the node returned by that function.

But you need to make sure to call it early on in your website before any of those elements are used, otherwise it won’t work.

You will need to call it for each and every new HTML5 elements like so:

"abbr article aside audio bdi canvas data datalist details figcaption figure "+
  "footer header hgroup main mark meter nav output progress section " +
  "summary template time video"
  .replace(/\w+/g, function(a){ document.createElement(a) });

Notice we’re using the replace method of the string object to succinctly iterate over each contiguous length of characters matched by the regular expression and executing the callback function for each character block which in turn calls createElement.

Here on in, we’ll call this method, “shivving the document”, so that the document can render the new HTML5 elements.

Now our previous two HTML examples work. But that’s not all there is to it.

Pitfall 1: HTML5 and innerHTML

If HTML is being generated using innerHTML and it is called on a node not currently attached to a document (AKA an orphaned node), then it’s deja vu all over again. The following two examples will not render the section element, even though it’s run on a document already shivved.

var n1 = document.getElementById("n1");
n1.parentNode.removeChild(n1);
n1.innerHTML = "<section>Sect 1<\/section>";  //won't work

var n2 = document.createElement("div");
n2.innerHTML = "<section>Sect 2<\/section>";  //won't work

In the second example above, if we append the node to the document first before calling innerHTML, then it will work:

var n2 = document.createElement("div");
document.body.appendChild(n2);
n2.innerHTML = "<section>Sect 2<\/section>";  //works

We can conclude that although we shivved the document earlier on, orphaned elements do not benefit from the shiv when calling innerHTML.

What can we do? For starters, whenever we need to set innerHTML we should append it to the document first. An alternative is to first shiv the document property of the orphan before working with the orphan.

First let’s put our shiv in its own function.

function iehtml5shiv(doc) {
  "abbr article aside audio bdi canvas data datalist details " +
    "figcaption figure footer header hgroup main mark meter nav " +
    "output progress section summary template time video"
    .replace(/\w+/g, function(a){ doc.createElement(a) });
}

The next time we have an orphan element, we can do this:

var n1 = document.createElement("div");
iehtml5shiv(n1.document);
n1.innerHTML = "<section>Sect 1<\/section>";  //works

Notice how it’s just like shivving the document, but on the document property of the element. And notice we’re accessing document instead of ownerDocument. Both are different things as shown here:

alert(n1.document == document);  //false
alert(n1.ownerDocument == document);  //true

Now we have two methods to make sure our call to innerHTML works when handling HTML5 elements.

Pitfall 2: cloneNode

It appears our cousin cloneNode is also susceptible to losing its shiv. Any HTML5 elements which are cloned, or have had their parents cloned, will lose their identity.

Notice how the below element has colons in its nodeName, meaning it’s being confused for an element from another namespace.

var n2 = n1.cloneNode(true);
alert(n2.innerHTML);  //outputs: <:section>Sect 1</:section>

This happens even if the node was already attached to the document.

There isn’t much we can do here except roll out your own implementation of cloneNode, which is trivial enough.

Pitfall 3: Printing

Whenever you print a webpage, IE appears to generate a new document before printing which means all the shiv workarounds are not preserved.

There isn’t much you can do to mitigate this. The HTML5Shiv tool works around this by listening for the onbeforeprint event and replacing all the HTML5 elements on the page with normal elements and then doing the reverse on the onafterprint event.

Thankfully, the HTML5Shiv tool does that nicely for us.

References

• The HTML5Shiv tool: https://github.com/aFarkas/html5shiv
• The story of the HTML5 Shiv: http://paulirish.com/2011/the-history-of-the-html5-shiv/

Do you use the hgroup element in your mark-up? It’s probably best not to — the tag is being dropped from the HTML5 specification.

We normally think of HTML5 specifications receiving additional features, such as the new <main> element. However, elements can be removed if they offer no compelling benefits.

hgroup represented the heading of a section and normally contained two or more h1 to h6 child elements, e.g.

<hgroup>
<h1>My Main Heading</h1>
<h2>A sub-heading</h2>
</hgroup>

Did you ever use it? I can recall one occasion and, even then, it was primarily for use as a CSS hook and could have easily been a div or section. The request to remove it came from Steve Faulkner:

• hgroup does not convey clearly that a particular heading is a sub-heading
• heading semantics are still exposed regardless of an outer hgroup
• the specification stated all hgroup headings must be concatenated for accessibility, i.e. the title would become “My Main Heading A sub-heading”
• hgroup did not have at least two reasonably complete interoperable implementations, i.e. it was a div by another name
• few sites implement the hgroup element

No reasonable use-cases were forthcoming so hgroup will ultimately disappear from the HTML5 specification. There is a possibility it will morph into another element offering better semantics, but those debates are yet to occur.

No … I Use hgroup On Every Page!

The removal of hgroup will make little difference to your daily coding efforts. Most browsers already support it and, even in a new applications, hgroup would be treated the same as any unknown tag. That said, it’s probably best to avoid using hgroup in new projects since HTML validators will eventually report an error.

Take a look at this media query demonstration page in Chrome. Now adjust the width of your browser and reduce the body below 800px. As soon as it reaches 799px the background color and media query detection text will change.

Now load the same page in Firefox, Opera or Internet Explorer 10 and resize the browser again. It will depend on your OS and configuration, but you’ll discover you must reduce the size around 20 pixels further to fire the same media query event. On my PC it reacts at 782px:

Why? Let’s look at the W3C media query specification for width:

The ‘width’ media feature describes the width of the targeted display area of the output device. For continuous media, this is the width of the viewport (as described by CSS2, section 9.1.1 [CSS21]) including the size of a rendered scroll bar (if any).

It couldn’t be any clearer: Chrome or, more specifically, the Webkit rendering engine (soon to be Blink) is incorrectly ignoring the scrollbar and reacting too early. That appears sensible since scrollbar widths vary between systems, but it’s going against the W3C standard (perhaps another reason to reject the WebKit monoculture?)

There are technical solutions to the problem. For example, mqGenie detects non-Webkit browsers and calculates the scrollbar width so you can subtract it from the browser’s reported viewport dimensions. But you shouldn’t use it…

If your responsive design is so fragile that 20 pixels either way causes layout problems, you aren’t doing it right!

Responsive Web Design permits fluid layouts to be interspersed by breakpoints. Those breakpoints may be simple (such as modifying a font size) or implement more complex changes which rearrange columns and grids.

Unfortunately, fluid layout design skills became a lost art during the past decade. As I commented in 2009, fixed width has become the norm. Fluid layout may be one of the medium’s biggest strengths but designers often struggle with the concept.

RWD addresses many of the criticisms of fluid design but adds further complications. It’s therefore tempting to use media queries to implement a series of fixed width layouts — and that’s when browser issues such as scrollbar assumptions bite.

Here are my three golden Responsive Web Design recommendations:

1. Investigate and experiment with fluid design techniques before attempting RWD.
2. When creating a responsive template, start with the simplest mobile-first layout and work toward more complex desktop designs (see also How to Use Responsive Web Design to Support Old Browsers).
3. Forget pixels — use proportional units such as %, em and rem for font and element dimensions. Even if your final design must have fixed dimensions, create a fluid layout and set the outer element’s width accordingly.

It’s a different way of thinking but persevere. Inflicting paper-like restrictions on web design reduces the possibilities and makes Responsive Web Design more difficult than necessary.

In a surprise statement released last week Google announced that Chrome and Chromium are to adopt a new rendering engine named ‘Blink’. Blink is a fork of Webkit introduced because:

• Chrome uses a different multi-process architecture to other Webkit browsers
• It provides Google with further performance improvement opportunities.

Google stated:

Blink’s mission is to improve the open web through technical innovation and good citizenship.

We believe that having multiple rendering engines — similar to having multiple browsers — will spur innovation and over time improve the health of the entire open web ecosystem.

All very noble. But was Google’s decision politically motivated? Webkit is open source; there are no technical reasons why Google couldn’t implement improvements. However, Webkit is largely controlled by Apple — a competitor. At best, Safari would have the same technologies. At worst, Apple could block features which offered Google a competitive advantage (such as Dart).

Regardless of the reasons, Blink is good for the web.

Webkit has never been a single rendering engine so another fork will have little immediate impact. Over time, Blink will proceed along a different path unencumbered by Webkit stakeholders. The engine will be one of Google’s top priorities and should evolve rapidly.

Blink will appear in Chrome 28 and also be adopted by other browsers based on Chromium — including the new version of Opera and RockMelt. We may have lost Presto, but Blink goes some way to redress the balance. The web has four major rendering engines once more — even if two will be mostly identical for a few months.

Will There be a New Vendor Prefix?

No. Blink will continue to support some -webkit prefixes for legacy compatibility but all prefixes will eventually disappear. Experimental DOM, CSS and JavaScript features will be available without a prefix but the developer must enable those facilities with a single setting in about:flags.

I’m not wholly convinced it’s a major improvement. Unless other vendors embrace the policy, developers will have the same number of prefixes to manage and remember (or forget).

Other Downsides?

Apple has most to lose. Webkit’s development team has been cut by 50% and the engine has just lost almost 40% market share. The web is everything to Google but a distraction for Apple; Safari could fall behind other browsers.

Testing has also become a little more difficult for web developers. While you could never rely on Chrome-compatible code working in Safari, differences were rare. That’s no longer the case.

The situation was complicated further when Apple dropped Safari on Windows. Windows developers must either buy a Mac, hope other Webkit browsers are close (Dooble, QupZilla, SlimBoat) or rely on Apple providing test facilities like Microsoft did for OS X users.

Finally, while Blink is technically open source, it’s Google’s baby. Chrome’s dominance means Google can change Blink in ways that were not possible before. The company could be dictating web standards before we know it — especially if they enable non-prefixed features which operate differently in other browsers.

Despite the pitfalls, Blink seems an appropriate name — the web’s future just became a little brighter.

Unless you think otherwise?…

March ended one week ago but, just as you think the browser market is stabilizing, Google puts another spring in its step. Here are the latest figures according to StatCounter…

Worldwide Browser Statistics February 2013 to March 2013

The following table shows browser usage movements during the past month.

Worldwide Browser Statistics March 2012 to March 2013

The following table shows browser usage movements during the past twelve months:

The tables show market share estimates for desktop browsers. The ‘change’ column is the absolute increase or decrease in market share. The ‘relative’ column indicates the proportional change, i.e. another 5.9% of IE7 users abandoned the browser last month. There are several caveats so I recommend you read How Browser Market Share is Calculated.

Just as I think Google cannot possibly increase their share further, Chrome takes another 1% bite of the browser market. The last time this occurred was July 2012. To put it into context, that’s the equivalent of every Opera user or all combined IE6 and IE7 users abandoning their browser in a single month.

Chrome was the only mainstream browser with positive growth last month and it’s clear other vendors are struggling to compete. Does Google have an unfair commercial advantage? Few users pass a day without using the search engine, GMail, Analytics, Reader or another vital service which politely suggests they switch to Chrome. Google also has the cash reserves to promote their browser on prime-time television, at the movies, in newspapers and magazines. And let’s not forget Google controls the world’s most-used smartphone platform and Chrome OS.

That said, advertising would be worthless without a good application. Developers like Chrome. Users like Chrome. Even the most ardent IE, Firefox, Safari and Opera fanboys have little bad to say about the browser. It may no longer enjoy significant technical advantages but other vendors must either produce more competitive software or hope Google becomes complacent.

IE9 has been hovering around 18% for six months but IE10 has begun to cannibalize its share following the recent Windows 7 update. At the end of March, IE9 had 15.81% and IE10 2.26%. IE8 dropped more than any other browser and looks likely to fall below 10% this month. IE6 and IE7 barely changed but they’ve become mostly insignificant.

Firefox fell another 0.5% and it’s starting to look like a monthly trend. The browser works well on Windows and is more than a match for Chrome but I suspect it’s lost most ground on Mac, Linux and mobile platforms. Unless Mozilla can convince users to stay, Firefox could drop below 20% by the end of May 2013.

Safari had a better month than most but almost 6% of Opera users abandoned the desktop browser. That could be a statistical anomaly or perhaps users are unimpressed with the company’s switch to Webkit? Let’s see how they fare on mobile devices…

Mobile Browser Usage

Mobile usage increased a fraction to 14.44% of all web activity during March 2013.

The primary mobile browsing applications:

1. Android — 30.78% (down 0.76%)
2. iPhone — 24.44% (up 0.08%)
3. Opera Mini/Mobile – 15.54% (up 0.14%)
4. UC Browser — 8.27% (down 0.07%)
5. Nokia browser — 6.96% (up 0.05%)

It’s difficult to spot trends because the mobile market is erratic and influenced by local factors. For example, the iPhone is massively popular in western countries, but less so in Asia, Africa and South America where Android and Opera compete for the top spot.

There’s been a slightly unusual fall for Android but I wouldn’t read too much into that. The Chrome mobile browser has a 2.02% market share and is starting to increase as rapidly as its desktop cousin. Google is everywhere.

Version numbers may be meaningless but Firefox 20 marks a milestone for Mozilla’s flagship browser. The new release appeared on April 2 exactly six weeks after version 19. If you don’t have it, open Help > About Firefox or download the browser from getfirefox.com.

Firefox 20 has a surprising number of new features — let’s look at the best…

Developer Tool Updates

Firefox has received an incredible number of tools within the past few releases. The Developer menu has been reorganized to order them more effectively and a new Toggle Tools option provides quick access to the Web Console. The Console can also be viewed within its own panel as well as docked.

A new JavaScript Profiler had been promised for version 20 but the feature has been delayed for a later release.

New Download Manager

If I recall correctly, this is the first major update to the Download Manager since it appeared in Phoenix back in 2002. The dedicated panel has been replaced by a drop-down list accessed by a new toolbar icon which highlights the time remaining:

It’s a nice touch. Previous downloads are still logged in bookmarks and history panel.

getUserMedia Support

Firefox now provides the getUserMedia HTML5 API which has been available in Chrome and Opera for several months. With the user’s permission, you can capture audio and video from a microphone or camera. Opera’s Photo Booth provides an excellent demonstration of the technology.

canvas Blend Modes

When you draw on a canvas element any existing pixels are normally replaced. However, the new globalCompositeOperation property permits Photoshop-like overlay effects including multiply, screen, darken, lighten, color-dodge, color-burn and difference. Refer to this Mozilla article for more information.

Audio and Video playbackRate Support

Have you ever wanted to watch a tedious movie at double-speed? The playbackRate property permits just that (apologies for the inline code):

<video id="v" src="video.webm" controls autoplay></video>
<a href="#" onclick="document.getElementById("v").playbackRate=2;return false;">fast foward</a>

View a demonstration movie…

Improved Private Browsing

Private browsing prevents Firefox updating your history, caching pages, saving passwords and storing cookies.

While it’s been available for some time, clicking “Start Private Browsing” from the menu would close your current window and start a new session. From version 20, Firefox permits you to have any number of private and non-private windows open at a time.

Better Plugin Stability

Browser stability is largely irrelevant if your plugins cause chaos. Fortunately, the new version of Firefox detects hanging plugins and allows you to close them without restarting the browser. I doubt it will end plugin problems but it’s a step in the right direction.

Want More?

Firefox developers had a busy six weeks…

• CSS and JavaScript now load with a higher priority than images to improve response times.
• various ECMAScript 6 additions
• performance improvements
• a dozen security fixes.

I’m not sure how long Mozilla can keep up the pace of development, but other vendors should take note (seriously Google, could you only manage a spell checker in Chrome 26?!)

IE10 brings Internet Explorer closer to Chrome and Firefox than it’s ever been. However, if you’ve visited a geek conference recently, you’d have noticed a proliferation of Macs — which can’t run the browser. That’s a problem for Microsoft…

• A large number of developers probably aren’t bothering to test sites in IE.
• Those who do, often test it very late in the development cycle.
• The inevitable problems lead to “IE’s still awful” comments. While IE10 may cause no more issues than any other browser, the mud sticks.

Microsoft released modern.IE in February. The site offers a page scanner, free virtual machine images, three months’ free subscription to BrowserStack and compatibility advice. However, to celebrate Microsoft’s sponsorship of the Webby Awards, several new features have been introduced today…

Free Parallels and Windows 8 USB Sticks for Mac Developers

If you’re a Mac developer, it can be difficult to justify the license costs for Parallels and Windows. Microsoft has made that decision a little easier for you by shipping free USB sticks with full copies of Parallels 8 and Windows 8.

The catch? There’s a limited supply — so act quickly — and Microsoft would like you to send a $25 donation to your favorite charity. Sounds like a good deal to me.

New Virtual Machine Images

Two new virtual machines are available: IE10 on Windows 7 and IE8 on Windows XP. Both remain free and all VMs are now available for Parallels on the Mac as well as Hyper-V, Virtual PC, VirtualBox and VMware on other platforms.

Scan Sites Behind Firewalls

It’s now possible to install a local instance of the modern.IE webpage scanner so you can test intranet applications or websites which have not yet launched.

Guess what platform the scanner requires…

You’re wrong! It’s node.js. That’s a surprisingly sensible choice which means it’ll run on Windows, Mac OS and Linux out of the box.

The scanner has a number of useful new features:

• deeper scanning with ‘how to fix’ suggestions
• responsive web design analysis
• touch optimization hints, and
• assistance for sites which have blocked Flash content.

Better Internationalization

modern.IE is available in 18 languages including Arabic, Chinese, Dutch, French, German, Italian, Japanese, Korean, Russian, Spanish, Swedish, Thai, Turkish and Vietnamese.

It’s good to see modern.IE evolving and Microsoft making life a little easier for web developers. Now, if only we could persuade Apple to release Safari on Windows again…

A pre-release build of Windows Blue, Microsoft’s successor to Windows 8, was leaked a few days ago. It may have been intentional or unintentional but the OS was installed, dissected and reported across the web.

The new OS contained an early version of Internet Explorer 11. A very early version. Probably nearer IE10.01. There’s little new technology to report, but one update caused a storm of controversy on SlashDot and Neowin.net: IE11′s user agent string appears to impersonate Firefox…

Mozilla/5.0 (IE 11.0; Windows NT 6.3; Trident/7.0; .NET4.0E; .NET4.0C; rv:11.0) like Gecko

The ‘MSIE’ string has disappeared and a suspicious ‘like Gecko’ statement has appeared. Cue 1,000 conspiracy theories.

Historically, browser vendors and developers have been doing the user agent dance since the dawn of the web. The problem starts when you attempt to create a cross-browser compatible website:

1. A developer creates a website in browser X then tests it in browser Y.
2. Browser Y fails, so the developer writes browser Y detection routines and serves different code. Everyone is happy.
3. Browser Y is then updated — but the website now fails because it’s serving legacy code.
4. The vendor changes the user agent string: detection fails and the site works again. Everyone is happy and we loop back to step one.

Look at the start of IE11′s user agent string: Mozilla/5.0. The early versions of IE had to masquerade as Netscape because it was the dominant browser and many sites refused to return content to anything else. The situation continues today — IE, Chrome, Safari and Firefox all start with ‘Mozilla/5.0′…

IE10:
Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2; WOW64; Trident/6.0)

Chrome 25:
Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.22 (KHTML, like Gecko) Chrome/25.0.1364.172 Safari/537.22

iPad Safari 6:
Mozilla/5.0 (iPad; CPU OS 6_0 like Mac OS X) AppleWebKit/536.26 (KHTML, like Gecko) Version/6.0 Mobile/10A5355d Safari/8536.25

Firefox 19:
Mozilla/5.0 (Windows NT 6.2; WOW64; rv:19.0) Gecko/20100101 Firefox/19.0

You’ll also notice both Chrome and Safari use the same ‘like Gecko’ string as IE11. I don’t recall that bombshell hitting the headlines?

The biggest change in IE11 is the removal of ‘MSIE’. I suspect that has been done for one reason: to prevent sites serving invalid IE6/7/8 code to modern editions of the browser. Recent releases of IE’s Trident engine are closer to Gecko or WebKit than legacy editions of itself. By removing the ‘MSIE’ string, Microsoft is breaking detection code and making many sites work as they should.

The point is: none of this matters. If you’re browser sniffing, you are almost certainly doing something wrong! While it seems an obvious solution, browser sniffing is a fragile technique that introduces more maintenance headaches than it prevents. If you know someone who sniffs, please suggest they close their IDE, step away from their browser and embark on another career.

The past few days have not been kind to web developers. Google announced they were scrapping their popular RSS Reader application and that overshadowed news from Adobe that Browserlab was being closed with immediate effect.

Browserlab started as a free browser testing service in 2009. Testing web sites and applications is notoriously difficult owing to seemingly infinite combinations of device, OS, browser, plugins and configurations. Desktop software developers — you have it easy! You can normally concentrate on one or two operating systems. However, people expect web applications to work no matter what. It doesn’t matter whether they’re running IE10 on Windows 8, Safari 6 on Mac OSX, Chromium on Ubuntu, Firefox on Android, Lynx on a Commodore 64 or — even worse — IE6 on XP.

Browserlab was one of a number of online services available for web developers which helped spot the worst layout problems. Adobe disclosed their reason for closing the system:

The growth of the importance of mobile devices and tablets, the landscape has changed dramatically. Because of this shift, we have seen the usage of BrowserLab drop over the past year while at the same time our engineering team has been focusing on solving this new challenge with new solutions.

We’d like to thank all of our customers over the years for using and providing input for the Adobe BrowserLab Service.

I find the announcement slightly strange. Testing has become more difficult so you would have expected the number of BrowserLab users to increase? Admittedly, it was not as good as competitors and did not support mobile devices but it remained a viable service for the majority of us testing desktop-based browsers.

Fortunately, BrowserLab users have a couple of good alternatives (take note Google):

1. Sauce Labs — BrowserLab users receive up to 10 hours of free testing
2. BrowserStack — there are no specific offers for BrowserLab users, but head over to Microsoft’s modern.IE website to receive three months free service.

So goodbye BrowserLab. Let’s hope this is the last essential service to disappear this week…

If you’re one of the 50% of PC users with Windows 7, be prepared for an essential update coming your way. Internet Explorer 9 has been officially retired to make way for IE10. The new browser will be installed as part of the standard Windows Update unless you explicitly prevent it (please don’t!)

It’s an important milestone for web developers. While IE9 was a radical step up from IE8, it was missing features we take for granted in Safari, Firefox, Chrome and Opera: CSS3 gradients, text shadows, animations, transitions, column layouts, flexbox, ECMAScript strict mode, media query listeners, the file API, web workers, local storage, etc. IE10 plugs many of the HTML5 gaps.

There’s another vital feature in IE10: automated updates. While Microsoft are yet to use it, IE10 can receive smaller incremental tweaks over time. I’m not expecting a Chrome or Firefox-like six-week delivery schedule, but two or three times per year would be significantly better than the current 18-24 month delay.

IE9 is likely to die rapidly especially since system administrators will not experience the upgrade issues which dogged previous versions. It will remain the default browser on Vista but the OS currently holds 6% of the PC market and is dropping fast.

IE6 and IE7 are dead. They still roam zombie-like across certain sectors of the web but, for most of us, the days of IE-specific hacks and fixes are long gone.

The IE8 Problem

Which leaves us with IE8. The browser holds 10% of the market and is the only version available for Windows XP which is used by one quarter of PC users. Many have stated that IE8 is the next IE6 (including me), but I’ve recently revised my pessimistic opinion…

• It depends on the statistics you believe, but competition from Google has changed the market. Chrome can be installed on XP, is advertised throughout Google’s ecosystem and light years ahead of IE8.
• IE8 usage is dropping by 0.5% per month. If the trend continues, it will hold just 5-6% of the market by the end of 2013.
• IE8 may not support HTML5, CSS3, SVG or media queries but it has few of issues we had to deal with in IE6 and 7. Your site will be missing rounded corners and drop-shadows, but the HTML5 shim will fix the majority of layout problems. It may not be pretty, but your site should work.
• IE8 is two versions old. Version numbers rarely matter to developers but it’s an important psychological gap for your clients.

It would have been great had Microsoft released a version of IE10 for XP and Vista but it’s probably not worth the effort. IE8 will die a natural death regardless of Microsoft’s aging OS platforms.

But let’s look at the positives: IE10 does much to catch up with the competition. It’s taken too long to arrive but I hope it becomes the most dominant version of IE within a few short months.

Owing to my rapidly increasing age I’ve used many, many IDEs and text editors over the years. Visual Studio, Aptana, Eclipse, HomeSite, CoffeeCup, Bluefish, Komodo, Vim, Crimson, jEdit, TextPad, PSPad, ConTEXT, PHPEdit, ScITE — I’ve probably forgotten more than I remember. Most annoy me. They often miss features I want or add bloat I don’t need. My current editor of choice is Notepad++: it’s simple, lightweight and very configurable.

Historically, HTML editors have been fairly awful. Many IDEs forced you to create dumb projects, insisted on particular doctypes, or favored deprecated tags. JavaScript editing could be worse: the editor programmers didn’t understand the language so even basic features such as function lists could fail.

Fortunately, the situation has improved and NetBeans 7.3 has been released with full support for HTML5, CSS and JavaScript. The cross-platform IDE now includes an HTML project wizard which allows you to select popular boilerplate templates and JavaScript frameworks:

There’s a lightweight internal server, embedded WebKit browser, Chrome integration and responsive web design facilities:

CSS styles can be edited directly or changed within the Inspector-like rule editor:

The JavaScript editor has been rewritten to include better code completion, jQuery support and pattern recognition:

There’s also a new debugger which can analyze code running in the internal browser or Chrome. You can apply breakpoints on lines, when a DOM element changes, when events are raised and when Ajax requests are called. Very useful:

Finally, there’s a great browser log which displays exceptions, errors and warnings as they occur:

Don’t forget that NetBeans also provides first-class development facilities for PHP, Java and C/C++. If you’re into that sort of thing.

It’s great to see client side browser technologies finally receiving the tools they deserve. I’m going to give NetBeans another look … will you?

NetBeans is available for free from netbeans.org.