I’ve spent more than three years trekking around the globe talking about CSS Grid Layout. Invariably while I’m on stage, someone will tweet something like, “well it sounds great – but it’s only implemented in Internet Explorer”. Where they get this information from is the Can I Use website, which correctly lists IE as the only browser offering support.
As regular readers of my grid ramblings will be aware, the IE and Edge implementation is outdated. It is based upon the initial version of the specification. However, pretty much all of the examples I show on stage and those listed on my site Grid By Example work in Firefox (Nightlies, Developer Edition or by enabling a flag in regular Firefox), Chrome (behind a flag), Opera (behind a flag), WebKit Nightlies and Safari Developer Preview.
It has been possible to test and experiment with big chunks of the Grid Layout specification for over two years. Grid is massively important in terms of front end web development. Along with Flexbox, it gives us for the very first time a layout method for the web which has been designed for the realities of the sort of stuff we need to build. Yet, until very recently I have felt like the lone voice in the wilderness talking about this stuff.
Browser flags v. Vendor Prefixes
Commenters failing to understand browser flags https://t.co/5LHqIpSxkv pic.twitter.com/zz10T0ld69
— Rachel Andrew (@rachelandrew) May 7, 2016
Vendor Prefixes were created as a way to get early stage implementations out to authors, to let us play with new features in a sandboxed way. The problem was that instead of using them for experimental stuff we started using them in production and getting all upset when the spec changed, leaving sites broken. Their success in terms of getting things into our hands ultimately heralded their demise.
In the last couple of weeks WebKit have announced they they will no longer be prefixing, and instead moving to exposing experimental features behind browser flags. Vendor Prefixes are dead but with them mass author involvement in early stage specifications. The history of Grid shows that it is incredibly difficult to get people to do enough work to give helpful feedback with something they can’t use – even a little bit – in production.
I firmly believe Grid is better for being developed behind a flag. You only need to compare the history of Flexbox with that of Grid to see how changes to the flexbox specification have confused and infuriated developers, where Grid has been through major changes without causing anyone (other than those implementing it in browsers) any headaches. That process is still happening now.
However I want more author inclusion in spec development. We are the people who use these specifications. They need to work for the things we build and will want to build in the future. Therefore I’m pleased to see efforts being made to find a middle ground. Chrome 51 will enable a framework for limited testing of experimental features via the Origin Trials Framework. You can read more about the thinking behind this in Alex Russell’s post Doing Science on the Web. This is a new endeavour, but one which at least recognises there is a problem and seeks to find a solution.
Browser implementations in the open
There has never been a better time to see what is coming soon in browsers. Browser vendors have opened up their processes with public roadmaps and developer editions – giving you a safe way to play with new things without causing instability in your primary browser.
Browser vendors are working together on features and interoperability, and this stuff is happening in software we can get our hands on and play with. You don’t need to have special access to download one of these browsers, see how things you care about are changing and log bugs if you find something bad happening.
Google have announced that new web platform features will be discussed through the Web Incubation Community Group. You can join, see what is listed on GitHub, and join the discussion.
Specification participation
Yesterday the CSS Working Group voted to move specification issues and technical discussion to GitHub. No longer will finding out what has already been raised and discussed mean searching through a mailing list archive. You’ll be able to track and contribute to discussion using the tools you already use day to day. It should be far easier to keep track of the specifications that interest you without being hit with the firehose of www-style.
The specifications are coming to the place that we are, using a format we already work with. This is a huge step forward.
Over to us.
Moving the web forward is hard, it involves lots of people and companies, and there are different ideas from these players in terms of how things should move forward. However if we don’t participate when ways to participate are offered, we can’t really complain about what happens.
Our browsers are more open than they ever have been. We are being offered ways to explore and play with experimental features. Our specifications are coming out to the places we already are. Take advantage of this. Your future self will thank you.