Post CSS era
CC Attribution - NonCommercial - ShareAlike 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this
Thirouin, Maxime
While the JavaScript community advocates inlines styles, monolithic CSS pre-processors become old fashioned. Fortunately for CSS aficionados, there is now a scalable and modular tool to facilitate our daily developments. PostCSS allows us to easily parse and transform CSS base on JavaScript plugins. This tool and its ecosystem will help you to avoid to write some legacy code, to lint you code or to write and enjoy today tomorrow’s CSS syntax, today, using cssnext.
 Hi, everyone. I'm going to talk to you about CSS. So the name of the presentation, but there is a lot of stuff in it. I'm going to present myself real quick. So I'm a MOOC on the internet. If you don't have not yet, I'm not English. I'm French. That's why I have this accent. I'm a front-end developer. I'm a freelance consultant. So that's how I live. I start most of the time to create, implement, to their architecture, the skeleton, to start with a good base. My face on the internet, but if you know me, nobody know me here? Maybe not? So that's some projects I did in the past. We talk here about CSS sometimes. But there is, like I said, a lot of other stuff. There is a French website, the first one, where I share some experiences. It's like a blog, but there are many writers on it. You're starting to write some English content. And there is another project, which is Static Dynamic. It's like a static website generator, but to make dynamic websites with a React component. Just take a look if you're curious. I share all of the other stuff on GitHub. So if you're here, maybe it's because you think CSS is awesome, but at the same time, you already get this feeling when you were playing with CSS. This famous gift is nice. So I'm going to talk here about some CSS issues before introducing some solution. So we're going to talk about writing CSS in 2005 to 2010. So most people, you know, felt like this when you have to write CSS back in time. So why CSS wasn't fun? We get no variable, nothing, no constants. You got no real function. There is URL that can be a function, but not really liking programming language. About the reusability, it was pretty weird. We might have import statement, but with the current state of HTTP, which is one, even if the HTTP is coming, it won't solve all the issues we can have with lots of queries for websites. So that's not a real solution for reusability. About inheritance and composition, we have just, you know, nothing right now at this moment. So we have CSS preprocessor. The first time you start to play with it, you're like, yeah, that's awesome. I can inline import statement. That's cool, kind of. You're viable, yeah. So you can do math and you can do some color manipulation. Not really standard, but you have this. You have SAS that came in 2006, less was like 2008 or 2009. Country member and still is 2010. So we still have some, you know, issues with CSS preprocessor. You know the sentence. It's, you know, great tool. You have a lot of shit that can come in. So I will talk about this real quick. Mixons. The premise of abstraction, it's when you have some CSS, CSS is a really simple language, but it can be, you know, hard to debug. And if you have, you know, like this class and you want to know what happened, you have an abstraction with a mixing block and you're trying to redefine a rule. You're trying to define or not redefine, but you're redefining something. So you got a problem here. You also have extant statement, which is, you know, kind of cool, but at the moment you have, like, you're looking at the source code, you're generating, you're generating, like, this kind of content. So that's kind of weird to have, you know, like a lot of problems. As you can see with sometimes some link. So when I will share the presentation, you will be able to read this. And I encourage you to read the link. I've put at the bottom. So that's what I call some cascading shit, because when you have extant, you are extanting rules that are redefining earlier, but, you know, you're maybe extending this at the bottom of your still sheet. And you might have a problem because of the order when you're defining some, you know, rules. You may have some issue with nesting that you have in a prepositor, because if we assume that the first selector is generated by a prepositor or made by hand, and there is a new being, the team that want to, you know, just add a new rule. So we create a class sidebar link. And you want to, you know, define something. And maybe he can try a lot of time, you know, because he can't, you know, make a powerful specificity that is higher than the previous selector, so he will use important. That's not cool. That's called specificity sheet. So now, lots of people will tell you that's kind of a pep car issues, because we are doing this. It's not the tool. It's what we do with it. Frameworks. I add frameworks. I don't know you, but personally I add them. And with CSS is the worst thing ever, because, you know, every selector is a global selector. So it's like global variable. And it's like, yeah, now when we do some JavaScript, we avoid global stuff. So with CSS, you have just that. Scoping. Yeah, that's the fun part. So we have web components and shadow DOM that are supposed to help us or the CSS scoping. I will, you know, try to show you, so that's the shadow DOM support. Pretty bad. And scoped CSS. Pretty bad. So we can't, you know, we can't use this yet. It's not ready. And dependency management in CSS, nothing. Just nothing. So CSS itself or preprocessor are not solving most of our daily problem. And we can say that CSS sucks. It sucks so bad that, you know, most people wear t-shirts with CSS sucks. I didn't have this one, but I already saw people with it. It's an actual t-shirt I saw on a web shop. So here I used this at the beginning of the presentation. But for me, as a front-end web developer, I don't really like to write CSS. I like to style stuff. Because styling is fun, you know. I like to draw things. So I like to create a user interface, but I don't really like CSS. There is a lot of talk right now about why CSS sucks. There is a link at the bottom about a talk about CSS in JavaScript. I encourage you to read this, but I will talk later about that. So here is just a recap about the CSS issue I mentioned. So everything is global. That sucks. Order of specificity is difficult to handle. We have too many unpredictable things. Because you don't really know how is it done and how your selector is going to affect. The DOM, we have just nothing for scoping or isolating components. And we don't have dependency management. So we are going to talk about the origin of most CSS issues. If we look at this snippet, most problems come from here. Yeah, because property and values are not really the issue. So we have a problem here. It's for joke later. So like I said, a user interface is just a bunch of components. We have buttons. We have inputs. We have a menu, et cetera. But why don't we code our user interface this way? If we take this code again, we can use BEM to make simple selector. Here is an example. So there is a good post about a lot of BEM variation you can find. So what is BEM? BEM is just block element modifier. It's like a convention. There is tool to use it. But it can be boring to use them. So since it's a simple convention, you can use it without any tool to set up. It's not set up or anything. Here is an example. You can define a block. You can use a modifier. You can have children for this block. So elements. And you can also have modifier for the element of your block. So block is just a component for your user interface. This example is pretty cool. It's pretty simple. You get a button. You can have a variation of this button, like the large button. You can have a icon in it. And you can have a small icon depending on where you use your button. So here is usage in HTML. So you use your button. You might use some modifier. You add them. You can have an icon and some text. Simple. So with BEM, you kind of, you know, it's a sort of workaround about the issue I mentioned here. Because you will see later an example. But with BEM, you can just prefix your custom selector, your selector, with, you know, like a prefix for your company or anything. Like, you know, Twitter bootstrap might use something like TWT in order to prevent some, you know, issues with the global thing. You have namespace. For the specificity, you don't have specificity issue because you just have, you know, one class. Every time you use one class. Nothing else. Just one class. One class. The selector is just one class. You know, it makes it easier to debug and everything is simple this way. So you have less unpredictable things because your selector is simple. And deleting some code is, you know, pretty easy because when you don't have some generated rules that depend on the document object modeling. So it's better. It's not the solution. But yeah, it's better. So when you, you know, understand this and practice BEM like a lot, you will take a look at your previous code. And you are probably going to punch yourself in the face. Why I didn't do that, you know, like before. That's so simple. I punched my face multiple times. My two cents. It's that when you use BEM, you define just one block per DOM element. Don't try to mix, you know, like different classes. Just classes with modifier. Don't try to compose, you know, like sort of composition with BEM. You will have more issues and you will benefit from, you won't benefit from anything. Just this rule is stupid, but it worked. So now you can tell me, you can ask me with BEM what is missing. I will stop about BEM for now and assess issues and I will show you some of the stuff. Because you know, there is a working group and that is working, I hope. And they made stuff, you know, CSS is kind of the same thing like for 10 years. But we have new things that are, you know, you are going to be able to use them in one year, two years maybe, you will see. Some properties, who knows this kind of syntax? Nobody? Okay, that's cool. So it's sort of variable. I say sort of because, you know, it's you define with double dash because single dash is used for vendor prefix. So it makes this choice. I guess it was a hard run. So you define like in the root component, root is just HTML when you are in a web page. And you can use it with a var function. Now you can recycle the calc function. Because you can do some math, some math, rather than custom properties. So you have, you know, dynamic values. That's cool. Something better, custom media queries. You can define, using add custom media, you define a keyword with double dash, yeah. And you might notice the super design. You can mix, you can use range, a value with our haze and another value. That's new but that will work in browser because it's a specification now. And you can use it with a keyword in parenthesis. So that's pretty simple. That's avoid, you know, having to define, sass, mixing, just for this. You have a lot of color function because there is now like four or five new functions for color. There is the color function, which is named color. You can, with this color, use some modifier on the color, like tint, saturation, alpha, lightness, blackness, darkness. I think it's better than, you know, lighten or darken, which is kind of weird, but you also have the gray function just to define a gray. The second parameter is an alpha value. So that's it for the color. There is a lot of new stuff I will show you in a moment. But you also have new selector that are coming, custom selector, you will see them later. You have new color functions that I don't show you. And there is nesting, native nesting in browser. And even extend that is coming. There is back for this, yeah. So prepositor. This is mostly syntax sugar. So it's just sugar, you know. And like one year, I think, no, in 2013, there is a project called myth, which called himself as a CSS polyfill, but it's not really polyfill because it's not executed during the right time in the browser. So it's not really polyfill, but we can call it that. Like that. The myth was using rework. Who knows rework? Nobody. Someone knows post-tss maybe? Yeah, one? Okay. So someone, the creator of stills created rework, which is just an engine. So it works this way. You take some CSS. You parse it as a nice T. No, IST is like just an object. Okay. Abstract syntax tree. So you have a tree of node in JavaScript. And you can, you know, work on your IST, make some changes, add some values, some rules, et cetera. And you can just stringify it to CSS again. That's how was created auto-prefixer. Who knows auto-prefixer? Nobody? Yeah, a few. So you know, when you use this tool, you can just forget vendor prefix like WebKit, Moz, et cetera. It's very cool to use. And I know I didn't even write prefix for two or three years now. There is a bat. The evolution of rework was not really great. We can show this on, see this on GitHub. You can notice this person here. This was, it was a creator of auto-prefixer, but he wasn't really happy because rework wasn't really open to, you know, a lot of change. So he was not happy. And he said, I'm going to do it my way. So he kind of forked rework. He forked the ID, but he didn't fork the project. And that's how we got Post-TSS. So Post-TSS is like the same thing. You still work on the same way. And you have a nice API to, you know, iterate some things. I will show you this later. Post-TSS is not a preprocessor. Doesn't handle further syntax or it's not an optimizer. It's not a linter. But Post-TSS can do all of this with just plugins. So it's like magic. So how can I use it? So you use, you take Post-TSS, you take some plugins. You plug them, you process some CSS. And you get a result, so new CSS. Here is an example of a plugin. You have a function. You just define a function. There is a better way to define a Post-TSS plugin. But it does this. So you can work on a declaration, for example. You can work on any nodes. You have a lot of method to iterate on the AST. And this plugin just replace around units by pixels unit. It's pretty simple to write. So Post-TSS has a great ecosystem because there is like, I don't know, 200 plugins already. But at the same time, it's like, there is too many. There is some weird plugin in LightGrants. There is a lot of stuff. I worked on those to handle further syntax that we already see as a spec. So I make a tool that I call CSS Next, which is now it's a Post-TSS plugin. Before it was a real tool with an API extra. But since Post-TSS is more famous than this one, I just restricted the core to be a Post-TSS plugin. Because a lot of people are using Post-TSS directly these days. So since it's next, I can handle other things I show you earlier with sometimes some restriction. But you will get warning. We'll take a look to the website. So here is an example of custom selector. For example, you can define your own heading selector and use it later. And now you can even nest media queries. So you can nest custom media queries in your own selector. We can take a look because there is a lot of stuff. So we have custom properties limited to root here. Maybe I can make this bigger. OK. We have calc that might be reduced. When you define font size, you want to make some math. And this will be transformed to simple stuff for old brother. You have the support of custom media queries. The custom media ranger I mentioned before. I think you can even write this just in one single run thing. But I don't remember really. There is too many stuff. Custom selector here. For example, you can define a button with the button tag on the class. And you can define selector for hover on focus as well. And now you can use your custom selector here. And you can make this. You have nesting. There is some variation. You can make direct nesting with the sign you use in SAS. You can make more complicated nesting with at nest statement. And you can like nest media here. You have color function, new function. U, whiteness, and blackness to define color. The gray function. You can even now define R, G, B, A color for real. But it's kind of free to define the alpha with just an example. But you can do it. You have some fallbacks. You can use font variant property, which is very easier to write to use than the font feature setting, which is kind of weird. And there is fallback. You can also use this. Well, there is a lot. There is a lot. Too many. But you can use this today. And when browser will implement this, SSNex will stop to do the transformation. That's a good part, I think. It's like auto-profixer. You use vendor prefix. You don't care about vendor prefix, really. Just want a feature. So you write it, auto-profixer under the prefix. And SSNex does the same for more syntax sugar. By the way, SSNex have auto-profixer in it. So you can use this plugin. At the same time, there is people that are working on the post-sys to bring a SAS-like syntax. And they were on the channel. I remember, like, how can we call this plugin? Sassy post-sys, et cetera. At this moment, some people were saying that post-sys is not really a post-processor. There was a debate on post-processor, pre-processor. So I use this ID, pre-SS. Everybody loves it. And they decide to use it. Well, you can do that. I don't use it, but you can do it. At the same time, you also have a linter, stylings. Who lints your JavaScript or your code? Yeah, that's good. You can do the same now with a stylings. It's a modern CSS linter, but post-sys, you got already, I think, 100 rules. This project is just a few months old, but there is too many rules. You see? That's good. That's good. So meanwhile, that's how CSS Proversor are evolving. The problem is it sucks, because you can't even inline a CSS file using SAS. If you want a result or normalize that you just wrote CSS, you can do that right now in SAS. It sucks. You can inline. You need to rename the file, the extension. It's pretty bad. And every SAS user probably know Chris Epstein. It's a SAS maintainer. And he used it like post-sys last week. He wrote his first plugin, because he wanted to do something that he can do with us. Here is my prediction for a CSS Proversor. We'll see. So I'm going now to talk about something else, which is asset management. So there is GrandumGulp. Who is something like GrandumGulp? OK. So task-curing is broccoli. Like there is too many. And each time we have to add something to our process, we're like, OK, let's make another task for that. Like there is another app, a task. OK. So here's an example of some grand file and some definition. There is like too many. That's a real example of I found. I just used a huge grand file and found that on GitHub. So it's like plugging like this in Grunt. Well, that's kind of weird. My advice is use Grunt, because it avoid you to write too many times through the file system. And it's really faster than Grunt. But well, I recommend Grunt, but I don't even use Grunt, myself. Meanwhile, in JavaScript, it's interesting now to see that JavaScript is evolving as well. Somebody know maybe EA6? No. So it's a new specification that you can use in most browser. But some piece you can use, some piece you cannot. It has been renamed like this. It's kind of weird. But you will have a new version each year now. So there was a tool called 6.5, which has been renamed to Babel. Babel.js, who define itself as a JavaScript compiler. And it's like Post CSS. It transforms all to something new. You have like a future syntax support. You can transform React.js. Somebody know React maybe here? OK. And it's plugable, so you can use your plugin. For a moment, Babel was like a single package. But recently, they explode their ecosystem to like a ton of package. Like there is a lot too. You can see here some transform ES 2015. There is a lot for this. And there is a lot for other stuff. So now we are going to make a recap. We have compilers like Babel and Post CSS. You take something, you change it, and you get some new things. You can use this for CSS, JavaScript. And then you even have now MDST, which is the name of the project, which can help you to get an ST for some markdown. And now you can output with new markdown or HTML as well. So how should we use this? Should we grant a Gulp? I'm going to show this. You all got this moment where is my asset. And you are not going to get this error directly in your face with Grunt or Gulp because you don't have error management. So I have a trick. My advice is use web packs. There is many tools. Recently I even saw a post yesterday about somebody who was complaining about the fact that there is too many tools that just do nothing out of the box. Like web pack, Post CSS, doesn't do anything if you use any plugin with it. But it's like Grunt or Gulp. If you don't use plugin, there is nothing. So you need to handle the configuration. Web pack is like this. You require some JavaScript. And you can require anything like a CSS, an SVG. You have JavaScript here and below it some CSS. The really interesting thing is that if your pass is not correct, if your asset is not at the place you think it is, you will have error management like, aye, the compiler with blowing your face an error. Like this asset don't exist. So you don't have a Mr. Use error that you can track really. You can get error directly during the compiling step. So web pack is you create a bundle. You take some JavaScript in the first place. And you use loader, which are just like plugins. You have a compiler. Same thing. So here is web pack. JavaScript, your thing. You get a bundle. You will find a lot of boilerplates because that helps you to set up the tool. When you don't know the tool, you don't want to read the doc. Because if there is like five new tools, too many doc to read. So you can go on the internet and find you will see like a million of boilerplates. That might fright you, but there is a good boilerplate you can find on using GitHub training repo. Use GitHub training repo. And you will find the most third repo on GitHub. So you will have something accurate and that might help you. So this work for application, you know, like single page application or websites. It's the same thing. I used WordPress like the last month to make a WordPress plugin to avoid under error. So here is snippet again. I'm not sure you have noticed this line, which is kind of weird, to require some CSS to get some content. So here is a trick. It's called CSS Modules. And it helps. Here is a BEM selector with a prefix for the company, for example. And CSS model is just killing this part. So you can just use a really simple selector. Now you require your CSS. You get a simple object with a generated class name. This avoids conflicts. And you can use it. Here is a line of React.jsx. But you can use it in a raw JavaScript. So with this, we can say that we call just simple objects with style, you know, declaration and values. So yeah, that's what we want in the first place. We want to style your original interface. So why not inline style? This might seem crazy, like a lot. But using inline style sort of fix all the issues we mentioned before. I can show you an example. React Native Web. So it's kind of weird because there is React for the web. There is React Native to write a native application for iOS or Android. And now we get React Native for the web. I want to highlight the author of this package, which is the author of normalize.sys, who use normalize.sys? OK. Everybody. So this person was not a web developer in the first place. But when he got into this, he got a lot of crazy idea. But all this idea, well, we're just here or to before we start to use it. I'm not sure my sentence was correct, but maybe you understand me. Here's an example of some React code. We don't really care about this because it's kind of real. We can just notice this part, this style. And you use it for the CSS model. So later on your code, you can define a stillsheet, which is like simple CSS like this. That's kind of cool. So that might not be relevant for all projects. But in life style, it can be easy to write a React Native application as well. You can use the syntax here to write a website style, web application, or even React Native application. That's a cool part. Facebook implemented a project they called the CSS layout, which is a re-implementation of Chrome Engine for CSS, but in a for React Native. So you can use some rules like margin, height, width, flex, flexbox, color, font ways, et cetera. So you can style your native application with this. That's, I think, interesting. So now I said and mentioned a lot of things. You're probably like, wow, I'm not sure. So today, if you have to write something or take a legacy project and use new stuff I mentioned, you can start with adding post-css. Maybe if you have just auto-profixer, you have a gulp task for your SAS stillsheet. You can add auto-profixer, and you're already using post-css. It's simple, and you will remove a ton of code by doing this. I have a friend which were using, like, how it was called, it was a mixing to handle a RAM to pixel for Albreuser. Internet Explorer 8. And there were, in his team, they were using this plugin, like, in, I don't know, everywhere. They were need a RAM unit. They were using this mixing to handle the pixel transformation. So when he started to use post-css with a plugin that replaced, that add pixels, values, as well as a RAM unit, like, removed, I don't know, 1,000 line of code by adding just, you know, like, tree line. That was something pretty cool. So you can add easily post-css with some plugin, and you can use BEM or CSS model, depending on your stack, and the time you have to, you know, set up the things. So with this, you will have custom syntax, new syntax, food proof syntax, eventually, with auto-profixer on CSS Next. You can still handle media queries, because with inline style, it's not easy to define state and media queries. It's kind of a problem, but there is some way to handle things, but it's not really easy. So if you have some server-side rendering, I will advise you to use CSS model on this stack right now. And if you are in a really dynamic context, like an application, you can use inline style that will make your code, you know, compatible with Racknative. And you will have a lot of flexibility, because you can generate in JavaScript some rules and value, et cetera. So the stack with post-sys can kind of solve some issues, but this can be used today and gradually. So you can just add auto-profixers and add post-sys with some plugins. Then at the same time, you can start to use BAM. Now you can do this. It's just a convention. And later, you can decide to remove some code and use CSS model, which is safer than BAM. Besides that, your inline style can that can solve all major CSS issues, but the pre-rendering is not really good. But you can use this kind of today, because you can switch or you can mix, because there is some package that allow you to use CSS to transform CSS to JavaScript for Racknative, so there's a package for that. And you can also transform JavaScript style to some CSS. So you can go back. You can change the way you use this. There is even more package on GitHub or NPM to handle this kind of weird transformation, but that might be relevant in some place. So my advice is just adjust your choice depending on your need and your current stack, because we can just say, hey, boss, I'm going to ditch everything and set up a new stack that's just awesome, because hand users don't care about that. When you make your whole application, hand users just want the user interface. So you can bring and add something for you to deliver some feature, some bug fix more quickly. So you can add this for you, because it's for you. It's not for the end user. He don't care about that. Do you got any questions? You can go. There is not a lot of people, so I am sure all of you can ask one or two questions. Did you understand me for 80%? That's the first time I'm doing a presentation in English, so that's my question. I did a lightning talk in five minutes, but it was weird. You have any question? Yeah? So I just wanted to make a round of the things. So please let's make a goal to do the CSS. So I'm doing a great Nesquad. So we've CSS, so we're doing the CSS file and running that through a built-in set. You can, are you asking me if you can use CSS with less? No, I'm not really. How do you write CSS? OK, just CSS. So you use CSS files, and most syntax highlighter in your text editor, we handle basic things like nested media queries. It doesn't add anything special to the language grammar. So you can use just CSS files. And then you can use the one after a built-in set. Excuse me? You still write through a built-in set? Yeah, yeah, yeah. We already have both steps. That's not going to stop. No, no, I just want to. Another one, please. Don't be shy. No? Thank you.
 Hi, everyone.  I'm going to talk to you about CSS.  So the name of the presentation, but there is a lot of stuff in it.  I'm going to present myself real quick.  So I'm a MOOC on the internet.  If you don't have not yet, I'm not English.  I'm French.  That's why I have this accent.  I'm a front-end developer.  I'm a freelance consultant.  So that's how I live.  I start most of the time to create, implement, to their architecture, the skeleton, to start  with a good base.  My face on the internet, but if you know me, nobody know me here?  Maybe not?  So that's some projects I did in the past.  We talk here about CSS sometimes.  But there is, like I said, a lot of other stuff.  There is a French website, the first one, where I share some experiences.  It's like a blog, but there are many writers on it.  You're starting to write some English content.  And there is another project, which is Static Dynamic.  It's like a static website generator, but to make dynamic websites with a React component.  Just take a look if you're curious.  I share all of the other stuff on GitHub.  So if you're here, maybe it's because you think CSS is awesome, but at the same time,  you already get this feeling when you were playing with CSS.  This famous gift is nice.  So I'm going to talk here about some CSS issues before introducing some solution.  So we're going to talk about writing CSS in 2005 to 2010.  So most people, you know, felt like this when you have to write CSS back in time.  So why CSS wasn't fun?  We get no variable, nothing, no constants.  You got no real function.  There is URL that can be a function, but not really liking programming language.  About the reusability, it was pretty weird.  We might have import statement, but with the current state of HTTP, which is one, even  if the HTTP is coming, it won't solve all the issues we can have with lots of queries  for websites.  So that's not a real solution for reusability.  About inheritance and composition, we have just, you know, nothing right now at this  moment.  So we have CSS preprocessor.  The first time you start to play with it, you're like, yeah, that's awesome.  I can inline import statement.  That's cool, kind of.  You're viable, yeah.  So you can do math and you can do some color manipulation.  Not really standard, but you have this.  You have SAS that came in 2006, less was like 2008 or 2009.  Country member and still is 2010.  So we still have some, you know, issues with CSS preprocessor.  You know the sentence.  It's, you know, great tool.  You have a lot of shit that can come in.  So I will talk about this real quick.  Mixons.  The premise of abstraction, it's when you have some CSS, CSS is a really simple language,  but it can be, you know, hard to debug.  And if you have, you know, like this class and you want to know what happened, you have  an abstraction with a mixing block and you're trying to redefine a rule.  You're trying to define or not redefine, but you're redefining something.  So you got a problem here.  You also have extant statement, which is, you know, kind of cool, but at the moment you  have, like, you're looking at the source code, you're generating, you're generating, like,  this kind of content.  So that's kind of weird to have, you know, like a lot of problems.  As you can see with sometimes some link.  So when I will share the presentation, you will be able to read this.  And I encourage you to read the link.  I've put at the bottom.  So that's what I call some cascading shit, because when you have extant, you are extanting  rules that are redefining earlier, but, you know, you're maybe extending this at the bottom  of your still sheet.  And you might have a problem because of the order when you're defining some, you know,  rules.  You may have some issue with nesting that you have in a prepositor, because if we assume  that the first selector is generated by a prepositor or made by hand, and there is a  new being, the team that want to, you know, just add a new rule.  So we create a class sidebar link.  And you want to, you know, define something.  And maybe he can try a lot of time, you know, because he can't, you know, make a powerful  specificity that is higher than the previous selector, so he will use important.  That's not cool.  That's called specificity sheet.  So now, lots of people will tell you that's kind of a pep car issues, because we are doing  this.  It's not the tool.  It's what we do with it.  Frameworks.  I add frameworks.  I don't know you, but personally I add them.  And with CSS is the worst thing ever, because, you know, every selector is a global selector.  So it's like global variable.  And it's like, yeah, now when we do some JavaScript, we avoid global stuff.  So with CSS, you have just that.  Scoping.  Yeah, that's the fun part.  So we have web components and shadow DOM that are supposed to help us or the CSS scoping.  I will, you know, try to show you, so that's the shadow DOM support.  Pretty bad.  And scoped CSS.  Pretty bad.  So we can't, you know, we can't use this yet.  It's not ready.  And dependency management in CSS, nothing.  Just nothing.  So CSS itself or preprocessor are not solving most of our daily problem.  And we can say that CSS sucks.  It sucks so bad that, you know, most people wear t-shirts with CSS sucks.  I didn't have this one, but I already saw people with it.  It's an actual t-shirt I saw on a web shop.  So here I used this at the beginning of the presentation.  But for me, as a front-end web developer, I don't really like to write CSS.  I like to style stuff.  Because styling is fun, you know.  I like to draw things.  So I like to create a user interface, but I don't really like CSS.  There is a lot of talk right now about why CSS sucks.  There is a link at the bottom about a talk about CSS in JavaScript.  I encourage you to read this, but I will talk later about that.  So here is just a recap about the CSS issue I mentioned.  So everything is global.  That sucks.  Order of specificity is difficult to handle.  We have too many unpredictable things.  Because you don't really know how is it done and how your selector is going to affect.  The DOM, we have just nothing for scoping or isolating components.  And we don't have dependency management.  So we are going to talk about the origin of most CSS issues.  If we look at this snippet, most problems come from here.  Yeah, because property and values are not really the issue.  So we have a problem here.  It's for joke later.  So like I said, a user interface is just a bunch of components.  We have buttons.  We have inputs.  We have a menu, et cetera.  But why don't we code our user interface this way?  If we take this code again, we can use BEM to make simple selector.  Here is an example.  So there is a good post about a lot of BEM variation you can find.  So what is BEM?  BEM is just block element modifier.  It's like a convention.  There is tool to use it.  But it can be boring to use them.  So since it's a simple convention, you can use it without any tool to set up.  It's not set up or anything.  Here is an example.  You can define a block.  You can use a modifier.  You can have children for this block.  So elements.  And you can also have modifier for the element of your block.  So block is just a component for your user interface.  This example is pretty cool.  It's pretty simple.  You get a button.  You can have a variation of this button, like the large button.  You can have a icon in it.  And you can have a small icon depending on where you use your button.  So here is usage in HTML.  So you use your button.  You might use some modifier.  You add them.  You can have an icon and some text.  Simple.  So with BEM, you kind of, you know, it's a sort of workaround about the issue I mentioned  here.  Because you will see later an example.  But with BEM, you can just prefix your custom selector, your selector, with, you know, like  a prefix for your company or anything.  Like, you know, Twitter bootstrap might use something like TWT in order to prevent some,  you know, issues with the global thing.  You have namespace.  For the specificity, you don't have specificity issue because you just have, you know, one  class.  Every time you use one class.  Nothing else.  Just one class.  One class.  The selector is just one class.  You know, it makes it easier to debug and everything is simple this way.  So you have less unpredictable things because your selector is simple.  And deleting some code is, you know, pretty easy because when you don't have some generated  rules that depend on the document object modeling.  So it's better.  It's not the solution.  But yeah, it's better.  So when you, you know, understand this and practice BEM like a lot, you will take a look  at your previous code.  And you are probably going to punch yourself in the face.  Why I didn't do that, you know, like before.  That's so simple.  I punched my face multiple times.  My two cents.  It's that when you use BEM, you define just one block per DOM element.  Don't try to mix, you know, like different classes.  Just classes with modifier.  Don't try to compose, you know, like sort of composition with BEM.  You will have more issues and you will benefit from, you won't benefit from anything.  Just this rule is stupid, but it worked.  So now you can tell me, you can ask me with BEM what is missing.  I will stop about BEM for now and assess issues and I will show you some of the stuff.  Because you know, there is a working group and that is working, I hope.  And they made stuff, you know, CSS is kind of the same thing like for 10 years.  But we have new things that are, you know, you are going to be able to use them in one  year, two years maybe, you will see.  Some properties, who knows this kind of syntax?  Nobody?  Okay, that's cool.  So it's sort of variable.  I say sort of because, you know, it's you define with double dash because single dash  is used for vendor prefix.  So it makes this choice.  I guess it was a hard run.  So you define like in the root component, root is just HTML when you are in a web page.  And you can use it with a var function.  Now you can recycle the calc function.  Because you can do some math, some math, rather than custom properties.  So you have, you know, dynamic values.  That's cool.  Something better, custom media queries.  You can define, using add custom media, you define a keyword with double dash, yeah.  And you might notice the super design.  You can mix, you can use range, a value with our haze and another value.  That's new but that will work in browser because it's a specification now.  And you can use it with a keyword in parenthesis.  So that's pretty simple.  That's avoid, you know, having to define, sass, mixing, just for this.  You have a lot of color function because there is now like four or five new functions for  color.  There is the color function, which is named color.  You can, with this color, use some modifier on the color, like tint, saturation, alpha,  lightness, blackness, darkness.  I think it's better than, you know, lighten or darken, which is kind of weird, but you  also have the gray function just to define a gray.  The second parameter is an alpha value.  So that's it for the color.  There is a lot of new stuff I will show you in a moment.  But you also have new selector that are coming, custom selector, you will see them later.  You have new color functions that I don't show you.  And there is nesting, native nesting in browser.  And even extend that is coming.  There is back for this, yeah.  So prepositor.  This is mostly syntax sugar.  So it's just sugar, you know.  And like one year, I think, no, in 2013, there is a project called myth, which called himself  as a CSS polyfill, but it's not really polyfill because it's not executed during the right  time in the browser.  So it's not really polyfill, but we can call it that.  Like that.  The myth was using rework.  Who knows rework?  Nobody.  Someone knows post-tss maybe?  Yeah, one?  Okay.  So someone, the creator of stills created rework, which is just an engine.  So it works this way.  You take some CSS.  You parse it as a nice T.  No, IST is like just an object.  Okay.  Abstract syntax tree.  So you have a tree of node in JavaScript.  And you can, you know, work on your IST, make some changes, add some values, some rules,  et cetera.  And you can just stringify it to CSS again.  That's how was created auto-prefixer.  Who knows auto-prefixer?  Nobody?  Yeah, a few.  So you know, when you use this tool, you can just forget vendor prefix like WebKit, Moz,  et cetera.  It's very cool to use.  And I know I didn't even write prefix for two or three years now.  There is a bat.  The evolution of rework was not really great.  We can show this on, see this on GitHub.  You can notice this person here.  This was, it was a creator of auto-prefixer, but he wasn't really happy because rework  wasn't really open to, you know, a lot of change.  So he was not happy.  And he said, I'm going to do it my way.  So he kind of forked rework.  He forked the ID, but he didn't fork the project.  And that's how we got Post-TSS.  So Post-TSS is like the same thing.  You still work on the same way.  And you have a nice API to, you know, iterate some things.  I will show you this later.  Post-TSS is not a preprocessor.  Doesn't handle further syntax or it's not an optimizer.  It's not a linter.  But Post-TSS can do all of this with just plugins.  So it's like magic.  So how can I use it?  So you use, you take Post-TSS, you take some plugins.  You plug them, you process some CSS.  And you get a result, so new CSS.  Here is an example of a plugin.  You have a function.  You just define a function.  There is a better way to define a Post-TSS plugin.  But it does this.  So you can work on a declaration, for example.  You can work on any nodes.  You have a lot of method to iterate on the AST.  And this plugin just replace around units by pixels unit.  It's pretty simple to write.  So Post-TSS has a great ecosystem because there is like,  I don't know, 200 plugins already.  But at the same time, it's like, there is too many.  There is some weird plugin in LightGrants.  There is a lot of stuff.  I worked on those to handle further syntax  that we already see as a spec.  So I make a tool that I call CSS Next, which is now  it's a Post-TSS plugin.  Before it was a real tool with an API extra.  But since Post-TSS is more famous than this one,  I just restricted the core to be a Post-TSS plugin.  Because a lot of people are using Post-TSS directly  these days.  So since it's next, I can handle other things I show you  earlier with sometimes some restriction.  But you will get warning.  We'll take a look to the website.  So here is an example of custom selector.  For example, you can define your own heading selector  and use it later.  And now you can even nest media queries.  So you can nest custom media queries in your own selector.  We can take a look because there is a lot of stuff.  So we have custom properties limited to root here.  Maybe I can make this bigger.  OK.  We have calc that might be reduced.  When you define font size, you want to make some math.  And this will be transformed to simple stuff for old brother.  You have the support of custom media queries.  The custom media ranger I mentioned before.  I think you can even write this just in one single run thing.  But I don't remember really.  There is too many stuff.  Custom selector here.  For example, you can define a button with the button tag  on the class.  And you can define selector for hover on focus as well.  And now you can use your custom selector here.  And you can make this.  You have nesting.  There is some variation.  You can make direct nesting with the sign you use in SAS.  You can make more complicated nesting with at nest statement.  And you can like nest media here.  You have color function, new function.  U, whiteness, and blackness to define color.  The gray function.  You can even now define R, G, B, A color for real.  But it's kind of free to define the alpha with just an example.  But you can do it.  You have some fallbacks.  You can use font variant property,  which is very easier to write to use than the font feature  setting, which is kind of weird.  And there is fallback.  You can also use this.  Well, there is a lot.  There is a lot.  Too many.  But you can use this today.  And when browser will implement this,  SSNex will stop to do the transformation.  That's a good part, I think.  It's like auto-profixer.  You use vendor prefix.  You don't care about vendor prefix, really.  Just want a feature.  So you write it, auto-profixer under the prefix.  And SSNex does the same for more syntax sugar.  By the way, SSNex have auto-profixer in it.  So you can use this plugin.  At the same time, there is people  that are working on the post-sys to bring a SAS-like syntax.  And they were on the channel.  I remember, like, how can we call this plugin?  Sassy post-sys, et cetera.  At this moment, some people were saying that post-sys is not  really a post-processor.  There was a debate on post-processor, pre-processor.  So I use this ID, pre-SS.  Everybody loves it.  And they decide to use it.  Well, you can do that.  I don't use it, but you can do it.  At the same time, you also have a linter, stylings.  Who lints your JavaScript or your code?  Yeah, that's good.  You can do the same now with a stylings.  It's a modern CSS linter, but post-sys, you got already,  I think, 100 rules.  This project is just a few months old,  but there is too many rules.  You see?  That's good.  That's good.  So meanwhile, that's how CSS Proversor are evolving.  The problem is it sucks, because you can't even  inline a CSS file using SAS.  If you want a result or normalize that you just  wrote CSS, you can do that right now in SAS.  It sucks.  You can inline.  You need to rename the file, the extension.  It's pretty bad.  And every SAS user probably know Chris Epstein.  It's a SAS maintainer.  And he used it like post-sys last week.  He wrote his first plugin, because he  wanted to do something that he can do with us.  Here is my prediction for a CSS Proversor.  We'll see.  So I'm going now to talk about something else, which  is asset management.  So there is GrandumGulp.  Who is something like GrandumGulp?  OK.  So task-curing is broccoli.  Like there is too many.  And each time we have to add something to our process,  we're like, OK, let's make another task for that.  Like there is another app, a task.  OK.  So here's an example of some grand file and some definition.  There is like too many.  That's a real example of I found.  I just used a huge grand file and found that on GitHub.  So it's like plugging like this in Grunt.  Well, that's kind of weird.  My advice is use Grunt, because it  avoid you to write too many times through the file system.  And it's really faster than Grunt.  But well, I recommend Grunt, but I don't even use Grunt,  myself.  Meanwhile, in JavaScript, it's interesting now  to see that JavaScript is evolving as well.  Somebody know maybe EA6?  No.  So it's a new specification that you can use in most browser.  But some piece you can use, some piece you cannot.  It has been renamed like this.  It's kind of weird.  But you will have a new version each year now.  So there was a tool called 6.5, which  has been renamed to Babel.  Babel.js, who define itself as a JavaScript compiler.  And it's like Post CSS.  It transforms all to something new.  You have like a future syntax support.  You can transform React.js.  Somebody know React maybe here?  OK.  And it's plugable, so you can use your plugin.  For a moment, Babel was like a single package.  But recently, they explode their ecosystem  to like a ton of package.  Like there is a lot too.  You can see here some transform ES 2015.  There is a lot for this.  And there is a lot for other stuff.  So now we are going to make a recap.  We have compilers like Babel and Post CSS.  You take something, you change it,  and you get some new things.  You can use this for CSS, JavaScript.  And then you even have now MDST, which  is the name of the project, which can help you to get  an ST for some markdown.  And now you can output with new markdown or HTML as well.  So how should we use this?  Should we grant a Gulp?  I'm going to show this.  You all got this moment where is my asset.  And you are not going to get this error directly  in your face with Grunt or Gulp because you don't  have error management.  So I have a trick.  My advice is use web packs.  There is many tools.  Recently I even saw a post yesterday about somebody  who was complaining about the fact that there is too many  tools that just do nothing out of the box.  Like web pack, Post CSS, doesn't do anything  if you use any plugin with it.  But it's like Grunt or Gulp.  If you don't use plugin, there is nothing.  So you need to handle the configuration.  Web pack is like this.  You require some JavaScript.  And you can require anything like a CSS, an SVG.  You have JavaScript here and below it some CSS.  The really interesting thing is that if your pass is not  correct, if your asset is not at the place you think it is,  you will have error management like,  aye, the compiler with blowing your face an error.  Like this asset don't exist.  So you don't have a Mr. Use error that you can track really.  You can get error directly during the compiling step.  So web pack is you create a bundle.  You take some JavaScript in the first place.  And you use loader, which are just like plugins.  You have a compiler.  Same thing.  So here is web pack.  JavaScript, your thing.  You get a bundle.  You will find a lot of boilerplates  because that helps you to set up the tool.  When you don't know the tool, you don't want to read the doc.  Because if there is like five new tools, too many doc to read.  So you can go on the internet and find you will see like a million  of boilerplates.  That might fright you, but there is a good boilerplate  you can find on using GitHub training repo.  Use GitHub training repo.  And you will find the most third repo on GitHub.  So you will have something accurate and that might help you.  So this work for application, you know,  like single page application or websites.  It's the same thing.  I used WordPress like the last month  to make a WordPress plugin to avoid under error.  So here is snippet again.  I'm not sure you have noticed this line, which is kind of weird,  to require some CSS to get some content.  So here is a trick.  It's called CSS Modules.  And it helps.  Here is a BEM selector with a prefix for the company,  for example.  And CSS model is just killing this part.  So you can just use a really simple selector.  Now you require your CSS.  You get a simple object with a generated class name.  This avoids conflicts.  And you can use it.  Here is a line of React.jsx.  But you can use it in a raw JavaScript.  So with this, we can say that we call just simple objects  with style, you know, declaration and values.  So yeah, that's what we want in the first place.  We want to style your original interface.  So why not inline style?  This might seem crazy, like a lot.  But using inline style sort of fix all the issues  we mentioned before.  I can show you an example.  React Native Web.  So it's kind of weird because there is React for the web.  There is React Native to write a native application for iOS  or Android.  And now we get React Native for the web.  I want to highlight the author of this package, which  is the author of normalize.sys, who use normalize.sys?  OK.  Everybody.  So this person was not a web developer in the first place.  But when he got into this, he got a lot of crazy idea.  But all this idea, well, we're just here or to before we  start to use it.  I'm not sure my sentence was correct,  but maybe you understand me.  Here's an example of some React code.  We don't really care about this because it's kind of real.  We can just notice this part, this style.  And you use it for the CSS model.  So later on your code, you can define a stillsheet,  which is like simple CSS like this.  That's kind of cool.  So that might not be relevant for all projects.  But in life style, it can be easy to write a React Native  application as well.  You can use the syntax here to write a website style,  web application, or even React Native application.  That's a cool part.  Facebook implemented a project they called the CSS layout,  which is a re-implementation of Chrome Engine for CSS,  but in a for React Native.  So you can use some rules like margin, height, width, flex,  flexbox, color, font ways, et cetera.  So you can style your native application with this.  That's, I think, interesting.  So now I said and mentioned a lot of things.  You're probably like, wow, I'm not sure.  So today, if you have to write something or take a legacy  project and use new stuff I mentioned,  you can start with adding post-css.  Maybe if you have just auto-profixer,  you have a gulp task for your SAS stillsheet.  You can add auto-profixer, and you're already using post-css.  It's simple, and you will remove a ton of code by doing this.  I have a friend which were using, like, how it was called,  it was a mixing to handle a RAM to pixel for Albreuser.  Internet Explorer 8.  And there were, in his team, they were using this plugin,  like, in, I don't know, everywhere.  They were need a RAM unit.  They were using this mixing to handle the pixel transformation.  So when he started to use post-css with a plugin that  replaced, that add pixels, values, as well as a RAM unit,  like, removed, I don't know, 1,000 line of code  by adding just, you know, like, tree line.  That was something pretty cool.  So you can add easily post-css with some plugin,  and you can use BEM or CSS model, depending on your stack,  and the time you have to, you know, set up the things.  So with this, you will have custom syntax, new syntax,  food proof syntax, eventually, with auto-profixer  on CSS Next.  You can still handle media queries,  because with inline style, it's not easy to define state  and media queries.  It's kind of a problem, but there is some way to handle things,  but it's not really easy.  So if you have some server-side rendering,  I will advise you to use CSS model on this stack right now.  And if you are in a really dynamic context,  like an application, you can use inline style  that will make your code, you know,  compatible with Racknative.  And you will have a lot of flexibility,  because you can generate in JavaScript some rules and value,  et cetera.  So the stack with post-sys can kind of solve some issues,  but this can be used today and gradually.  So you can just add auto-profixers  and add post-sys with some plugins.  Then at the same time, you can start to use BAM.  Now you can do this.  It's just a convention.  And later, you can decide to remove some code  and use CSS model, which is safer than BAM.  Besides that, your inline style can  that can solve all major CSS issues,  but the pre-rendering is not really good.  But you can use this kind of today,  because you can switch or you can mix,  because there is some package that  allow you to use CSS to transform CSS to JavaScript  for Racknative, so there's a package for that.  And you can also transform JavaScript style to some CSS.  So you can go back.  You can change the way you use this.  There is even more package on GitHub or NPM  to handle this kind of weird transformation,  but that might be relevant in some place.  So my advice is just adjust your choice depending  on your need and your current stack,  because we can just say, hey, boss,  I'm going to ditch everything and set up a new stack that's  just awesome, because hand users don't care about that.  When you make your whole application,  hand users just want the user interface.  So you can bring and add something for you  to deliver some feature, some bug fix more quickly.  So you can add this for you, because it's for you.  It's not for the end user.  He don't care about that.  Do you got any questions?  You can go.  There is not a lot of people, so I  am sure all of you can ask one or two questions.  Did you understand me for 80%?  That's the first time I'm doing a presentation in English,  so that's my question.  I did a lightning talk in five minutes, but it was weird.  You have any question?  Yeah?  So I just wanted to make a round of the things.  So please let's make a goal to do the CSS.  So I'm doing a great Nesquad.  So we've CSS, so we're doing the CSS  file and running that through a built-in set.  You can, are you asking me if you can use CSS with less?  No, I'm not really.  How do you write CSS?  OK, just CSS.  So you use CSS files, and most syntax  highlighter in your text editor, we handle basic things  like nested media queries.  It doesn't add anything special to the language grammar.  So you can use just CSS files.  And then you can use the one after a built-in set.  Excuse me?  You still write through a built-in set?  Yeah, yeah, yeah.  We already have both steps.  That's not going to stop.  No, no, I just want to.  Another one, please.  Don't be shy.  No?  Thank you.
