My idealistic view is that the web should work for everyone, regardless of their method of access. Idealism always takes second place to pragmatism, however; I know that we have to work within our limits, we can’t provide a first-class experience for everyone all of the time. So where do we draw the line for browser support?

The answer is the same as always: it depends.

When making the decision, you should use a Cost-Benefit Analysis (CBA). The cost includes your resources: how much time you have, how much money, the staff you have available. All of these are finite. The benefit (or lack of) is mostly to your users: not only the ones who may be excluded, but also the others who could get a reduced service if you have to divert resources to legacy support.

In 37Signals case they know their users well, they’ve done this before and obviously feel the benefits are greatly in favour of their current user base. If someone can’t get access to their website it’s not the end of the world, there are alternatives available.

But your market may be different. You may not even know your market. Telling people that they must update their browser is making a lot of presumptions about them:

• That they are aware of what a browser is. A lot of people aren’t. It’s why Google are spending millions on a global campaign (not entirely selflessly, of course).
• That they have the ability to update it — and I don’t just mean technical ability, but cognitive and physical ability too.
• That the technology they use supports updating or using alternative browsers. Many (most?) of the devices I know do, but I’m not aware of the technology markets across Africa and Asia, for example.

Most importantly, you must assess the benefit of the content — or the lack of access thereof — to the user. You could be building a site about healthcare which contains content that could save lives — literally vital information. Christian Heilmann recently posted browser stats from a healthcare site which showed that ~50% of visitors were using a browser which wouldn’t meet 37Signals’ criteria.

With all that in mind, after we’ve done the CBA I would say that the very least consideration of ours should be how easy it is to do something. I said in the discussion that “we play the cards we’re dealt” — that wasn’t intended to be a statement of passivity, but rather one of acceptance that we don’t control our users. If they use IE6, we build for them. We can educate and encourage, but only up to a point. Beyond that point we start to become arrogant.

So that’s my opinion, I look forward to hearing yours.

@media -o-paged {}

Then use new values for the overflow property on the scrollable element to control whether the pagination moves horizontally or vertically, and whether or not on-screen controls are shown, like so:

@media -o-paged {
  html {
    height: 100%;
    overflow: -o-paged-x-controls;
  }
}

This paginates the whole document horizontally, and adds controls. To see this working, you’ll need to download a copy of the Labs build (available for Mac, Windows, Linux and Android), then you can visit this example page from Dive Into HTML5 I quickly set up. Navigate by dragging/swiping, cursor keys, or the native controls.

I really like this; it’s still early days, but the syntax seems clear and logical and works well in the demos I’ve seen, and I think it’s going to be really useful as the web migrates away from the desktop and onto other connected devices. More information and examples are in the ‘Paging the Web’ article on Håkon Wium Lie’s website, and I’ll definitely be delving further into this.

There were long talks and shorter breakout sessions, as well as plenty of time to socialise; the LWS must really be congratulated on organising such a good event. There was plenty of news and talking points throughout the day — far too much, really, for me to write here, so I’ll just write up notes of what I found most interesting to me.

After a fun introduction from Terence Eden, the first full session was by Michael Mahemoff of Google. He showed that Chrome’s V8 JavaScript engine is now some 700% faster than when it was first released, and then mentioned a few features that have just landed (or are about to land) in the browser: the HTML5 File System, Shared Workers, and Server-Sent Events. The big round of applause, though, was reserved for speech input in forms, which is supported in Chrome (dev channel) right now; you just need to add the attribute x-webkit-speech:

<input type="text" x-webkit-speech>

