• Demos that work in one browser/engine only and aren’t updated even when other browsers implement the new features, are harmful.
• Using prefixed features as a way of actively excluding other browsers is lazy and anti-competitive.
• Including an unprefixed property in anticipation of eventual standardisation works against the principle of using prefixes
• When browsers have working, largely compatible, implementations of properties (like transform) they should remove the prefix even if the spec hasn’t reached the stage required by the W3C.

However, I still think using prefixed properties is the right approach. If we do as Henri suggests and leave experimental features in experimental builds (an eminently sensible suggestion, I might add), the pace of progress will be much slower. I believe that having these features out there and getting people using them encourages competition (and collaboration) between browser makers, and the benefits of that competition are given to us, the developers, and passed on to the audiences of the sites we build.

That doesn’t mean that the current situation is ideal; far from it. But improving things will involve more effort from us, the developers and writers, the community in general. Chief responsibilities will be:

• Commit to supporting old demos that we have made.
• Always make sure we plan our designs and builds in a way that they are not reliant on prefixed features, but degrade gracefully.
• Don’t use an unprefixed property before standardisation has happened unless we can have reasonable confidence that it is safe.
• Make sure we stress that the things we use and teach are experimental and subject to change.

As an author and writer I’m guilty of some of the faults that are pointed out in his article, and I promise to do better in the future.

In closing, I want to congratulate Henri on writing this thought-provoking post. I was ready to dismiss it as one of the lazy articles criticising prefixes that occur regularly, but the argument was very well thought and well made, and made me change my mind a few times while I was writing this post.

While I think the alternative syntax is pretty robust, I did detect a couple of flaws in it which I promised Mark I would write about, and that’s what I’ll do in this article. Before I get to that, I just want to quickly address one of the key points from his proposal.

Defining a Grid

grids have been around for quite a while and there is established words for things like Columns, Fields, Modules and Gutters. It’s my feeling that the CSS grid module should speak the same language as designers, not that of developers.

I’m not certain that I wholeheartedly agree with this; not that the Grid Layout syntax uses terms that are more familiar from tables or spreadsheets rather than typographic grids, as this is certainly true; but the contention in the second sentence, that the Grid module should be aimed at designers rather than developers.

The language of grids may be obvious to those that are trained in using them, but I wonder just how many people that includes. For the non-typographically savvy I think it’s not as literal; speaking for myself I find Rows and Cells more logical than Fields and Modules.

And while Mark’s proposed syntax works well for typographic grids, it does mean that making an irregular grid becomes extremely hard. Using the Grid Layout syntax you can make regular and irregular grids very easily, whereas this new proposal is really intended only to make one very strict type of grid.

Anyway, that’s kind of besides the point; I’m not strongly convinced of my own argument, just thought it was worth raising. But I’ll take Mark’s premise at face value and go along with the syntax that he proposes. If that’s a more logical way to think about grids, then the syntax seems pretty solid. There are, however, a few potential problems I can see with it.

Fractions

The first problem is that basing the grid on modules eliminates the effectiveness of the fr (fraction) unit. In the example in section 4 of the article a three column grid is created using this code (NB: I’ve changed some of the values a little to bring them into line with existing properties):

div {
grid-columns: 3md 1fr 2md;
grid-x-count: 10;
}

As this is on a grid made of 10 horizontal modules, the central column is five modules wide. But what if we used four columns, with two fraction units?

div { grid-columns: 3md 1fr 1fr 2md; }

That would make the second and third columns 2.5 modules wide. I’m presuming that we can’t have fractions of modules, so if the fraction unit can’t be used to create fractions then it becomes useless (or, at least, very hard to work with). In this case we should just go back to using the md unit for everything:

div { grid-columns: 3md 5md 2md; }

And if we’re doing it this way, then we don’t need the proposed grid-x-count property any more; that count can be obtained by the sum of the md units in grid-columns. This brings it a little closer to the existing Grid Layout syntax.

Breaking the Grid

The second problem is that the grid is now very hard to break out of. What if, after we’ve laid out our grid, we wanted to put an item that broke into the gutters:

