Using Tomorrow's CSS Today
•Download as PPTX, PDF•
0 likes•587 views
CSS4 may only be in the working draft stage, but that doesn't mean we can't begin to use some of it's capabilities in our current designs. Variables, color manipulation, custom media queries, and custom selectors are just a few of the powerful new features that can be utilized to take our css to the next level. This talk will take a look at the benefits of using postprocessers to write powerful, bleeding-edge CSS and have it work in today's browsers.
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Using Tomorrow's CSS Today
Similar to Using Tomorrow's CSS Today (20)
More from Brian Graves
More from Brian Graves (9)
Recently uploaded
Recently uploaded (20)
Using Tomorrow's CSS Today
- 10. CSS in 2015 is Amazing.
- 12. There is No CSS3! And other facts about how standards are made.
- 13. Despite the popularity of the “CSS3” buzzword, there is actually no spec defining such a thing. – Lea Verou
- 16. Animation
- 17. Typography
- 18. Layout
- 19. “CSS is not a real programming language”
- 20. Problems with CSS • Cross-browser compatibility issues • Vendor prefixes • No variables • No inline importing • No nested selectors • No functions/mixins • No color manipulation • No basic arithmetic
- 21. Rise of the Preprocessors. How we filled in the gaps.
- 25. .row { @include display-flex; background-color: $color-blue; } .row { display: -webkit-box; display: -webkit-flex; display: -ms-flexbox; display: flex; background-color: #173fb1; }
- 26. Preprocessors Perpetuate A Problem. – Aaron Ladage
- 27. More & More Layers of Abstraction
- 28. Problems with Preprocessors • Not “real” code • Proprietary syntax • Often written in non front-end languages • Not as easily extensible • Must be compiled • Compile times can be slow • Browsers are catching up
- 29. Preprocessors? Where we’re going, we don’t need preprocessors.
- 30. THE FUTURE OF CSS IS NOW
- 31. Variables
- 32. Color Functions
- 33. Nesting
- 35. PostCSS
- 36. .row { @include display-flex; background: $color-blue; } .row { display: -webkit-box; display: -webkit-flex; display: -ms-flexbox; display: flex; background-color: #173fb1; }
- 37. .row { display: flex; background: var(—color-blue); } .row { display: -webkit-box; display: -webkit-flex; display: -ms-flexbox; display: flex; background-color: #173fb1; }
- 38. PostCSS Advantages • Write CSS using CSS • Use CSS3 without worry • Even Use CSS4 • Modular • Works with your existing task runner • Faster compile times • Built on Node • No Ruby dependencies • Easier to debug • Tons of existing plugins • Can’t find a plugin? Write one in javascript.
- 39. Autoprefixer
- 40. PostCSS Ecosystem • Autoprefixer • PostCSS-nested • PostCSS-color-function • PostCSS-calc • PostCSS-custom-properties • PostCSS-mixins • PostCSS-custom-media • CSSNext • PostCSS-import • Can’t find a plugin? Write one in javascript.
- 41. Variables
- 42. :root { --color-blue: #0A81C4; --color-blue-dark: #005581; } .element { color: var(--color-blue); } .element:hover { color: var(--color-blue-dark); }
- 43. Variables lose their value if you have to constantly track down what they represent. – Ryan Heap
- 44. Color Functions
- 45. .element { color: #1982C5; } .element-modifier { color: color(#1982C5 tint(40%)); }
- 46. .element { color: #1982C5; } .element-modifier { color: color(#1982C5 shade(40%)); }
- 47. CSS Color Functions • Tints & Shades • RGBA Adjustment • HSL/HWB Adjustment • Color Blending (blend & blenda) • Guarantee Contrast
- 48. Nesting
- 49. .element { color: blue; {&.modifier { color: red; }} }
- 50. .element { color: blue; {&.modifier { color: red; }} }
- 51. .element { color: blue; &.modifier { color: red; } }
- 53. @custom-media --small (min-width: 450px); @media (--small) { .element { font-size: 22px; } }
- 55. /* generated with grunt-sass-globbing */ @import "utilities/variables"; @import "utilities/mixins"; @import "utilities/reset"; @import “utilities/breakpoints"; @import “atoms/buttons"; @import “atoms/headings"; @import “atoms/icons"; @import “atoms/text"; @import “molecules/components/disclaimer“; …
- 56. Mixins
- 57. Problems with CSS • Cross-browser compatibility issues • Vendor prefixes • No variables • No inline importing • No nested selectors • No functions/mixins • No color manipulation • No basic arithmetic
- 58. One Day…
- 59. Let’s Get As Close As We Can To The Real Language
Editor's Notes
- Throughout 2012 there was a hoax taking place on Facebook and Twitter. Someone had Photoshopped the display of the Delorian from Back to the Future II to read June 27th, 2012. Everyone, well everyone that didn’t know the movie well, posted away. All, wanting to know where there hover boards were. so why did this phenomenon take off
- it’s 2015
- We may not have flying cars
- but we do have hover boards. just ask justin bieber or wiz.
- and we have slightly better 3d graphics
- and thankfully we’ve all but killed off fax machines.
- and…
- So, how Did We Get Here? how did we get to the point where we can say css is amazing?
- One of the things that got us here was the wisdom of the csswg to make the css spec more modular. While trying to finish CSS 2.1, they realized that these big monolithic "versions" weren't any good. They were difficult to maintain, and slow to develop. So they decided to split up the CSS language into a bunch of independent modules.
- So, despite what you may have heard, there really is no such thing as css3 Each css module can now level up independently, and contains only a smallish set of features, so it's harder for a large set of features to be slowed down by a single stubborn feature. Some modules start out at level 3, if they extend something from CSS2.1. Others start out at level 1, if they're something new (for example, Flexbox).
- the end result of all of this modularization is that we’re now seeing css features come out at a record pace.
- but while they were coming out faster that before, most of them only focused on the visual aspects of css
- things like animation - transitions, transforms & keyframes
- typography - web fonts, hyphenation, etc
- new layout techniques like flexbox, columns, grids everyone knows the inherent problems with absolute pos and floats. some of the workarounds we used for years. these layout techniques are great and address a lot of those problems. and while all of these things helped to solve those existing problems. they didn’t get to the core of the problems with css.
- this is what you hear from a lot of developers.
- and it’s because CSS does have a lot of inherent problems still Cross-browser compatibility issues Vendor prefixes No variables No inline importing No nested selectors No functions/mixins No color manipulation No basic arithmetic
- Developers wanted these problems solved, but for a long time, the spec updates coming through were only addressing the visual front end. Developers wanted better authoring tools and realized they had to do it themselves. Enter preprocessors! People started to fill in those gaps themselves
- to help them do this they created things like sass that gave them many of these powers sass is probably the most popular of the bunch but there’s also
- also fairly popular, less does many of the same things as sass, just maybe with a little bit smaller user base
- and there’s also stylus - probably the least popular, but maybe the most powerful. adds additional things like built in globbing and some other things. popular with people who hate punctuation. :) preprocessors gave devs the authoring enhancements they craved- those things like variables, nesting, color functions, custom media queries
- The way all of these work is: A developer writes code using a preprocessor’s proprietary syntax. A task runner notices the code change and compiles the preprocessor code. Standards-based CSS is output by the task runner and fed to the browser.
- But preprocessors perpetuate a problem
- We’re putting more and more layers of abstraction between the code we write and the code the browser can read
- And that’s because preprocessors are their own programming languages when you really think about it. Not "real" code - a browser can never read sass Proprietary syntax Often written in “non-front-end" languages Not as easily extensible - Must be compiled, today and forever - sass will never natively run in a browser Compile times can be slow Browsers are catching up
- but well they had they issues, preprocessors did solve our problems. and as use of them surged, the w3c began to take notice. But they haven’t just adopted everything from Sass. They’ve taken more of an in with the good out with the bad type approach.
- And now we’re at a point where many of these authoring tools are in proposed or working draft stages in native css. Some have even made their way into browsers. That means that we’re at the beginning stages of being able to use these things in native css. Free from sass, less, or stylus
- things like variables
- color functions
- nesting
- custom media queries but all of these things are just proposed spec they aren’t approved and very few of them have landed in browsers. really only variables in firefox. so, what is the solution?
- Instead of using a preprocessor. We can use what’s been referred to as a postprocessor. Who here has heard of PostCSS or just the general concept of a postprocessor? now to be fair. things like PostCSS, which is the most popular, aren’t really postprocessors. That is, they don’t happen at runtime, so technically yes, postprocessors are still preprocessors.
- but there definitely are differences between something like postcss and sass If you remember — our preprocessor process: A developer writes code using a preprocessor’s proprietary syntax. A task runner notices the code change and compiles the preprocessor code. Standards-based CSS is output by the task runner and fed to the browser.
- with our post processor or transpiler, instead, our process looks like this: A developer writes code in standards based (even next-gen) CSS. A task runner notices the change and transpiles it into browser-friendly CSS. Standards-based CSS is output by the task runner and fed to the browser.
- PostCSS Advantages: Write your CSS using CSS. Use CSS3 with reckless abandon. Hell, use CSS4. Who cares if that's not actually a thing yet? Modular - only use what you need Works with your existing task runners - grunt, gulp, or probably even fly.js that I heard about all of 12 hours ago Faster compile times Built on Node! - which means No more Ruby dependencies! Easier to debug if you’re a js dev Countless plugins Can't find a plugin that does what you want? Write your own in nothing but JavaScript.
- There’s a good chance you’ve at least heard of or are already using part of the postCSS ecosystem. Autoprefixer - A popular replacement for Compass's vendor prefix mixins. You define which browsers you need to support Cross-references the caniuse database Automatically adds vendor prefixes to your CSS3 properties. No need to memorize special function names; just write CSS and let it do its work in the background.
- but autoprefixer is just one postcss plugin there are many many more. and you may notice that this list and the list of upcoming native css authoring tools is very similar.
- VARIABLES if you’re used to sass variables, the syntax may look a little different. but the basic concept is the same as a variable used in any other language.
- you define your variables with that dash dash you see there in root. and then call it with var()… is the syntax as clean as the $ sign in sass? arguably not, but you honestly get used to it very quickly, and…it is native spec, so you’re going to have to use it eventually
- one caveat, if you’re new to variables - make sure to use a naming system that makes sense you should know just from looking at your variable, what it represents. otherwise they lose most of their value.
- Color Module Level 4 - allow you to modify colors Use postcss-color. You may have done similar things in sass with saturation or lighten and darken functions. Essentially, color functions work like this:
- using tint as an example - what tint does is mix your base color with white. so if you have an element, say a link that’s blue and then you want to set a modifier of some sort off of your base color, you can do so right in your css. call the color in your color function, and pass in tint() plus the percentage of white you want to mix it with. so, essentially the amount you want to lighten it by and the result is what you see here.
- shade is more or less works the same as tint, only instead of mixing the base color with white it mixes it with black, darkening it.
- and tints and shades aren’t your only color options you can do things with alpha transparently, hsl, you can blend colors, and there’s even some new crazy stuff in the spec you can do like guarantee contrast.
- nested selectors - this IS in the spec…but only in authoring state…that is to say…not very far along at all
- the authoring state of the spec is proposed to work like this:
- red set of curly braces and you can use postcss-nesting if you want to use that spec style
- but there is also postcss plugin for sass style nesting if that’s what you’re used to and more comfortable with postcss-nested Just like Sass, remember to use them sparingly.
- custom media queries - let you set your media queries to variables
- custom media queries example easier to reference works well with “resize until it looks like shit - add a media query approach” estimate media queries and then adjust as you go also good for not having to remember the exact pixel dimensions you set your breakpoints at - you can just reference small, medium, large, etc
- One of the things not in the spec, at least yet, but that we weren’t willing to give up is the concept of partials and globbing And the good news is that if you can do it with sass, you can probably pretty easily do it with postcss. postcss-import allows you to do basic partials.
- and if you’re a fan of globbing…grunt-sass-globbing will still work for you in fact aaron has spent probably more time than necessary trying to convince the creator to drop sass from the name
- Mixins As a team, we’re honestly of the opinion that if you’ve got super complex mixins you’re probably over-engineering. But there are definitely use cases, so if you want mixins, which aren’t yet in the spec, you can use the postcss-mixins plugin.
- FRONT-END DEVELOPMENT IS AT A CROSSROADS. We're not that far away from next-gen CSS and JS being adopted into standards and supported natively in all modern browsers. Until that happens, it's a wonderful time to get as close to "real" code as you can in your development process.
- Let’s take a look back at our problems with CSS. Which ones have we solved? Really? Most of them!
- One day, hopefully, we really can get to a point where all of this is available in browsers natively. But even though that’s not yet the case, the specs are out there and they’re catching up.
- There’s no longer any reason to hide behind a language of abstraction. Let’s choose to work towards ONCE AGAIN getting as close as we can to REAL, POWERFUL, CSS.