He also showed off the Chrome Web Store and a neat little utility, Appmator, which you can use to easily publish your own app. His slides are available online, but they only work in WebKit browsers. :(

Next was Paul Rouget of Firefox, showing off a load of neat demos of the capabilities of open web media, many of which can be found at Mozilla’s Web O’ Wonder. He also demonstrated them all running perfectly on Firefox Mobile, which pretty much has feature parity with its desktop sibling — indeed it may even have more, as it includes the Notifications API which isn’t in Firefox desktop yet. There’s a cool little dashboard demo which showcases many of Firefox 4’s new features, and an impressive mobile version which doesn’t seem to be online yet.

He then talked about Firefox’s new release schedule, which is moving to quarterly releases meaning that Firefox 7 could be out by the end of this year. Features planned for inclusion in Firefox 5 include Web Sockets, Server-Sent Events, the Fullscreen API, Notification API, and an Account Manager. No mention of what Firefox 6 may have, but Firefox 7 may include an update to the Gecko engine.

Chris Mills of Opera was next. In his talk, A Matter of Good Form, he focused a lot on Opera’s implementation of HTML5 Forms, which it must be said are streets ahead of anyone else. I’m putting together a couple of posts on forms, so I’ll save discussion of this until that time.

After lunch there were some breakout sessions to choose from. I attended first Google’s Malte Ubl’s session, Performance Optimization for HTML5 Apps. In fact this was a really good overview of performance best practices, not limited to only HTML5 apps. One of his points was to let the browser take as much of the work from the JS engine as it can; use CSS transitions instead of JS animations where possible, as this uses the browser’s hardware acceleration and therefore less processor resource. Another was to interact with the DOM as few times as possible, and to also to group those interactions; if your JS is currently structured Read-Write-Read-Write, changing it to Read-Read-Write-Write means less DOM interaction, and increased speed.

An interesting aside: he said that this generation’s equivalent of zoom:1 (which triggers hasLayout in older versions of IE) could be:

E { transform: translate3D(0,0,0); }

This triggers hardware acceleration on elements which don’t already use it (in Safari, at least). I think this may have been partly a joke, however!

The second session was The Dos and Don’ts on the Mobile Web by Blackberry’s Mathew Staikos, which covered some similar ground but had more good tips, notably not to use position:fixed with WebKit Mobile — it can cause a complete repaint after every scroll action! Also, use touch events where possible as they’re faster than click, which has to wait anywhere up to 500ms to see if the action will be doubleclick before firing. He also used a tool I hadn’t seen before which provides information about the version of WebKit you are running. His colleague Sanyu Kiruluta then gave us a very rapid overview of the Blackberry App World (link is Windows-only) and their tool WebWorks, which is similar to Phonegap.

To round the afternoon off we had a Q&A with all of the main speakers, then off to the pub for a free beer courtesy of BlackBerry. Thanks, BlackBerry, and thanks again to everyone else who organised, spoke and attended.

NB: I’ll update this post with more slides and videos from the event as they become available.

Recently I read this piece of hyperbolic link-bait: IE9 is the IE6 of CSS3. In the article the author bemoans the fact that a layout he’s created using some new CSS3 features doesn’t display well in IE9. His complaints betray his basic misunderstanding of software development, the standards process, and Microsoft themselves.

Browser makers are under no obligation to include CSS3 features just because other browsers do. Just because WebKit proposed a bunch of new modules and the W3C have agreed to open a consultation on them, doesn’t mean they are an ‘official’ part of CSS3. In Microsoft’s case they also have a policy of not implementing features that don’t have a full suite of tests; one of the features in the article that the author mentions is the Flexible Box Layout module, which is far from complete — Firefox and WebKit have it implemented, but it behaves differently in each and the spec is still undergoing revision.

Also, it must be remembered that IE9 is still in Beta; new features are being added, removed and changed constantly. If you encounter an inconsistency in the way those features are implemented, stop griping and file a bug report. Personally, I’d favour a browser with fewer, more stable features than one which ships with non-conforming or badly implemented features (this is how we’d really end up with a new IE6). I actually think that IE9 provides a pretty good snapshot of the most stable components of CSS3, and I’m looking forward to seeing it adopted by users.

So, onto the gripe. With all of the hard work that the IE dev team have put into bringing their browser up to scratch in the last few years, it must be immensely dispiriting for them that nobody else within Microsoft seems to want to use it. First we had the news that Outlook was to use Word as it’s default HTML renderer*, and now we have the launch of Windows Phone 7 with a modded version of IE7 as its browser.

IE7 was, essentially, a bug-fix version of IE6. It is not a modern browser, and not in the same league as the Mobile versions of WebKit, Firefox and Opera. It has none of the features which make those browsers so useful. If you’re building a website for touch-enabled smartphones you now have to take into account that if you want to support Windows Phone 7, you have to work around the lack of geolocation, local storage, offline storage, SVG, canvas and much more.

The only saving grace in this is that apparently the browser has been implemented in a way which means it can be updated separately from the rest of the software, so improvements can be made without a full firmware update. I hope that this is the case, and that updates are made frequently, and soon.

* It seems that future versions of Outlook (on Mac, at least) may use WebKit.

You can read an in-depth review of it at ZDNet, except it seems to be written by someone who doesn’t really understand CSS very well.

In page five of the review he provides comparisons of the code required to get a rounded corners effect on an element, claiming that this is what’s needed for it to work in Chrome:

border-bottom-left-radius: 152px 152px;
border-bottom-right-radius: 228px 228px;
border-bottom-style: solid;
border-bottom-width: 42px;
border-left-style: solid;
border-left-width: 42px;
border-right-style: solid;
border-right-width: 42px;
border-top-left-radius: 152px 152px;
border-top-right-radius: 304px 304px;
border-top-style: solid;
border-top-width: 42px;
padding-bottom: 12px;
padding-left: 12px;
padding-right: 12px;
padding-top: 12px;

This is — not to put too fine a point on it — crap. Chrome will accept the shorthand properties in exactly the same way as IE9, Safari, Opera and Firefox.

Speaking of that latter browser, he also states that the –moz– prefix is required for border-radius:

-moz-border-radius: 152px 304px 228px 152px;

But as we’re dealing with Beta releases, then he should also make clear that in the latest Firefox Beta the prefix is no longer needed.

When the Betas become release versions, we’ll be able to use the same code cross-browser:

border: 42px solid orange;
border-radius: 152px 304px 228px 152px;
padding: 12px;

There’s nothing wrong with not knowing CSS, but if you don’t know it then maybe you shouldn’t make a point of using it in an example.

<a href="http://example.com">
  <div>
    <h3>I'm an example</h3>
  </div>
</a>

You can begin to use this straight away, as every browser supports it — although you must be wary of one rather glaring bug in Internet Explorer.

The bug occurs if you try to nest other a elements inside the block-level one, as shown in this example markup:

<a href="http://example.com">
  <div>
    <h3><a href="http://example.com">I'm an example</a></h3>
  </div>
</a>

With this markup IE7 fails to render some elements, and IE8 and IE9 create an empty, ‘phantom’ element. I’ll show you what I mean, starting with the way this markup should render; on the left is the HTML markup as it displays in your browser, and on the right I’ve placed a screenshot from Firefox to act as a comparison.

And now see how they appear in IE7 (left) and IE8 & IE9 (right):

As you can see, in IE7 the h3 element loses its background color and margin, and in IE8 & IE9 there’s an empty box above my markup; this is the ‘phantom’ element, which is inheriting the border from the div element, and the margin-bottom from the h3. Were I to add margin-top (or further properties that affect the box model) to my markup, they would also show up here.

Strangely, this bug doesn’t seem to occur in IE6.

The fix is quite simple: don’t nest a elements. I only did it as I needed an element to create a particular style effect, but it can be done just as easily with a span. I tried a number of other approaches but this seemed to be the only one that worked.

Update: As has been pointed out in the comments, nesting a elements is in fact prohibited by the HTML5 specification. I’ll leave this post here for the other people like me who weren’t aware of that.

Firefox do a great job of this with their website The Burning Edge, which gives fortnightly (more or less) lists of changes in the latest trunk builds, and Opera’s Desktop Team Blog does likewise on a semi-regular basis. The Internet Explorer team have done a good job of documenting all the changes in IE9 with the Platform Preview Release Notes.

The notable exception seems to be WebKit. I’ve looked around but I can’t find any site which gives an overview of changes in the nightly builds. I could subscribe to the RSS feed of their Trac, but it would be a nightmare trying to find the interesting features amongst all the technical changes. The Surfin’ Safari and Planet WebKit aren’t any help.

So does anyone know how to find this information for WebKit? I can’t believe it doesn’t exist.

Update: As if by magic, look what I found just a day later: Last week in.. WebKit and Chromium!

If you have a nightly build of Firefox you can see a little demo I’ve put together of them in action.

The first new property is –moz-calc, which is the experimental implementation of CSS3’s calc function. This allows you to perform simple mathematical functions on length values.

Take a look at the demo, where you’ll see two h2 elements; both have the same styles applied to them, but the second also has some extra calc values for some of its properties:

font-size: -moz-calc(120% * 3);
letter-spacing: -moz-calc(0 + 2px);
text-shadow: rgba(0,0,0,0.33) -moz-calc(4px / 2) -moz-calc(4px / 2);
word-spacing: -moz-calc(0.75em - 0.25em);

The font-size property has a value of 120% * 3, or 360%; the letter-spacing property has a value of 0 + 2px, or 2px; the text-shadow property has x and y offset values of 4px / 2, or 2px; and the word-spacing property has a value of 0.75em — 0.25em, or 0.5em.

The values themselves are abitrary and not important; what matters is that we’re doing calculations in CSS!

At the moment the only properties which support –moz-calc values are:–moz-column-rule-width, –moz-column-width, letter-spacing, word-spacing, marker-offset, outline-offset, border-spacing, text-shadow and –moz-box-shadow; but work is underway to add this to all properties which accept length values.

Update: You can read more about calc() at hacks.mozilla.org.

Also implemented is a new selector, :-moz-any. With this you can group other simple selectors, removing the need for repetitive code. Consider, for example, a typical web page which has many types of list, and nested lists:

<ul>
  <li>We are all list items now
    <ul>
      <li>We are all list items now</li>
    </ul>
  </li>
</ul>
<ol>
  <li>We are all list items now
    <ul>
      <li>We are all list items now</li>
    </ul>
  </li>
</ol>
<menu>
  <li>We are all list items now
    <ul>
      <li>We are all list items now</li>
    </ul>
  </li>
</menu>

If we wanted to select all of the li children of nested ul elements we would currently have to do this:

ul ul li, ol ul li, menu ul li { property: value; }

But with –moz-any we can group the selectors like so:

:-moz-any(ul,ol,menu) ul li { property: value; }

In my demo page I’ve provided a couple of examples; the first selects all list types which are direct child elements of the body:

body > :-moz-any(ol, ul, menu) {
	float: left;
	width: 33%;
}

And the next selects list items of the lists which are children of those elements:

:-moz-any(ol, ul, menu) ul li {
	font-weight: bold;
	margin-left: 0;
}

The :any selector isn’t in any of the CSS3 modules, but it’s pretty useful and definitely a candidate for inclusion. You can read more about it on the blog of David Baron.

Update: Changed the examples for clarity.

Has anyone reading this ever seen an example of these in action? I’ve searched for demos but have found nothing. If you know anything about this, please leave me a comment; your help would be gratefully appreciated.