How do I position that? Unlike in the Grid Layout syntax, gutters aren’t available as slots to position elements in. I could use relative positioning to move it into the gutter, but how do I also expand the element so that it’s larger than the modules it covers? Maybe with padding:

div {
left: -21px;
padding: 21px;
position: relative;
top: -21px;
}

But if, in this box model, padding is added to make the element bigger, then how would I put put internal padding on an element which I didn’t want to get bigger? A possible alternative solution to this would be to add a new property, something like:

grid-gutter-span: all;

This could also have the keywords top, right, bottom, left, or none, to provide flexibility to the elements that are placed in the grid.

Conclusion

For defining a typographic grid I think this syntax is pretty well thought out, certainly for a first draft, and the problems I’ve pointed out here are not insurmountable, but just require some more consideration. I hope that the feedback I’ve given is constructive — well, most of all I hope that I’ve understood the proposed syntax correctly and not made any stupid mistakes! If you’ve anything you’d like to add, feel free to leave a comment.

This is great for the future, but although you can start using these functions now (in many browsers), they aren’t without their drawbacks — well, one big drawback really. I’m going to explain briefly the problem, and then propose a solution.

How Form Validation Works

The simplest form of validation is to say that a field is required, which is done by adding the required attribute (it’s boolean, so needs no explicit value):

<input type="text" required>

This will check to see if a value is supplied, and returns an error if it isn’t. You can add parameters to validation by using the pattern attribute with a JavaScript regex value; for example, to only accept a numeric value you would use the following:

<input type="text" pattern="[-0-9]+" required>

Some field types have pattern validation baked in; email and url will only accept correctly formatted email addresses and URLs, respectively, while number and range can have maximum and minimum numeric values applied. There’s also a maxlength attribute to restrict the number of characters, which can also cause a validation error.

The Problem With Error Messages

Probably the biggest drawback of the validation process is that the error messages are, for the most part — and there’s no polite way to put this — ugly. Take a look at this image showing the validation error message in (from the top) Chrome, Opera, and Firefox:

I think the Opera message is the better of the three, but I think it’s fair to say that the designers weren’t having their best days when they made these. (I’m using Ubuntu here, but they really aren’t any better in any other OS.) The problem I have with these is that I’d like to use them, but I don’t think any designer I work with would find these acceptable and I’d no doubt end up using a JS implementation just to get some form of consistency.

Using JS is a short term solution, and there’s a good Validation API to aid in using it (which I aim to write about soon). But longer term we will need better-designed messages, or a way to style them ourselves, or both. I don’t think that the error messages need to look identical in every browser on every OS, but I do think they should be more closely aligned with the browser chrome and sympathetic to the OS; they should feel like a natural part of the platform, rather than an add-on.

A Proposal For Styling Error Messages

There’s no formalised suggestion for CSS styling of error messages, but I think it’s probably inevitable that there will be. This could take the form of a pseudo-element, perhaps something like:

input::error {}

This would allow us to set background, colour and font options. It may be necessary to also have a property to set where the validation error message appears in relation to the input it’s attached to; perhaps modifying position with values of above, below, before, or after:

input::error { position: below; }

And, perhaps, another property to set the appearance of the box which contains the message; perhaps the appearance property with values of box for a rectangle, or balloon for the current speech balloon style:

input::error { appearance: balloon; }

There’s also the text inside the validation error; the main message, and an optional extra which can be set with the title attribute (or JavaScript). These could have further pseudo-elements for finer control over the text formatting:

input::error-message { }
input::error-text { }

This is all straight off the top of my head, of course, and no doubt needs plenty of development; but as there’s no formal proposal at the moment, it’s a good time to be thinking about these things.

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.

I’ve no idea how the web video format war will end. My preference is that a free, non-patent encumbered, high-quality video codec will become the standard, and WebM is the best fit for that description. Despite the recent announcement by the MPEG LA, the patent pool which controls licensing of H.264, that it will always be free for ‘video delivered to the internet without charge’, that still doesn’t make it free-as-in-speech, and still not free-as-in-beer for anyone wanting to build a business around video encoding/decoding (which includes, if I’m not mistaken, bundling it with a browser). All that said, my preference is meaningless in the face of so many vested business interests.

