This is the same way CSS3 was organised and helped browser vendors to implement new CSS functionality and the CSS Working Group to work in parallel, as “Modules develop at different speeds, depending on their complexity and the working group’s priorities” (Bert Bos, w3.org/Style/2011/CSS-process). Module specifications go through five stages but browsers could implement them at any stage. This is where vendor-prefixes like -webkit- became ubiquitous and tools like Autoprefixer a necessity, so that browsers could get real-world feedback on features prior to the spec or implementation being fully completed. Those five stages aren’t sequential either, through testing fundamental issues can be uncovered which require the spec to be rethought.
With all that in mind, the next wave of modules currently under development contain some neat features and refinements. The highlights include: variables, new selectors, Grid and Snap Points. Some of these already have a decent level of support in evergreen browsers. Variables are supported in 26.01 per cent of browsers (Firefox and Chrome with Opera and Safari on their way), Grid is at 8.77 per cent, and Snap Points have 23.83 per cent global support but 41.14 per cent in the UK. These stats are from caniuse.com and are accurate at the time of writing.
Part of what makes preprocessors so appealing are variables, and they’re finally making their way to CSS. They’re declared like ‘–primary-color: #6C71C4;’ and used as ‘background-color: var(–primary-color)’. The use and aim of CSS variables is to make it easier for us to read large files and help you to write error-free CSS as you can declare it once and then reuse it throughout. The syntax for these variables may be a bit harder to stomach compared to the way that preprocessors declare variables, but this was decided as the most consistent with the current grammar of CSS. In many ways, this is more exciting than variables in preprocessors as they are static, whereas native variables will be dynamic. This means that you’ll be able to ensure that colours are always accessible and that variable values can be set within media queries.
The CSS Grid Layout module aims to make creating layouts simpler. This shouldn’t be confused with CSS Grids, which are a popular way to divide containers into columns of a specific width. Chrome and Firefox currently have the best support for it in their next incarnations, while IE11 and Edge support an older version of the specification. Unfortunately Safari is one of the main browsers left to implement it, which holds web developers back from being able to use it in the next six months. This is unlike flexbox layouts, which can fairly easily fall back to using block or inline-block. Tab Atkins explains it well, flexbox is akin to a one-dimensional layout system. It’s great when you know you want to work in a straight line but for anything more it starts to feel as hacky as using floats; Tab says that Grid is for two-dimensional layouts. It’s for this reason that it’s harder to write fallbacks without simply stacking content. Rachel Andrew has been a key figure in exploring what it’s capable of and advocating its use. She’s created many useful resources including Get Ready for CSS Grid Layout published by A Book Apart for a deeper look into it.
The next CSS feature will hopefully do away with sites hijacking the scroll event, causing jank and iffy experiences across devices. CSS Scroll Snap Points allow you to define where the user should end up when scrolling along the page with a tolerance defined by you and a gentle transition. It currently has support in Firefox and Safari. IE10 and Edge support an older version of the specification; IE10 only works on touchscreens. Snap Points work both horizontally and vertically, making it ideal for scrolling to containers or for carousels/galleries. The best news is that it only needs a handful of new properties to achieve.