PostCSS__cssnext_and_the_future_of_CSS_-_Maxime_Thirouin_0_275.png PostCSS__cssnext_and_the_future_of_CSS_-_Maxime_Thirouin_276_3275.png PostCSS__cssnext_and_the_future_of_CSS_-_Maxime_Thirouin_3276_3827.png PostCSS__cssnext_and_the_future_of_CSS_-_Maxime_Thirouin_3828_4415.png PostCSS__cssnext_and_the_future_of_CSS_-_Maxime_Thirouin_4416_5987.png PostCSS__cssnext_and_the_future_of_CSS_-_Maxime_Thirouin_5988_6383.png PostCSS__cssnext_and_the_future_of_CSS_-_Maxime_Thirouin_6384_6959.png PostCSS__cssnext_and_the_future_of_CSS_-_Maxime_Thirouin_6960_8483.png PostCSS__cssnext_and_the_future_of_CSS_-_Maxime_Thirouin_8484_9767.png PostCSS__cssnext_and_the_future_of_CSS_-_Maxime_Thirouin_9768_10007.png PostCSS__cssnext_and_the_future_of_CSS_-_Maxime_Thirouin_10008_11243.png PostCSS__cssnext_and_the_future_of_CSS_-_Maxime_Thirouin_11244_12371.png PostCSS__cssnext_and_the_future_of_CSS_-_Maxime_Thirouin_12372_13187.png PostCSS__cssnext_and_the_future_of_CSS_-_Maxime_Thirouin_13188_14279.png PostCSS__cssnext_and_the_future_of_CSS_-_Maxime_Thirouin_14280_17279.png PostCSS__cssnext_and_the_future_of_CSS_-_Maxime_Thirouin_17280_18455.png PostCSS__cssnext_and_the_future_of_CSS_-_Maxime_Thirouin_18456_20159.png PostCSS__cssnext_and_the_future_of_CSS_-_Maxime_Thirouin_20160_20579.png PostCSS__cssnext_and_the_future_of_CSS_-_Maxime_Thirouin_20580_24491.png PostCSS__cssnext_and_the_future_of_CSS_-_Maxime_Thirouin_24492_25283.png PostCSS__cssnext_and_the_future_of_CSS_-_Maxime_Thirouin_25284_29111.png PostCSS__cssnext_and_the_future_of_CSS_-_Maxime_Thirouin_29112_33479.png PostCSS__cssnext_and_the_future_of_CSS_-_Maxime_Thirouin_33480_33659.png PostCSS__cssnext_and_the_future_of_CSS_-_Maxime_Thirouin_33660_33839.png PostCSS__cssnext_and_the_future_of_CSS_-_Maxime_Thirouin_33840_36563.png PostCSS__cssnext_and_the_future_of_CSS_-_Maxime_Thirouin_36564_37727.png PostCSS__cssnext_and_the_future_of_CSS_-_Maxime_Thirouin_37728_38639.png PostCSS__cssnext_and_the_future_of_CSS_-_Maxime_Thirouin_38640_38735.png PostCSS__cssnext_and_the_future_of_CSS_-_Maxime_Thirouin_38736_39623.png PostCSS__cssnext_and_the_future_of_CSS_-_Maxime_Thirouin_39624_41111.png PostCSS__cssnext_and_the_future_of_CSS_-_Maxime_Thirouin_41112_41771.png PostCSS__cssnext_and_the_future_of_CSS_-_Maxime_Thirouin_41772_42167.png PostCSS__cssnext_and_the_future_of_CSS_-_Maxime_Thirouin_42168_43583.png PostCSS__cssnext_and_the_future_of_CSS_-_Maxime_Thirouin_43584_43715.png PostCSS__cssnext_and_the_future_of_CSS_-_Maxime_Thirouin_43716_43787.png PostCSS__cssnext_and_the_future_of_CSS_-_Maxime_Thirouin_43788_43919.png PostCSS__cssnext_and_the_future_of_CSS_-_Maxime_Thirouin_43920_45023.png PostCSS__cssnext_and_the_future_of_CSS_-_Maxime_Thirouin_45024_45191.png PostCSS__cssnext_and_the_future_of_CSS_-_Maxime_Thirouin_45192_46163.png PostCSS__cssnext_and_the_future_of_CSS_-_Maxime_Thirouin_46164_47051.png PostCSS__cssnext_and_the_future_of_CSS_-_Maxime_Thirouin_47052_50363.png PostCSS__cssnext_and_the_future_of_CSS_-_Maxime_Thirouin_50364_51023.png PostCSS__cssnext_and_the_future_of_CSS_-_Maxime_Thirouin_51024_51407.png PostCSS__cssnext_and_the_future_of_CSS_-_Maxime_Thirouin_51408_52655.png PostCSS__cssnext_and_the_future_of_CSS_-_Maxime_Thirouin_52656_52703.png PostCSS__cssnext_and_the_future_of_CSS_-_Maxime_Thirouin_52704_52823.png PostCSS__cssnext_and_the_future_of_CSS_-_Maxime_Thirouin_52824_53363.png PostCSS__cssnext_and_the_future_of_CSS_-_Maxime_Thirouin_53364_53555.png PostCSS__cssnext_and_the_future_of_CSS_-_Maxime_Thirouin_53556_54479.png PostCSS__cssnext_and_the_future_of_CSS_-_Maxime_Thirouin_54480_55331.png PostCSS__cssnext_and_the_future_of_CSS_-_Maxime_Thirouin_55332_56987.png PostCSS__cssnext_and_the_future_of_CSS_-_Maxime_Thirouin_56988_58307.png PostCSS__cssnext_and_the_future_of_CSS_-_Maxime_Thirouin_58308_63119.png PostCSS__cssnext_and_the_future_of_CSS_-_Maxime_Thirouin_63120_63443.png PostCSS__cssnext_and_the_future_of_CSS_-_Maxime_Thirouin_63444_63611.png PostCSS__cssnext_and_the_future_of_CSS_-_Maxime_Thirouin_63612_64187.png PostCSS__cssnext_and_the_future_of_CSS_-_Maxime_Thirouin_64188_64547.png PostCSS__cssnext_and_the_future_of_CSS_-_Maxime_Thirouin_64548_73391.png PostCSS__cssnext_and_the_future_of_CSS_-_Maxime_Thirouin_73392_73571.png PostCSS__cssnext_and_the_future_of_CSS_-_Maxime_Thirouin_73572_74087.png PostCSS__cssnext_and_the_future_of_CSS_-_Maxime_Thirouin_74088_74639.png PostCSS__cssnext_and_the_future_of_CSS_-_Maxime_Thirouin_74640_75923.png PostCSS__cssnext_and_the_future_of_CSS_-_Maxime_Thirouin_75924_75995.png PostCSS__cssnext_and_the_future_of_CSS_-_Maxime_Thirouin_75996_76235.png PostCSS__cssnext_and_the_future_of_CSS_-_Maxime_Thirouin_76236_76288.png