dotCSS 2015

For the second year, I went to dotCSS. It took place at the same place as last year, Théâtre des variétés. As usual, we know only who will be speaking, but have no idea what they are going to talk about.

I met a few former colleagues (most of them had switched job in the past year), so it was a nice way to catch up on the news.

You can find wonderful photos of the event on flickr.

Rachel Andrew

The first talk of the day was by Rachel Andrew, who talked about CSS grids. Midway through her talk I realized that I had already seen that talk not long ago, at ParisWeb. This time it was in 18mn instead of 50 which is a much more suitable format.

I see CSS grids as the logical extension of flexbox, where each element is aware that it is part of layout markup, and thus can react to CSS rules knowing much more context, and without being bound to its wrapping markup.

Long will be gone the days of the faux-column layout and display:table when CSS grid will hit mainstream browsers. I personally do not yet have dived into the flexbox world, but seeing what the future has in stock, I might hold a bit longer and go with the CSS grids once they are released.

CSS grids are the future of CSS layout, you should start to play with it right now (by feature flipping it in your browser) so you'll be ready when the day will come.

Andrey Sitnik

Next talk, by Andrey Sitnik, made me understand what postCSS was, for real. Like everybody, I've used autoprefixer, but I never understood it was just one plugin across hundreds that sits in the postCSS environment.

By itself, postCSS does nothing more than parsing a CSS file into a tree representation, and output it back into a string. But the fun part is that you can add any number of plugins between the start and the end of the pipeline. This means that you can write plugins that take a tree representation of a CSS file as input, transform it as much as you want, and let postCSS output the new string representation of your file.

All the plugins follow the simple rule of doing one thing only (but doing it well), and can all be piped together, in pure unix philosophy. As said earlier, one of the most known plugin is autoprefixer, which will add all the required vendor prefixes to your properties, but other can emulate some features found in SCSS for example (like nesting of selectors).

Andrey showed us a bunch of really useful plugins, stressing the fact that postCSS can do what SCSS can also do (using the precss plugin for example), but that its goal was not to add syntactic sugar on top of CSS, but to help improve modularization, reusability and maintainability of CSS components.

In CSS, everything is global. A rule you write in a file could affect an element on another part of the application. Even reset.css files are global. And the cascade makes it really hard to really know where properties are coming from.

With postCSS, you can split your code into modules (like button or header), creating one directory for each of them, where you put all the required html, css, js and images. The use meta-plugin lets you define a local plugin for this module only, which lets you better handle the dependencies of your project.

In the past years, we've started to use BEM as a way to avoid collisions in our selectors and workaround the global nature of CSS. But naming components in BEM can still be complex, and boring. postCSS provides of course @b, @e and @m methods to make writing BEM easier, but it also provides a better top-level abstraction that lets your write your nested class like in the 1996 web, without caring about any conflict, and it will automatically rewrite them to make them unique in a BEM sort of way. The example given was using React for the HTML rendering part, and I'm a bit unsure how this would work without React.

postCSS also provides plugins for handling extended media queries. Part of CSS code that could react not only to the window width, but to a parent element dimensions, or color. This can be useful for example to change the text color of an element to black to white if its container changes its background to something darker.

In the same vein, postCSS has a plugin to apply a local reset to an element, not affecting every other elements on the page. As it has knowledge of every other parent element in the tree, it can know which properties needs to be overwritten to get back to the default values.

I must say postCSS seems really awesome. It seems mature and build by people that really use CSS everyday and know the quirks we are facing. The component approach of plugins and the modularization it provides are really huge benefits for the code maintenance.

But to be honest, this is also one new tool to add to the front-end pipeline and should be used only by people that understand the underlying issues the tool is solving, otherwise it only adds complexity.

If I had to remember only one thing from dotCSS, it's postCSS.

You can find the slides here: http://ai.github.io/postcss-isolation/

Daniel Eden

Then, Daniel Eden, Designer at Dropbox, told us more about how they manage to do CSS on a huge scale. Short answer is: they don't.

Their codebase is 1220 CSS files, for about 150.000 LOC. Which is about 6% of the whole Dropbox codebase. This seems impressive, but it is in the same tendency that another web giant, Etsy, with its 2000 files for 200.000 LOC.

How did that happen? Well, because a lot of people are touching CSS. When a new developer or new team starts a new feature, it handles both the back-end and front-end side. And most of them do not like writing CSS, so they do it quite badly. They are very good js and python developers, still do not understand the cascading principle of CSS, the specificity nor the way to abstract CSS concepts. And still, they have to write CSS, and write a lot of it.

