At its most extreme, this is used as an argument for disbanding the W3C, and even for core web technologies to become “a single source repository [with] a good owner to drive it.”

Occasionally history throws up curiously timely experiments. Right now we are seeing a very interesting one (and one with far reaching consequences) play out.

Since the middle to late 18th Century, with the enclosure of the commons, and the rise of industrial capitalism, the belief that ownership and property rights is what has largely driven advancements in our civilisation has become almost all pervasive. It lies at the heart of the, until relatively recently alien, concept of intellectual property (increasingly seen as a bane not boon for innovation).

So, what does this have to do with the clear demise of Flash on mobile? Flash has an owner. One that had, and continues to have large revenues, teams of very smart people, deep pockets.

Despite all this, Flash failed to adapt to changing technological circumstances, and withered on the vine.

In parallel, core web technologies have slowly, inexorably grown more sophisticated, organically, iteratively, cooperatively adding capabilities that, for the most part developers clearly want and need.

Let’s take an example I used in a recent presentation. The DOM, while powerful, has long been a pain for developers to really get to grips with. Recognizing this, various libraries, and most famously jQuery, came up with more developer friendly ways of accessing it. jQuery’s use of CSS selector concepts proved immediately popular, and in short order, the W3C began work on the Selectors API, while browsers also within a relatively short time frame began implementing this API.

An ownership model is different. The owner of a platform or technology makes strategic decisions, and long term bets on what will be successful. Those bets may of course pay off tremendously (as in the case of iOS). But they may not, and very often do not, as in the case of Flash.

Standards bodies are not imune to the ownership model of development. XHTML2 is a decade long demonstration of that.

Technologies with the ownership model seem less capable of adapting to change, and are very dependent on initial conditions. The cooperative, collaborative standards based approach (characterised best by the IETF’s founding principle of “rough consensus and working code”) often seems to build technologies that weather the storms of technological, social and political change far better.

It’s ironic, that the apparently “capitalist” “ownership” model is really much more like the central planned economic model of former socialist countries, while the W3 model more closely approximates how the societies of economically liberal countries work.

Neither model is going away soon. Each will have its successes and its failures. But I think it is time to put to bed the far too pervasive meme that standards are in some way an impediment to innovation. After all, take a look at the web. Built on standards (TCP/IP, http, HTML, CSS, EMCMAScript, the DOM), it’s doing ok. Better than OK I’d suggest.

According to most estimates just over 2 billion currently use the internet regularly (in ten years this has grown from around 360 million).

The growth in the web’s use, even in purely numerical terms is almost incomprehensibly dramatic. From .4% of the world’s population in 1995, to 5.9% in 2000, 13.9% in 2005, to today’s 30.4%.

When you add in the global and cultural reach of the web — currently 11% of the population of Africa, 24% of Asia, 31% of the middle east, as well as around 40% of Europe and Oceania, and nearly 80% of North America — then it’s clear we are seeing a global phenomenon the scale and breadth of which is unlike anything see in human history.

Which is in fact no accident.

The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect

Lately, there has been a lot of concern expressed, by intelligent, experienced people I have a lot of respect for, about the future of the web, about its very viability.

I’ve engaged folks like Joe Hewitt in strenuous, but I believe healthy and important debate about these issues.

As I considered in my recent Web Directions presentation, A Dao of Web Design Revisited (article, slides and audio recording coming soon), I feel that many of these concerns strangely, uncannily, echo those which prompted my original Dao of Web Design article back in 2000.

A recent tweet by Aral Balkan (once again, a passionate, intelligent contributor to the web, who has spoken at our events, and hopefully will do again), retweeted by Lea Verou (another generous contributor to the web, and again, one of our past, and I hope future speakers) really captured for me the essence of the issue

#oneversion #manifesto My websites will only support the latest versions of browsers. It’s the browser makers’ duty to get users to upgrade.

Aral Balkan, Twitter, October 20 2011

So, what does this tweet, and predictions of world population have to do with one another?

I love the shiny stuff of the web — the gradients and animations, the transforms. As someone who has developed for the web for nearly 18 years, the ever increasing sophistication of the DOM, of JavaScript, the increase in the speed of JS engines, of rendering, the arrival of mobile platforms, and micro-mobile platforms for the web excite me as a user and a developer. But, they aren’t what gets me up in the morning. They aren’t what fires me up like no other platform before (I built my first Mac apps in 1986, and have had commercially available Mac OS apps continuously since 1994, and Windows apps since 1996).

What really, at the not so tender age of 45, keeps me as passionate and excited about building stuff as I was when about 16 and got my first TRS80 clone is the potential for the web to transform our world for the better. And overarching all this is the question, the challenge, how do we get the next 2 billion online, and ultimately, the next 6 billion people online?

This might not float your boat. And that’s fine. You might consider it an ideological position. And that’s your prerogative. But I know I’m not alone in believing that the potential, the promise, and in the face of overwhelming planet-wide challenges — anthropogenic climate change, global pandemics to name just two which our generation, and particularly my children’s generation will have to increasingly confront — the necessity of bringing our planet together, and enabling all of us to collaborate, share, communicate, without the friction of borders, is something only the web can hope to achieve.

Universality is a founding principle of the web. It is the manifesto the web has been built on, and I believe one of the key drivers of the almost unimaginable success of the web over these last two decades. We ignore that at the web’s peril.

The web alone, not iOS, or Android, or Windows Phone, or any other platform can possibly connect the next 6 billion. Yes, some, many of those 6 billion will be accessing the web via iOS, some via Android devices, some Windows Phone.

But, this next six billion is children in rural India, Africa, China where access to power, and networks, may be intermittent. It’s someone in Sumatra at a decade old Wintel box. It’s people who speak hundreds of different languages, with dozens of different writing systems. It’s people who are the first in their family to be able to read and write. It’s the 20% of people worldwide who can’t read or write. Yet.

So, to say “My websites will only support the latest versions of browsers”, you are in a sense saying, “I’m going to make the fact that developing for the web is harder than it would be if I concern myself with browsers other than the latest is not my problem, and not even the browser makers problem, it’s the problem of the next 6 billion. It’s not my problem, it’s the problem of the child in rural India, Africa, China.”