But this post isn’t really about that; it’s about clearing up a misconception. One common statement I keep seeing repeated (WebMonkey said this in May, but I’ve seen it even more recently) is that Safari will be the only browser to not support WebM, when even the Internet Explorer team have promised to. That’s not the case. What the IE team said was that they will support WebM (or rather, the VP8 codec) as long as the user has installed the codec on Windows. Safari’s position is identical, they just haven’t publicly stated so.

The current free alternative to H.264, OGG video, is also not supported in Safari — but you can play OGG videos in Safari by downloading and installing the Xiph Quicktime Components. Likewise, Windows Media files are supported through Flip4Mac. WebM can be supported in Safari in the same way, as soon as someone creates a QuickTime plugin (I believe experimental support is in Perian already). This is exactly the same situation as with IE.

Where this doesn’t apply is on mobile devices; many — principal amongst them, the iOS range — don’t allow extra codecs to be installed. However, this is slightly supplemental to my point, which is that both IE and Safari — on desktop — are capable of playing WebM via a plugin. I believe that if people will install the Flash plugin, they will install the WebM plugin — and when we have choice and competition, a true standard can be reached by consensus, rather than financial clout.

You can now use SVG with the img element, as well as the background image in CSS.

I know you can already use SVG in background-image with Safari, Chrome and Opera, and this, coupled with Internet Explorer’s push towards SVG and the strong chance this will be available in IE9, made me decide to take a closer look.

I’ve put together a little demo page which you can view with Safari, Chrome, Opera or Firefox 4 nightlies:

SVG in background-image demo

The same image is used many times at different sizes on this page, displaying the grand advantage of SVG over PNG: it can be resized without the same loss of quality that bitmap images suffer.

Implementation is very easy:

E { background-image: url('image.svg'); }

You’ll notice also a box labelled ‘SVGZ’ — the background-image on this element is in the compressed SVG format, SVGZ:

E { background-image: url('image.svgz'); }

The file size is less than one-third of the non-compressed version. In order to use this, you may need to configure your server; full instructions for Apache servers can be found here.

The drawback is that it’s not ready for use just yet — browsers that don’t support SVG in background-image will not provide any fallback, even if you supply another background-image value; so in non-supporting browsers, no image at all will be displayed.

Update: I’ve found a technique for using SVG images with PNG fallback.

The image used in this demo is from All Free Vectors.

Update (21/12/2010): Changed information about SVGZ, thanks to the comment from Robert Longson below.

I recently read Peter Morville’s fantastic book, Ambient Findability, which defined really well the motivation to use semantic descriptions for links: they give the target page aboutness.

Simply defined, aboutness is the quality of meaning; what something is about is defined by its aboutness. To extend an example from Morville’s book, let’s regard a web page which contains W.H. Auden’s poem, Funeral Blues:

He was my North, my South, my East and West,
My working week and my Sunday rest,
My noon, my midnight, my talk, my song,
I thought that love would last forever; I was wrong

Although we know that the poem is about death, the word itself doesn’t appear in the poem; so how could a search engine that indexed the page know what it was about, and return it in the results of a search on that topic?

In order to gain some context, the search engine will look at the text of the links to that page*; so a link with the text ‘read more’ will provide no context whatsoever, whereas a link with the text ‘W.H. Auden’s poem about death’ provides aboutness.

And it’s not just for our link text that semantics are important; the same principle applies with HTML — your markup gives aboutness to your content. So if you’re a front-end coder, be sure to at least use appropriate container elements (the HTML5 Doctor can help with this), and if you want to go further take a look at the likes of Microformats and RDFa.

* Search engines look at more than this, of course, but this is the most obvious example.

The four demos shown to date display different (although related) aspects of the API, showing first multiple file uploads, then a drag and drop upload interface, next adding progress information (although this doesn’t work for me), then reading EXIF data from a JPEG image. You can imagine how these combined would be used for native drag and drop uploading to Flickr, for example.

The File API plays a big part in integrating the browser more tightly with the OS, particularly when combined with the drag and drop functionality, and I’m sure it’s only a matter of time until the other browsers implement this. Congratulations to the Firefox team for their work on this, and hacks.mozilla.org for some great demos.