Developers are frustrated by the archaic way we have to test CSS: save file, alt-tab, see if this looks good. As said earlier, everything can be overridden because everything is global. The box model is counter-intuitive and the industry best practice are really young, a few years at most.

And when something doesn't work as expected in CSS, it is easy to write more CSS to fix it. And then writing more CSS to fix the fix that fixes this old fix. In the end, it is too easy to write CSS, that's why the codebase grows that fast.

So Daniel took the issue and started improving the whole CSS codebase, following a mantra I like a lot:

Move slow and fix things

His solution was not perfect, but it was a good starting point. He started to quantify everything. Knowing the number of line of code (using cloc, then running CSSStats —which is using Parker underneath—) to show in a nice and readable way what they were doing wrong. CSSStats outputs the number of font-size defined, the number of unique colors, the most specific selectors, and so on. When faced with such objective values, one can only react and try to make things better. As long as the issue is invisible and "things are working" and "CSS is not really programming", nothing will change.

He put in place a few rules in their process, like the check through a linter for new files, adding himself as a reviewer every time CSS was changed on some critical files, as well as writing a style guide. They also moved from SCSS to postCSS and managed to lose almost 80% of their LOC.

What I really enjoyed in this talk was how humble Daniel was. He told use what worked for them, and the issues they faced. All that was needed was one guy that really cared about CSS code quality to take the lead on it to see things dramatically improve. Start with data, get metrics from your current codebase, explain and teach why it's bad and how to fix it, then provide some tooling to help make it easier and the results will come.

CSS Optimization

After the coffee break, we had the chance to see one (and only one) lightning talk. Only one person applied for it this year, which is a shame because it was really interesting and I would have like to see more of them. I will suggest a talk myself for next year.

The one and only talk was about a project named cssnano, a postCSS plugin for minifying CSS.

This is a set of plugins that will try to optimize the css output so it takes the lower possible amount of bytes. Things like removing whitespace, renaming colors, animations, transform and default values.

In essence, it does the same job as cssmin, but due to its modular approach seems a better alternative on the long run.

Una Kravetz

The next talk was the mind-blowing one. Every dotCSS needs one, and this was the one.

Una Kravetz works at IBM and told us about mostly unknown properties to apply styling on images close to what we are used to do with Photoshop. She started by giving an academic list of all the possible options, then gave us some real life examples.

It is for example possible to change an image contrast to make the grey background appear white and thus being able to put it on a white background page without having to edit the page in Photoshop beforehand.

Then she showed a few interpolation modes to merge two images together and the various way each pixel can interact (either by taking the lightest or darkest value, doing a mix of both, only keeping the hue, etc). At first this looked a bit useless because I could not see any real life usage of the technique, then she started giving more real examples and I was conquered.

When you start mixing this already powerful filters with other CSS properties like masking and cropping, you can make really smart image composition stuff. She recreated most (if not all) the Instagram effects and more using simply CSS.

She showed us how to create those blurry background images in pure CSS, and by applying them to all images in a photo gallery, we can manage to give them an unifying look. This seems really useful on an e-commerce website when you are presenting a lot of different products, with various size, background and colors. But using such a filter, they will all look like they are part of the same set.

I highly encourage you to have a look at CSSGram and her other projects. Her talk was really inspiring and the effects she showed are much more than a simple showcase of the power of CSS, they have real world usage that could greatly improve UI and UX of the website that are going to use it. That being said, only the best unicorn devsigners will be able to harness it correctly because this requires both a set of design and CSS skills to be able to understand all the possibilities.

Alan Stearns

After that, we had Alan Stearns, new co-chairman of the W3C who told us a bit more about how we, web developers, can help move the web forward.

The guy was a huge typo nerd and was unhappy about how fonts were rendered on the web, so he wrote a blog post about it. And was contacted by the W3C to help them fix this at a larger scale.

His whole talk could have been summarized in one of his slides:

Write, Talk, Share and File bugs

We should write blog posts about what is hard, boring or impossible to do in CSS. We should write about the workarounds we found. We should talk in conferences about it and most of all, we should file bugs directly to the browser issue tracking. I know it can be intimidating to file a bug that up in the chain, but this is actually the only way to make the browser improve their rendering engines.

Platform.sh