The truth is, the challenge of universality is daunting. It is hard work. But to me at least, paying this forward is the quid pro quo of the enormous privilege I’ve been granted to work on the web, which has given me fascinating well paid work, connections with thousands of intelligent, passionate, generous people around the world, and the opportunity to participate, in however insignificant a way, in something genuinely extraordinary, something unique. I can pay this forward by including rather than excluding people. By, in my own small way, helping ensure that the next 6 billion will be able to share in the privilege that I, you and the first 2 billion share in.

Which is not to say we shouldn’t continue to develop the capabilities of web technologies. It is not to say we shouldn’t continually explore what these technologies enable us to do.

But to me at least, we owe it to the web to do this in a way that is generous to the web in the way the web has been generous to us.

To reformulate the now famous question Steve Jobs asked of John Sculley:

Do you want to make shiny products for the privileged for the rest of your life, or do you want to come with me and change the world?

Luckily, through photos, tweets, blog and Facebook posts and even the odd video, increasingly an event like Web Directions is captured in more than just our memory.

Web Directions South, held last week, was the sixth annual Web Directions event we’ve run in Sydney, and though likely we feel this every year, it was in our estimation, and indeed of so many we spoke to, and based on many tweets we’ve read the best we’ve done by far.

The atmosphere was incredibly positive, (reflected in everything from the twitter stream, to the crowds who refused to go home, staying long into the night at the closing night party).

A new generation of partner companies, almost all from Australia and New Zealand, and most of which did not exist when Web Directions started back in 2006 companies shouted great parties, competitions, and most importantly showcased the sophistication and breadth (as well as spirit of fun) of the Australian web industry.

Similarly, while many of the speakers, local and international, may have been unknown to our audience, they excelled–educating, inspiring and entertaining. From opening keynote to closing, never have we seen such uniformly positive responses to a program.

Every presentation we had the privilege to see, as well as all those we didn’t but which we heard amazing things about, was world class.