In the first part of this post I gave a potted history of the differing syntaxes, and provided an overview of how that affected linear gradients. In this second part I’m going to look at radial gradients.

Here the syntaxes diverge slightly more, with WebKit requiring more values than Mozilla; while that adds some flexibility, it also increases the complexity.

I’ll be using the same page of examples, which you’ll need to view in Safari / Chrome (or other WebKit derivative) or Firefox 3.6 (beta 3+):

CSS Gradients comparison: Mozilla & WebKit

Radial gradients

As with linear gradients, the key differentiation between the Mozilla syntax and the WebKit syntax is that the latter requires a start and end point, whereas the former is constrained by the bounding box.

You can see in this first example (Radial 1) that the Mozilla syntax is much shorter when making a simple two-colour radial gradient:

-moz-radial-gradient(green, yellow);
-webkit-gradient(radial, center center, 0, center center, 70.5, from(green), to(yellow));

In Mozilla’s case I set only start and end color-stops; for WebKit I must specify a position (50% 50%) and radius (0 — I’ll explain that later) for the start point, and a position (50% 50%) and radius (70.5) for the end point, as well as the color-stops.

As far as I can see the radius value has to be a value in pixels, so in order for the end radius to be the diagonal of the square (where Mozilla defaults to) you need to use the calculation (side)(sqrt(2)) — or, do what I did and use this online calculator.

In the next example (Radial 2) I’ve offset the center of the gradient and set it to end at the furthest edge of the containing box:

-moz-radial-gradient(40% 40%, farthest-side, green, yellow);
-webkit-gradient(radial, 40% 40%, 0, 40% 40%, 60, from(green), to(yellow));

And then used the same center offset but constrained the radius to the distance of the nearest wall (Radial 3):

-moz-radial-gradient(40% 40%, closest-side, green, yellow);
-webkit-gradient(radial, 40% 40%, 0, 40% 40%, 40, from(green), to(yellow));

As you can see, Mozilla takes a series of constants using natural language — farthest-side, closest-side, contain, etc — to set the limits of the gradient, where WebKit accepts only pixel values. The advantage to the former approach is that the syntax is simpler and no calculations are required; the disadvantage is that if you want to create a radial gradient that is smaller than the limits of the containing box, you have to combine it with the background-size property.

Next (Radial 4) I’ve set the center of the gradient to the top-right corner, using three colours equally distributed; here’s where you can start to see the WebKit syntax start to become really unwieldy:

-moz-radial-gradient(right top, green, yellow, blue);
-webkit-gradient(radial, right top, 0, right top, 141, from(green), color-stop(50%, yellow), to(blue));

With WebKit I again have to specify start and end points (with radii), and also specify the stop position of the middle colour. Both outcomes are the same, but the Mozilla syntax is significantly easier.

One aspect of WebKit’s syntax which allows for more flexibility in a gradient is the start point and end point; by providing two separate values you can set the start gradient at a different point to the end gradient, as well as providing different radius values, allowing for effects that Mozilla can’t easily replicate (Radial 5):

-moz-radial-gradient(60% 60%,circle contain,yellow,green 75%,rgba(255,255,255,0));
-webkit-gradient(radial,45% 45%,5,60% 60%,40,from(yellow),color-stop(75%, green),to(rgba(255,255,255,0)));

You can see how that is rendered here (Mozilla on the left, WebKit on the right):

Achieving the same effect is only possible in Mozilla by using multiple values on the background-image property, along with background-size (Update: This isn’t necessary; see Tab Atkins Jr’s comment, below).

Conclusions

While the (original) WebKit syntax does allow for a few effects that the simpler Mozilla implementation can’t easily copy, I think these are really edge cases and the simplicity of the newer syntax is more than ample compensation. It seems the CSS WG agree, which is why the simple syntax is to become an official proposal; I hope the WebKit team accept the proposal and implement it soon.

It was suggested that I also compare these with Internet Explorer’s Gradient filter, but that’s a browser-specific implementation that has no chance of becoming a standard, so I didn’t feel it was suitable for this article; perhaps in a future extension.

Update: Just after I finished this article, Mozilla Hacks published an in-depth look at the new syntax.