During the next break, I talked briefly with Ori about his company, platform.sh. Platform is a PaaS that gives you the insurance that your production and staging environment are exactly the same, up to the bytecode running. This gives you all confidence that if its working in staging, this will work the same in prod. This also let you run your tests against your production DB. The way to define your config is a declarative language close to Ansible (but not Ansible).

The idea is interesting, but moving all the prod environment to such a new actor on the scene can be scary.

Tom Giannattasio

After the break, Tom Giannattasio told us more about advanced CSS animations.

The guy came from the Flash world, where doing 3D modeling was a real pain, whereas it is really easy to do in CSS. The default tutorial you see everywhere is how to build a 3D cube in CSS. By tweaking it a bit you can easily create other forms, like a cylinder, and by applying the specific background, you can simulate a barrel (like the ones usually found in video games).

Actually, this is not a real 3D object, this are just various div elements rotating and with a mask applied to simulate some perspective effect. It is actually possible to go quite far in 3D in pure CSS (like this guy who build a FPS).

Still, things are quite limited in what you can achieve with one div only because any timing animation you add with an element has a fixed duration. If you want to animate the same element with one timing function for one property and another for another property, you have to resort to using pseudo-elements or wrapper divs. By adding enough wrappers and playing with transform, blend-mode and opacity, you can build interesting demos.

But what use does it actually have in the web world? Well, seduction. Netflix did a parallax effect on their serie selection view for example. This is a pure gadget, but is so nicely done that the user wants to play with it, and is one of this little touches that does the difference.

As we have already seen in the previous talk with blend-mode, we can do pretty nice and incredible things with CSS today. But should we?

For Tom, most of what the web needs today can be done with simple CSS. More complex usage, like 3D rendering, can be achieved through CSS as well, but the more advanced effect will require WebGL. And this is a whole different world, with a completely different learning curve.

Chris Eppstein

One of the last talks was done by Chris Eppstein, the creator of SCSS. He did not speak about SCSS but gave an few plausible explanations of why CSS is often seen as not really programming.

Before the declarative version of CSS we know, there was a proposal of another styling language, close to lisp in its syntax, but this was considered too complex for the non-programmers. So yes, from its inception, CSS has been created with the fact that their users where not programmers.

At first, variables in the language where considered a bad idea from its creator itself, for the exact same reasons. This was too complex a concept for the non-programmers. But what is programming anyway? Chris had a nice definition of it. Programming is simply the art of splitting a big problem into smaller ones, and then moving data from one place to another, possibly with some reformatting in between.

Following that definition, CSS is programming as we are moving the pixels data from the stylesheet to the screen. The fact that the language is declarative and does not have loops or branching does not change anything.

Maybe this view of the CSS developer not being a real developer come from the old ages, when CSS was much easier? In the first version, CSS had 53 properties, whereas it now boast 316. Maybe it is based on the fact that developers think design is easy and does not require much skill?

In any case, even if any of those two ideas were true, system have evolved but CSS is still part of it. It is tied to the HTML, it is tied to the JavaScript, and website and applications codebase are getting bigger and bigger. Being tied like this, CSS complexity increases just because its related parts complexity are increasing as well.

Chris point was that CSS is not easy. Maybe it was, back in the days, but it is not anymore. And what we can do is limited by the language in which we expose our concepts. In ancient Rome, multiplication was something that was considered an extremely complex scientific achievement, simply because the Roman way of writing numbers was too complex. When people switched to Arabic numbers, multiplication became much more easier. The language we use restricts us in what we can achieve.

This limitation of the language was the driving force that made Chris create SCSS. It added variables, functions and loops. People were reacting quite badly against it at first, because it was breaking how CSS was designed. Along the years, we learned by experience that this new tools where indeed useful and we are glad Chris pushed the boundaries of the language.

You can find the slides here

Daniel Glazman

The last conference of the day was by Daniel Glazman, doing a nice echo to last year where he did the opening one. I must confess that I slept during the major part of his talk so I cannot really tell what it was about. I kind of remember that he was bitching about CSS, and that I had already seen this talk (or one very similar) in another event, but I'll have to wait for the video to refresh my memory.

Conclusion

Awesome evening. A great line up of talks that were really inspiring. Maybe the intensity decreased a bit at the end of the day, or maybe it was just me getting tired. The tool to remember from this session is definitely postCSS (and CSSStats). I've personally really enjoyed the talks about the blend mode and 3D, as well as the more meta talks about the CSS dev environment.

Big up to the dotConferences team, keep up the good work and I'll definitely come again next year.

Tags : #dotCSS

Want to add something ? Feel free to get in touch on Twitter : @pixelastic