Whether you were there, or missed out, as the podcasts and slides from presentations come online, we’ll tweet about them (so if you don’t already, you really should follow us on Twitter. Meanwhile, you can catch up on hundreds of past presentations from our conferences around the world from the last several years.

And, as a special treat, coming soon is a slickly produced video version of James Bridle’s amazing closing keynote, thanks to Hunting with Pixels.

In the meantime, Ben Buchanan has already made available his traditional big stonking post™ with detailed live notes, links, and photos from a dozen presentations. So, if you missed it, and can bare to see what you missed out on, it’s a great place to start.

Thanks!

• A huge thanks to our wonderful sponsors, partners and exhibitors
• To our incredibly generous speakers
• To Cameron Adams for the opening sequence, setting a new standard for creativity with Web Technologies
• To the Design Computing program at the University of Sydney for their incredible exhibition of interactive technology
• To the W3C Australia Office for once again hosting the W3C South Track
• And not least to the fantastic, positive, open minded, engaged audience.

In the middle 1990s, by an accident of fate and coincidence far too tedious to go into here, I found myself teaching some of the earliest web related courses at TAFENSW. A lot of my focus was in getting students to think conceptually about document structure, linking, interactive tables of contents and so on. Very little was about HTML. Indeed, so convinced was I that WYSIWYG editing was just around the corner, I felt it a waste of their time learning markup (this was pre CSS, but that’s another story). We used Claris HomePage, a surprisingly useful application, to develop web sites as part of these courses.

Pretty much everyone at the time felt that actually working at the markup level for the web would go the way of assembly programming.

There were reasonable precedents to this belief. Desktop publishing in the middle 1980s (really only around 10 years before this time) had revolutionized traditionally markup based print page layout (and more or less given the world the term WYSIWYG).

And, around that same time (the middle and latter half of the 1980s), I was studying Computer Science at University, where for our final year major project, we were the first cohort to no longer use COBOL (I kid you not). Rather we used a 4GL named Omnis (4GLs or Fourth Generation Languages were supposed to abstract away all the messy stuff when developing complex applications). The consensus was (and this was a classic CS program with lots of C, and algorithms and stuff) that the traditional approach to programming was going the way of assembly language.

4GLs live on in systems like 4D, but you would have shocked us all back then if you said that we’d still be using 3GLs without even garbage collection today.

So, why did WYSIWYG revolutionize print design, but not application development?

Similarly, despite the success of, above all DreamWeaver, and to a lesser extent other WYSIWYG web development tools, we’re still very much working at the codeface (I don’t think I know any professional web developers who use a WYSIWYG tool these days, though many, myself included, once did).

But why is that? Will it always be the case? Or will one day someone crack the code (literally and metaphorically) and deliver a WYSIWYG tool that liberates us from the “grind” of coding.

But first, let’s consider why WYSIWYG was so successful in the world of print. I’d suggest a big part of that success was that is possible to map every aspect of a printed page onto the screen (or better, into the internal model of the software). You can even map colors onto a grayscale screen, which many desktop publishing systems were in the mid 1980s, color screens were seriously expensive. So, there was little if any need for metaphor or abstraction. This part of the page right here, will be pantone color whatever. And this little bit over here, will be white. And so on.

The problem space of printed page layout was sufficiently constrained that everything the designer might want to do, they could do with DTP software. I’d argue that a constrained “possibility space” is a key requirement for WYSIWYG systems to really work.

So, what about the web? Douglas Engelbart, one of the giants of modern computing, coined the term “WYSIAYG” (what you see is all you get), which I think captures the challenge faced in developing web development tools, and software tools more generally. With desktop publishing, all you get is all you need. As we saw, the space of possible outcomes can be mapped into a set of tools.

But with the web (even leaving aside JavaScript and the DOM), the possibility space is I’d argue, too open ended to map well onto any WYSIWYG software. So the designer of development tools needs to decide what the all is. Unlike print design, where the problem was constrained by the medium, with the web, software designers constrain the problem space.

So, if you were developing a “WYSIWYG” web development tool, how would you enable your users to make the first paragraph after a heading of level 2, in the introductory section of a document bold? You could allow users to add a class (though you may or may not use that term) to that particular page object (or do you call them elements?). Or, you could provide an interface that is familiar from word processors, where the user selects text, and a bold tool, and behind the scenes the software adds a strong element (to code the user will never see). Or you might add inline style of bold to that paragraph.

And this is about as simple a scenario as it gets. No interaction. Just styled text based on document structure.

Now, what if a document is divided into chapters. And what if the designer wants the first line in the first paragraph in each chapter to be capitalized? Or every other row in a table to have a given background color?

The best possible approach to these particular challenges at the markup and CSS level is likely to use structural selectors (e.g. nth-child). But how to intuit from the users’ actions their intent, and map that intent onto the capabilities of CSS?

And we still haven’t even introduced any interactivity to the challenge yet.

This isn’t simply a theoretical issue for me. I’ve been developing the CSS Editor Style Master for well over a decade. One of the design principles for it has been to never hide the underlying CSS concepts behind metaphors and abstractions. Rather, the goal is to make understanding, and using, these powerful features of CSS easier, more productive, and more enjoyable. This same design principle informs my work on various CSS3 tools, for example my gradient and animation tools. While other tools (and this is not a criticism, simply an observation), create metaphors (for example, provide a Photoshop-like interface for creating gradients), I emphasise a direct correspondence between the objects you manipulate, and the underlying CSS concepts.

But, to return to the question, is WYSIWYG possible for the web? I actually think that it is, but not in general. But in situations where a specific problem is sufficiently constrained, I think we can provide WYSIWYG tools. Which means the approach Adobe is taking with MUSE, will run up against the same challenges that all general purpose WYSIWYG web development tools have. That’s not to say it might not be very useful, but will be so within the constraints of its capabilities, of the problem space its designers have chosen to map.

Where I do think WYSIWYG can be, and already often is very successful is in constrained problem spaces. Blog posting is a particular example. An area I’m focussing on right now is presentations, which I believe is sufficiently constrained to make a WYWIWYG approach meaningful (but even here, I think being able to bust out an editor for markup, CSS or JS is important).
Ironically, you could create a WYSIWYG print design tool with web technologies, for precisely the same reason you can do it with other languages and development platforms.

In essence, the set of problems the web presents developers and designers is open ended in a way that no other system is. Viewport sizes can range from 128 x 128 pixels (or less) to 3840 x 2160, and no doubt beyond. Pixel density, color depth, available fonts, all of these will vary dramatically. Then there’s varying levels of support for CSS, HTML, DOM, SVG. There’s varying network speeds, drastic performance differences. Different input methods (mouse, keyboard, touch, Kinect, …) And none of these are going away. They are getting “worse” (which ironically means better — because more diversity among these characteristics means more people are using the web in more ways, which is good). The fact it causes challenges for designers and developers is essentially irrelevant. That’s our problem.

The search for an over-arching WYSIWYG solution to the challenge of developing for the web reflects our ongoing misconception of what the web is. It’s a medium unlike those which it is in some ways conceptually built on — be that paper, TV or desktop platforms like Windows. It’s understandable that we want it to be more like these. We know them well, we’re comfortable with their concepts and techniques. We’ve invested hugely in technology and expertise to design and develop for them. The web continues to make us uncomfortable. As it should. It is something new, and exciting, and challenging, and unfinished. What we see is never going to be all web get. That’s the challenge, and beauty, of the web.

To contrast with this glacial change, we’re typically pointed toward the wonders of platforms like iOS and Android, where change takes place at breakneck speed. Or we’re pointed toward any number of open source projects, for example SASS, to demonstrate that we can evolve web standards faster outside the W3C (afterall, CSS hasn’t kept place with SASS/LESS… therefor the W3C is clearly useless)

Pretty sure that already happened. SCSS, Coffeescript, etc. The W3C doesn’t have influence anymore AFAIK

And occasionally, this erupts in an orgy of revolutionary fervour, where we need to man the barricades, and

dissolve the W3C, and run the web like an open source project. No more specs, just commits. Does Linux need a standards body?

I guess Joe hasn’t taken a look at the WHATWG’s “HTML“lately. An unversioned. constantly, continuously evolving potage, wherein creeps all kinds of at the every least questionable “innovations”, whose trajectory is unburdened by such trifling challenges as the need for intellectual property policies, or getting anyone to actually implement their stuff.

But let’s step back a pace. Is there really actually such a problem here? And if so, exactly what is that problem? And, are the proposals, to the extent they do exist, likely to help, or make matters worse?

Firstly, it is fair to say, that for the best part of the first decade of this century, we saw considerable stagnation in the development of web standards. The W3C went down the rabbit hole of XHTML2, and CSS 2 almost entirely stagnated (I’l have more to say on that in a second). During that time, innovation came almost entirely from developers discovering techniques which worked with existing browser capabilities, and through JavaScript libraries.

The last three or four years have however seen an explosion of innovation at the browser level. This has included:

• Huge improvements in the performance of JavaScript engines
• Fantastic new CSS features, that have within a couple of years landed in all modern browsers
• Sophisticated new APIs across a broad range of functionality, again now widespread across most if not all modern browsers (Selectors API, Geolocation, offline, localStorage, 2D and 3D canvas to name just a few)

Before we throw the baby out with the bathwater, we should ask, is there a problem at all? Are we really seeing innovation — from standards proposal to widespread browser adoption in the order of 10 years?

Let’s take a look at an actual example. Dave Hyatt announced CSS Gradients in WebKit nightlies April 14th 2008. More or less simultaneously, Apple formally proposed these as part of CSS3. Gradients have been supported in Firefox since 3.6 (released Jan 2010), Opera since 11.1 (final release mid 2011), Internet Explorer 10 (developer releases early 2011). So, from first released and proposed as a standard to very widespread adoption in around 3 years.

We’ve seen similar timeframes for other CSS features, as well as “HTML5” features like the Selectors API, appcache, geolocation, localStorage.

So, to put it bluntly, I think the problem is overstated. We seem to have arrived at an approach that both enables the exploration and implementation of novel features in browsers, which are also widely adopted across browsers. It’s that second part that is most important, and I’ll return to it in a moment.

But I also want to quickly address why I think we seem to have thrown off the stagnation of previous years. I’d argue it comes down to stepping back from the monolithic approach of earlier W3C recommendations (CSS 1 and 2, XHTML2, SVG), toward a much more modular approach, as exemplified by CSS3, but as also seen with geolocation and the selectors API. A corollary to this is, I’d argue, that HTML5 is too monolithic and needs to be fragmented (which in some ways is happening).

But back to the real issue. The web is a different problem. It makes little if any sense to compare innovation of the web ecosystem with that of iOS, Android or other platforms. The web faces challenges far far greater (and has goals far more important). A platform such as iOS can abandon legacy applications, content and hardware, (along with their users) with little compunction. It can (and does) make developers and content creators wishing to participate jump through any number of hoops. It has a single dictatorial decision maker, beholden to no one, and nothing other than itself. And it generates extraordinary revenues, which can be reinvested into the ongoing development of the platform.

The web is different. It values interoperablity, backwards compatibility. It’s goal is to bring access to the same information to billions across the world, on all manner of devices.
Its custodians are, in my opinion, scandalously under-resourced, given just how much wealth the web has created for so many, perhaps above all Google and Apple.

Without the web, Google would not exist, and Apple’s core engine of growth, iOS devices would essentially not either.

So, rather than generally criticising the W3C, or going so far as calling for its dissolution, we should focus on how well in many ways it has done an almost impossible task — getting companies which are fierce commercial rivals to sit down, work together and agree on core technologies they will each, and all, implement, even while at the same time, these same competitors are involved in significant legal conflicts with one another.

Can the W3C be improved? Certainly. But before suggesting solutions, let’s identify, and demonstrate with evidence, genuine problems. Then, when devising solutions, it pays to ask what evidence there is that those solutions will not only solve the problems identified, but also ensure the ongoing cooperation that has given rise to the web.

In this article, we’ll take a look at how to use 2D transforms and the various transform functions (such as scale and rotate). We’ll also, as always, look at some gotchas when first working with transforms, and once again, there’s a tool to help you play with transforms (I developed it some time ago, but I’ve updated it significantly for this article).

What transforms do

As in many cases, an example is worth a thousand words, so let’s take a look at a couple, to illustrate how transforms work, as well as some of their most important aspects.

When you click or tap the button below, this paragraph is rotated by 45 degrees. It’s also scaled to 75% of the size it would otherwise be. However note how the rest of the page layout is not affected. That’s because transformations don’t change the box model of an element, and so leave the page layout unchanged.

Transform It!

This element has been skewed horizontally and vertically. You can still select the text, and otherwise interact with the element, as you would if it weren’t transformed.

Transforming elements

The syntax for CSS transforms is in many ways straightforward. There are just two new properties to contend with — transform, and transform-origin. The first specifies the transforms we want applied (scaling, rotating and so on), while the second, which is optional, specifies the origin for this transformation (for example, do we rotate around the middle of the element, its top left hand corner, and so on).

The transform property

The transform property takes as its value one or more transform functions, which each specify a transformation. Let’s take a look at each of these different functions in detail. Functions all take the form of a function name, with a value inside round brackets (as indeed do all CSS functions). So for example, we translate horizontally with the function translateX(200px).

OK, enough preliminaries, let’s start in with some actual transforming. We’ll start with the translate function.

translate

The translate function moves the contents of an element to the left (negative values) or right (positive values), and/or upwards (negative values) and downwards (positive values).

translate takes one or two comma separated values. The first is the horizontal translation value. If there is a second, this is the vertical translation value, while if there is only one value, then the vertical translation is zero (that is, the element will only be translated horizontally).

In addition to the translate function, there are the related translateX and translateY functions, which only translate an element horizontally, or vertically, respectively. Translate functions take length or percentage values, and like CSS properties, require units for values other than zero.

But enough theory, why not have a play with them?

We mentioned a moment ago that transforms don’t impact the layout of a page. There’s one area where this is not exactly true. If you translate the above element completely to the right, you’ll notice a horizontal scrollbar appears (or the page can now be scrolled to the right). While the page layout has not been changed, the overflow property of the transformed elements containing element is affected by transforms (Safari on Mac OS X Lion is an exception to this, and perhaps indicates where this sort of UX is headed, but for now, in desktop/laptop browsers other than this, the addition of a scrollbar will impact page layout).

Transform It!

scale

The scale function lets us zoom an element up or down in size (all the while maintaining the dimensions of its box for the purposes of the layout of the page). The function name is scale, and it takes a number value-with a value of .5 meaning “scale to half the current size”, and of 2 meaning “scale to twice the current size”, and so on. So, if we want to make an element 75% of its current size, we use the property transform: scale(.75). And that’s really all there is to it. Why not have a play with it?

It’s also possible to scale horizontally and vertically independently from one another, by using two comma separated numerical values for the scale property. The first value scales an element horizontally, and the second, vertically. Let’s take a look.

As with translate there are two related scale functions, scaleX, and scaleY. scaleX scales only horizontally (scaleX(2) is the equivalent of scale(2, 1)), and scaleY, which scales only vertically (scaleY(2) is the equivalent of scale(1, 2)).

rotate

Rotating text and images is a common page design technique, until now difficult to achieve on the web without considerable hackery, if at all. Transforms make rotating an element easy.

The rotate function takes an angle value. If you’ve worked with CSS linear gradients, in particular the newer syntax, then you’ll have seen angle units before. There are several ways you can specify an angle in CSS.

degrees

As you most likely remember from school math, there are 360 degrees in a circle. So, when specifying a rotation of an element, 90 degrees is a quarter turn clockwise, 180 degrees is a half turn, 270 degrees is three quarters turn clockwise, and 360 degrees is a full revolution. Here these are below.

rotate(90deg) rotate(180deg) rotate(270deg) rotate(360deg)

Of course, it is possible to rotate an element by an arbitrary angle, for example 34.6 degrees, like so

rotate(34.6deg)

But, there are other ways we can specify rotations.

turns

perhaps the simplest way to specify a rotation is with the turn value. We can rotate an element a quarter turn clockwise with the function rotate(.25turn), half a turn with .5turn, three quarters of a turn with .75 turn, and a whole turn with the function rotate(1turn). WebKit and Opera support the turn value, while Firefox (version 6) does not.

rotate(.25turn) rotate(.5turn) rotate(.75turn) rotate(1turn)

For completeness, it’s worth noting that there are two other possible angle units-radians (rad), and gradians (grad). Briefly, there are 400 gradians in a full rotation (so one grad is slightly larger than one degree), while there are 2π radians in a full rotation (radians are widely used in mathematics).

Now, if you think about rotating an element, then you might wonder what point of the element the rotation takes place around. For example — is it the center? Or one of the corners?

This element rotates around the top left hand corner when you click or tap and hold it. (transform: rotate(360deg))

We can in fact specify where the rotation (and as we’ll soon see, any transformation) takes place, using the transform-origin property. transform-origin takes two length or percentage values, which specify the horizontal and vertical “origin” of the transformation. In the above example, we have transform-origin: 0 0. If we want to rotate around the center of the element, we use transform-origin: 50% 50%, while to rotate around the bottom right of the element, we use transform-origin: 100% 100%.

This element rotates around the center of the element (transform-origin: 50% 50%; transform: rotate(360deg)).

This element rotates around the bottom right hand corner of the element (transform-origin: 100% 100%; transform: rotate(360deg)).

(You might be able to guess that we can animate transformation changes, like we can most other CSS property changes using CSS Transitions. For more on this, see my article on CSS transitions and animations.)

So, let’s now put rotations and transform origin together so we can play around with them.

transform: rotate(0);
transform-origin: 0 0

transform-origin can also be specified with keywords, in place of percentage (or length) values. As with background-position we can use left, center or right for the horizontal origin position and top, center or bottom for vertical. Where only one value is used, this applies to the horizontal origin, and the vertical is 50% (or center). Where no transform-origin is specified, its default value is 50% 50%.

skew

the last of the 2 dimensional transform functions is skew. Skewing is typically explained in mathematical terms, but if you recall a little school geometry, it isn’t really that complicated. Horizontal skew (the skewX function) takes the box of an element, and while the top and bottom edges remain horizontal, tilts the left and right edges by the specified number of degrees to create a parallelogram. Similarly, a vertical skew (skewY), leaves the left and right edges vertical, and creates a parallelogram with the top and bottom edges rotated by the specified number of degrees. And when you skew both horizontally and vertically, you combine both of these (where it can get really quite tricky to work out what’s going on). Does that help? You can play with the values below to get a sense of how skewing works in practice, including how it can create apparent 3D effects.

The skew function, like most other functions, takes one or two values. As with rotate, they are angle values, and where there are two values, they are comma separated.

Once again, as with a number of the other transform functions we’ve seen, there are two related functions — skewX and skewY, which each skew only in one dimension, and which take only a single, angle value.

Complex transformations

While you’ll likely never need to use it, underneath all these functions is the core of CSS transformations, based on the mathematical concept of a transformation matrix. Each of the functions we’ve seen can be represented by a matrix value. While it’s firmly in the domain of mathematics, we can for example represent the function scale(1.5,1.2) by the matrix

1.5	|	0	|	0
0	|	1.2	|	0
0	|	0	|	1 

and directly apply this matrix value using the matrix function, like so

transform: matrix(1.5, 0, 0, 1.2, 0, 0)

this element has been scaled using a matrix function on the transform property.

The transform matrices for various functions are described in the SVG specification.

Multiple transforms

It’s possible to apply multiple transform functions at once to an element. For example we can rotate, translate and skew an element with the single transform property:

transform: scale(0.75) rotate(45deg) translate(132px, -149px) skew(32deg, -32deg);

Click the button below to apply several transformation functions simultaneously, with the property transform: scale(0.75) rotate(45deg) translate(132px, -149px) skew(32deg, -32deg);

Transform!

There is however a complicating factor, which we look at in a moment.

The Transformer Tool

Hand coding transforms, as with much to do with CSS3, is an increasingly complex process. Not only is there a good deal of syntax to remember often for quite straightforward effects, but the outcome of at least some transforms isn’t necessarily obvious to most of us simply by looking at the CSS. So, to help you learn, and explore, CSS transforms, I’ve developed a 2D transform tool (there’s a 3D one as well, but we’ll cover 3D in a later article).

If you’re keen to explore transformations in more detail, and how they can be made to work together, head over and take a look, and as always, let me know what you think via twitter.

Gotchas, tips and tricks

Its fair to say that while now widely supported in modern browsers, 2D CSS transforms are still experimental, and quite quirky. Here are some of the difficulties you might encounter, and some tips and ideas for working with 2D transforms.

vendor specific prefixes

Reflecting the experimental nature of transforms, all browsers require vendor specific prefixes for the transform and transform-origin properties (note that function names are not prefixed). As all modern browsers including IE9 and up support 2D CSS transforms, using these transformation properties can get more than a little unwieldy. For example, the CSS for a simple rotation around the center of an element, if we include all vendor specific properties, would be something like:

img{
	-webkit-transform: rotate(90deg);
	-moz-transform: rotate(90deg);
	-o-transform: rotate(90deg);
	-ms-transform: rotate(90deg);
	transform: rotate(90deg); //always include a standard for last 

	-webkit-transform-origin: 50% 50%;
	-moz-transform-origin: 50% 50%;
	-o-transform-origin: 50% 50%;
	-ms-transform-origin: 50% 50%;
	transform-origin: 50% 50%;
}

You might find the use of a CSS preprocessor like LESS or SASS worth exploring, as they can make stylesheets far more manageable when you use a lot of vendor prefixing.

Transforming inline elements in webkit

According to the current version of the specification, CSS Transforms should be applied to inline, as well as block elements, but while Opera and Firefox both correctly apply transforms to inline elements, WebKit browsers (Safari 5.1, Chrome 15) currently don’t.

A workaround for this is to give inline elements which are to be transformed display: inline-block, which won’t affect how they are laid out in the page, but will enable these browsers to transform them.

Translating rotated content

One subtle aspect of multiple transformations is that functions are performed in sequence — from first to last in the list. The order that you specify functions can make a difference. Take a look at the following paragraphs. Both have the same scale, rotate and translate functions applied. But, in the first, the element is translated to the right, while in the second, it is translated to the left. What’s going on?

Clicking the button below applies several transformation functions simultaneously, with the property transform: scale(0.75) rotate(180deg) translate(-100px,0)

Transform!

Clicking the button below applies several transformation functions simultaneously, with the property transform: scale(0.75) translate(-100px, 0) rotate(180deg)

Transform!

Transformations don’t take place in an absolute coordinate space. Rather, “up”, “down”, “left” and “right” are relative to the current rotation (but not skew) of the element. So, if an element is rotated half a turn, and so is “upside down” then translate(0, –100px) moves it down the page 100px. If it’s rotated a quarter turn to the right, it’s moved to the left. Similarly, translating “horizontally” is always relative to the element. So, if it’s rotated by 180 degrees, then translate(100px, 0) moves the element to the left. In short, the X and Y axes of a transformation are relative not to the page, but the element’s current rotation.

Interacting with transformed content

While the box of an element isn’t changed by a transformation, elements that are transformed display various quirks when it comes to mouse events in various browsers, most likely due to the still experimental nature of transformations. Take the element below. It rotates a quarter turn clockwise when the mouse is over it, and then back to its original rotation when the mouse is out of it.

Now, if the box of the element isn’t changed, then when rotated, hovering over any of the image which is outside that original box should not trigger a mouseover event, and so the element should rotate back to its original position. However, as makes intuitive sense, hovering over those parts of the rotated element that are outside the original box does cause mouseover events to be fired. But in addition, mouseover events are also fired when you hover over that part of the element’s original box which no longer has content because it has been rotated away. And if you move your mouse around the element, you’ll find in all browsers various locations where the rotation abruptly, though unintuitively, changes. Similar behavior can be observed for translation and other transformations.

In light of this, I’d suggest being extremely wary of transforming elements which users will interact with given the current state of browser support for transformations.

Overflowing and transformations

We mentioned earlier that while transformations don’t effect the box model of an element, and so leave the layout of a page untouched, they do effect the overflow, and if we have overflow: auto, they can in fact impact the page flow.

In the element below, we have an image inside a div. The div has an overflow:auto. When we hover over the element (apologies to touch device users), the contained image scales up in size.

Now, in most browsers on most platforms (Safari on Mac OS X 10.7 is an exception) the browser adds a horizontal scrollbar to the div when you hover over the image, which adds to the height of the element, reflowing the page below it. Just something to be aware of.

CSS Positioning and Transforms

While I was writing this article, CSS legend Eric Meyer posted a detailed critique of one interesting aspect of transforms.

It has to do with the positioning of elements. When we absolutely or fixed position an element, and give it say a top and left, these positions are offset from their containing box — which is not necessarily their parent element. Rather, the containing box is the first ancestor which itself has either relative, absolute or fixed position. However, adding a transform to an element also makes it a containing block for its descendent elements! As Eric observes, this can particularly cause difficulties with fixed positioning. Rather than rehash Eric’s detailed thoughts, I’ll let you head over and read them first hand.

General Rendering Problems

On different browsers you’ll find various rendering problems with transformed content. For example, with Opera, rotated text appears to be rendered in a lighter font than the same text when it isn’t rotated. I’ve also seen redrawing problems when rotating text in WebKit browsers. In Safari on iOS 4, rotated text doesn’t necessarily align smoothly along its baseline. None of these are necessarily deal breakers, but it’s worth keeping in mind. Transforms are still experimental, so don’t necessarily expect them to be perfectly supported in all circumstances just yet.

Hardware Acceleration

There’s a widely held belief that at least some browsers hardware accelerate the rendering of CSS transformations (hardware acceleration involves the CPU handing off execution of certain types of calculation to the GPU, which can increase rendering performance significantly, particularly on mobile devices).

At present the current state of hardware acceleration for CSS transforms across all browsers and devices is difficult to pin down. A webkit engineer I tracked down confirmed that current versions of Safari (5.1 on the desktop, iOS 4), but not necessarily other WebKit browsers:

• animated 2D transforms in Safari are always hardware accelerated
• using 3D for static 2D transforms may improve performance, but may also increase memory use — a real issue for memory limited mobile devices in particular

Now, haven’t we just spent however much effort covering 2D transforms? How could this possibly help? Well, as we’ll see in an upcoming article on 3D transforms, we can use 3D transforms to do 2D transforms (for example, there’s rotate3D). If squeezing maximum performance for iOS devices is a need, then it may be that using a 3D version of a transform will help.

It’s also worth noting that issues around what aspects of CSS transforms are hardware accelerated and how that acceleration works are implementation details in specific browsers, and not specified as part of CSS Transforms. As such, across browsers there’s likely to be little uniformity of approach to hardware acceleration, and even from one version of a browser to the next, approaches may change.

Backwards Compatibility

One of the strongest aspects of CSS3 features like gradients, border-radius, shadows and the like is that they have been typically designed so as to be easily used in a way that is backwards compatible almost automatically, or provided we keep a small number of potential challenges in mind. For example, with gradients we need to ensure we have a fallback background color or image for when gradients aren’t supported. For text-shadow, we need to ensure that the contrast between the text and the element background is sufficient when the shadow is not drawn.

Of all new CSS3 properties, transform is the one where backwards compatibility is the most difficult to ensure. Ironically, it’s precisely because transforms don’t affect the page layout that they cause such difficulty. For example, in order to accommodate say a heading rotated 90 degree to run horizontally along the left hand side of the text which follows it, we need to create whitespace to ensure the heading does not overlap the text. We might do that with margin, or padding. We’re also likely to want to remove the whitespace where the heading has been rotated away from, by, for example, using negative margin on the paragraph following the heading. But, what happens if transforms aren’t supported? The heading text will be overlapped by the paragraph below it.

In order to use transforms for more sophisticated page layout along these lines, a solution like Modernizr, which enables different CSS to be applied based on the support, or absence of support for various CSS3 features like transforms is indispensable.

Transformations are typically most easily used in a way that is backwards compatible where animated transforms create a transition between states in an application. We’re all most likely used to sliding or flipping transitions between states in iOS and other mobile apps. CSS transforms can be used for these transitions, in conjunction with CSS Transitions, and where transforms aren’t supported (in which case it’s unlikely transitions will be as well), your users simply see an abrupt change in state.

However you plan to use transforms, as with every other aspect of web development, keep in mind those browsers which don’t support them, and ensure your user’s experience isn’t diminished to the point where information or functionality is denied them because their browser doesn’t support it.

Browser Support

As we mentioned, despite the still rather experimental nature of support for CSS 2D Transforms, they are now widely supported in modern browsers including:

• Internet Explorer 9 and up
• Firefox 3.5 up
• Safari 3.2 up
• Chrome 10 and up
• Opera 10.6 and up
• iOS 3.2 and up
• Opera Mobile 11 and higher
• Android 2.1 and up

So, support is widespread, and constantly improving. While there are definitely challenges associated with using 2D Transforms, they’re a powerful, and worthwhile addition to the repertoire of developers, and will only gain in value. What are you going to do with them?

More Reading

• The 2D Transforms Specification
• MSDN on Transforms — great to see the IE love for them!
• Opera’s developer center on, you guessed it, Transforms
• On Transformations in Internet Explorer (before and after IE9)

The format was simple — each of the speakers had 5 minutes to tell the audience something they know — think of it as super-concentrated (and fun) lessons in all sorts of cool stuff.

The crowds had a blast, and even better, we captured everything that happened on screen that night, along with audio.

Presentations covered all manner of design, development and other web related topics. So, in 5 minutes you can learn more than you might have thought possible on

• Bezier curves
• Accessing the gyroscope and accelerometer in mobile browsers (watch a live web based take battle built specially for the night!)
• WCAG ARIA
• Mobile HTML emails (our Sydney winner!)
• CSS3 Media Queries (our Melbourne winner, and great fun)
• Parallax effects in CSS

and much much more, including the world premier of Dmitry Baranovskiy’s Newton.js game dev engine (featuring an Angry Birds clone he built with it)

So, head over to the video page, and check out 100+ minutes of fantastic fun interesting presentations, 5 minutes at a time.

And stay tuned, as What Do You Know might be headed to your city early 2012 (well, if you are in Australia)

And, if you like the concept, then go ahead and borrow it — maybe in house at work, or with your meet up group, or your own community What do you know event. Drop us a line, and we’ll gladly give you some thoughts about how to go about it, and help get the word out if you like!

It must be said though, that nothing has quite riled me like the proposed “scoped” attribute for style elements. To learn about it, I recommend HTML5 doctor Jack Osborne’s much more readable version, with some thoughts (and lively commentary).

So, what do I think of it? Well, I guess from the title of the post you already know. I think this is genuinely the worst suggested feature of HTML or CSS I’ve ever seen, and I would like it to see it be swiftly taken out the back and euthanised. Yep — strong language, but just so no one is possibly mistaken about this.

Why am I so emphatically opposed to it? Where to begin? There are several different lines of objection I have.

First, if we consider the separation of presentation from markup to be in anyway important, and at present it is considered a central best practice in web development, then this approach, which strikes at the heart of that practice, should be anathema. It’s long been considered that inline CSS is a last resort hack when it is difficult, or impossible to apply style using a stylesheet in the head of a document (linked or embedded). Now we’re embedding style sheets into the body of a document?

But, let’s go even more deeply than that. The development of HTML5 is supposedly governed by core design principles. This suggested approach violates several of these. Let’s take a look.

Principle 2.2. Degrade Gracefully

So, what happens if we use this feature in current browsers? Well, firstly none of these support the feature whatsoever.

But here’s an example I tried in a number of current browsers

<section>
    <style scoped>
      p { color: red; }
    </style>
    <h2>How does it work?</h2>
    <p>Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas.</p>
  </section>

  <p>other stuff</p>

And here’s what happened.

Safari 5.1, Opera 11, Chrome, Firefox 6, and IE7 up all recognise the style element, and then style both p elements red — so scoping is not honoured — let’s call this not graceful degradation.

Principle 2.3. Do not Reinvent the Wheel

We currently can scope style in an HTML document. We use these new fangled things call CSS selectors. Even without touching the HTML above we could style the paragraphs in the given section like so

section:first-of-type>p{
  color: red
}

Or we could add class or id as appropriate to our section. I’d need to see a pretty compelling use case here, that demonstrates a need that can’t otherwise be solved using existing CSS/HTML practices and technologies, before beginning to even think there’s a problem to be solved, let alone that this might be a good solution to that problem.

Principle 3.1. Solve Real Problems

In over 15 years of web development, I’ve not seen a problem this is a solution to. If you are going to violate widely held long standing best practice, you need to do a bit better than invent a rare problem, then solve it in a way that opens the floodgates to terrible practice.

Truthfully, and I have paid a fair bit of attention for close to 15 years in the CSS space, I have never ever once heard anyone articulate this need. Sure, it’s probably happened, but it’s far from a pressing concern.

Principle 3.2. Priority of Constituencies

In case of conflict, consider users over authors over implementors over specifiers over theoretical purity

So, users get broken pages in older browsers with style scope. Authors who want to use it would need to hack around the fact that this not only doesn’t work in older browsers, it causes rendering challenges. Seems we are focussing at the level of theoretical “purity”, or maybe, the whims of specifiers here.

Is this what versionless HTML development is about? Design principles violated left right and center, and an unwanted, unneeded and harmful addition to HTML, seemingly at the whim of one of the authors of HTML5?

And the first place we hear about it is in a draft of the future HTML specification. I wonder what other hidden gems await discovery in that document?

You know, it’s not like there aren’t some pressing real world problems to there for HTML to address.

If you feel remotely strongly as I do, you can submit a comment on the draft HTML specification at the WHATWG here.

Well, recently there’s been a little bit of whimsy in the otherwise dry, but very useful CSS3 Text module, with the “bikeshedding” property. But sadly, no more. bikeshedding is now more prosaically named “white-space-collapsing”, and I for one think this is wrong. So wrong, that I’m campaigning for the reinstatement of the bike shedding name.

If like me, you want to bring a little bit of whimsy back to web standards, then join the campaign by commenting below, and bring back bikeshedding!

Newer iterations of the DOM provided developers with access to far more than just that original limited range of elements, as well as the ability to insert, modify and delete elements in an HTML document. But, cross-browser implementations very often differed, and full support for the W3C’s DOM standards have arguably been treated as far more optional than CSS or HTML support.

One of the many reasons for the success of JavaScript libraries like jQuery and Prototype, on top of their easing the pain of cross-browser development was how they made working with the DOM far less painful than it had previously been, and indeed how it was with the standard DOM. Being able to use arbitrary CSS selector notation to get matching elements from a document made the standard DOM methods seem antiquated, or at the every least, far too much like hard work.

Luckily, the standards and browser developers took notice. The W3C developed the Selectors API, a way of easily accessing elements in the DOM using standard CSS selector concepts, and browser developers have baked these into all modern browsers, way back to IE8.

In this short (by my standards) article, we’ll look at the Selectors API, how you use it, browser support, and some little things you might like to keep in mind while using it. Rest assured, it’s now widely supported, so in many cases, you can safely use it, potentially with a fallback for older browsers (IE7 and older specifically) via libraries like jQuery (or more lightweight selector engines like Sizzle, which provides this functionality for jQuery, and other libraries).

The Selectors API

The Selectors API, which many would consider to be part of HTML5, is in fact a separate, small specification from the W3C. It provides only two new methods, querySelector, and querySelectorAll, for the Document, Element, and DocumentFragment objects (typically, you’ll use these methods on the document or element objects.) But do these methods make life easier for developers?

Before the Selectors API, to access an object in the DOM we could use these methods:

• getElementById (from DOM Level 2 Core) — available for the document element
• getElementsByClassName, standardized in HTML5, after long non standard browser support, which is supported on documents and elements
• getElementsByTagName, from DOM Level 2 Core, available on the document and element objects

And there are some legacy ways of accessing elements on a page, which date from the earliest days of JavaScript:

• links is a property of the document object which contains all anchor (a) and area elements with an href attribute
• anchors is a property of the document object which contains all a elements
• forms is a property of the document object which contains all form elements

We can also “traverse” the DOM, using:

• childNodes, a property of the document and node objects
• nextSibling, a property of a node, which contains the element directly following it in the same parent element
• parentElement, a property of a node, which contains its parent element.

and related DOM traversal properties and methods.

But, what developers really often want to be able to do (as the success of jQuery and other libraries has shown) is simply say “give me all the elements which match this selector”, or “give me the first element which matches this selector”. And that’s precisely what the simple, powerful Selectors API does. It doesn’t completely do away with the need for DOM traversal, and legacy methods and properties, but it goes a long, long way.

querySelector

querySelector is a method of the document or any element, which returns the first descendent element which would be selected by its one argument, a CSS selector string. We can use this in place of the document.getElementById('content') like so: document.querySelector('#content') (like me, you’ll probably find yourself forgetting to add the # from time to time in querySelector, something which doesn’t throw an error, so can be frustrating to track down).

And we can do things like find the first header element in an HTML5 document, with querySelector('header'). So far so good. But where querySelector really shines is we can use any selector (attribute, structural, dynamic, UI, and even selector groups) with it. In most cases, this makes traversing the DOM, and locating a specific element far simpler, and most likely far quicker, as we won’t be looping in JavaScript and accessing all kinds of DOM properties, rather, the query is taking place inside the browser’s far faster native DOM engine.

querySelectorAll

Often, when working with the DOM, we want to manipulate several elements at once, For example, we might want to unobtrusively attach an event listener to all the links with a given class value. Here, querySelectorAll is your friend. Just like querySelector, it takes a single string as an argument, which is a CSS selector. Instead of returning a single element, it returns a NodeList (a kind of JavaScript array) of matching elements. We can then iterate through this array, and manipulate these objects.

For example, we could use it to replace document.links like so:

document.querySelectorAll('area[href], a[href]')

This finds all area elements with the href attribute set, as well as all a elements with this attribute set as well (notice how we’ve used a selector group, which is quite acceptable with the Selectors API).

Matching elements are returned in the order they appear in the DOM parse tree.

Document or Element?

I mentioned that both the document, and element objects implement these two methods — what’s the difference? Well, as you might have guessed, these methods find elements that are descendants of the object you query on. So, if you use the method on a paragraph element, it will only find the descendant elements of that paragraph which match the selector. Other elements in the document which might match it won’t be returned. But, if you use the methods on the document, then any matching element in the document can be found.

Gotchas

If you’ve really got your hands dirty with the DOM, you’ll know that when DOM methods return a NodeList, it is live—that is, the members of the list change, depending on the state of the document.

Let’s say we get all the elements with a class of “nav” using document.getElementsByClassName('nav'), and it returns 5 elements, which we keep in a variable.

Now, if we add a new element with class nav, or remove one of the existing elements with a class of nav, the NodeList in our variable will be updated to reflect these changes (that’s why it is called a live NodeList).

But querySelector and querySelectorAll are different. While they return a NodeList, it is static. So, if we similarly get all elements with a class of nav using document.querySelectorAll('.nav'), then regardless of what we subsequently do to the DOM, the length and contents of the NodeList won’t change. Which means, it’s always best to query the DOM just before you need the elements, rather than holding on to elements if your DOM is going to change.

There’s also a performance consideration. Tests of various browsers indicate that querySelectorAll is slower than getElementByTagName (though not it would appear in Opera). But, it’s also possible that once available, manipulating the static NodeList may be higher performance than manipulating a dynamic NodeList. And this issue will likely only have an impact in extreme cases. I’d certainly not recommend prematurely optimising by using getElementsByTagName, getElementsByClass, getElementById and so on in place of querySelectorAll, but it is worth noting you might be able to squeeze a little more performance out by doing so if you really need to.

And it is worth noting too that querySelector and querySelectorAll don’t work with every kind of selector. While pseudo-class selectors (like :visited) work with these methods, pseudo-element selectors, like :first-letter, :first-line, :before and :after although permissible as arguments, will return null in the case of querySelector, and an array of length zero for querySelectorAll.

A little gotcha this aging developer has found I’m so used to getElementById and getElementsByClassName that I find myself forgetting the # or . required in the selector string in querySeletor and querySelectorAll. As I mentioned a moment ago, it can be frustrating, as this won’t throw an error, but simply return null or an empty NodeList.

Support

All modern browsers, including IE8 and up support both querySelector and querySelectorAll. It is however worth noting that the results returned are dependent on what selectors the browser supports. IE8 supports CSS2.1 selectors, though not CSS3 selectors. IE9 supports many CSS3 selectors, but not a number of the UI related pseudo-classes, such as :required and :invalid. IE CSS support for versions 5 through 9 is extensively covered here by Microsoft.

So, keep in mind, even where these methods are supported, what they return is only as good as the CSS selector support in that browser.

The Wrap-up

If you’re more of a web designer who’s always been a little intimidated by the thought of wading through the DOM in search of elements (trust me, even seasoned developers often wince at the thought), then querySelector and querySelectorAll are a boon for you. Or, if you’re a developer who finds yourself going straight for jQuery or another library as soon as the DOM is involved, the Selectors API might just save you a few KBs, additional files and fussing around. And, if you’re one of those seasoned DOM experts, I’m sure there’s plenty of times you’ll breathe a sigh of relief that rather than wading through an entire document with childNodes, nextElementSibling and the like, a single call to querySelectorAll will return all the elements you want. I reckon these two are my favourite, and now most used DOM methods, and I’m only surprised they aren’t more widely covered, as they really are like a Swiss Army Knife for the DOM. Perhaps we need a “top 2 Selectors API methods” article. Then again…

Reading

Here’s a few articles and other resources which delve into the Selectors API.

• The Selectors API specification from the W3C
• Selectors API at Opera Developers Center, by Lachlan Hunt, one of the authors of the spec.
• Selectors API at Mozilla Hacks
• Thoughts on performance from JS performance guru Nicholas Zakas (the comments are well worth reading)