davidbgk
/
larlet-fr-david-cache
Watch 1
Star 0
Fork 0
Code Releases 0 Activity
A place to cache linked articles (think custom and personal wayback machine)
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
42 Commits
1 Branch
Tree: 2e4d51a7b7
Branches Tags
${ item.name }
Create branch ${ searchTerm }
from '2e4d51a7b7'
${ noResults }
larlet-fr-david-cache/cache/95e919fd9da95be15758b7cd420.../index.md

index.md 17KB
Raw Normal View History

Add cache data
4 years ago
​
​
​
​
​
​
​
 12345678 
  1. title: The End of Global CSS

  2. url: https://medium.com/seek-ui-engineering/the-end-of-global-css-90d2a4a06284

  3. hash_url: 95e919fd9da95be15758b7cd420b6d0c

  4. 

  5. <p name="d899" id="d899" class="graf--p graf--first">On <a href="https://github.com/webpack/css-loader/commit/d2c9c25721a711b0fe041c597b43646e82d9f145" data-href="https://github.com/webpack/css-loader/commit/d2c9c25721a711b0fe041c597b43646e82d9f145" class="markup--anchor markup--p-anchor" rel="nofollow">April 22, 2015</a>, <a href="https://github.com/sokra" data-href="https://github.com/sokra" class="markup--anchor markup--p-anchor" rel="nofollow">Tobias Koppers</a> — the ever tireless author of Webpack — committed the first iteration of a new feature to css-loader, at the time called <em class="markup--em markup--p-em">placeholders</em>, now known as <a href="https://github.com/webpack/css-loader#local-scope" data-href="https://github.com/webpack/css-loader#local-scope" class="markup--anchor markup--p-anchor" rel="nofollow">local scope</a>.</p><p name="2794" id="2794" class="graf--p">This feature allows us to export class names from our CSS into the consuming JavaScript code.</p><p name="3479" id="3479" class="graf--p">In short, instead of writing this:</p><pre name="8c0d" id="8c0d" class="graf--pre"><strong class="markup--strong markup--pre-strong">require</strong>('./MyComponent.css');</pre><p name="2bd7" id="2bd7" class="graf--p">We write this:</p><pre name="db53" id="db53" class="graf--pre"><strong class="markup--strong markup--pre-strong">import</strong> styles <strong class="markup--strong markup--pre-strong">from</strong> './MyComponent.css';</pre><p name="130c" id="130c" class="graf--p">So, in this example, what does <em class="markup--em markup--p-em">styles </em>evaluate to?</p><p name="d8a4" id="d8a4" class="graf--p">To see what is exported from our CSS, let’s take a look at an example of what our style sheet might look like.</p><pre name="a4f1" id="a4f1" class="graf--pre"><strong class="markup--strong markup--pre-strong">:local(.</strong>foo) {<br/>  <strong class="markup--strong markup--pre-strong">color</strong>: red;<br/>}</pre><pre name="01b4" id="01b4" class="graf--pre"><strong class="markup--strong markup--pre-strong">:local(.</strong>bar) {<br/>  <strong class="markup--strong markup--pre-strong">color</strong>: blue;<br/>}</pre><p name="067a" id="067a" class="graf--p">In this case, we’ve used css-loader’s custom <em class="markup--em markup--p-em">:local(.identifier)</em> syntax to export two identifiers — <em class="markup--em markup--p-em">foo</em> and <em class="markup--em markup--p-em">bar</em>.</p><p name="7aae" id="7aae" class="graf--p">These identifiers map to class strings that we can use in our JavaScript file. For example, when using <a href="http://facebook.github.io/react/" data-href="http://facebook.github.io/react/" class="markup--anchor markup--p-anchor" rel="nofollow">React</a>:</p><pre name="4e34" id="4e34" class="graf--pre"><strong class="markup--strong markup--pre-strong">import</strong> styles <strong class="markup--strong markup--pre-strong">from</strong> './MyComponent.css';</pre><pre name="fe30" id="fe30" class="graf--pre"><strong class="markup--strong markup--pre-strong">import</strong> React, { Component } <strong class="markup--strong markup--pre-strong">from</strong> 'react';</pre><pre name="7c51" id="7c51" class="graf--pre"><strong class="markup--strong markup--pre-strong">export default class</strong> MyComponent <strong class="markup--strong markup--pre-strong">extends</strong> Component {</pre><pre name="cced" id="cced" class="graf--pre">  <strong class="markup--strong markup--pre-strong">render</strong>() {<br/>    return (<br/>      &lt;div&gt;<br/>        &lt;div className={<strong class="markup--strong markup--pre-strong">styles.foo</strong>}&gt;<strong class="markup--strong markup--pre-strong">Foo</strong>&lt;/div&gt;<br/>        &lt;div className={<strong class="markup--strong markup--pre-strong">styles.bar</strong>}&gt;<strong class="markup--strong markup--pre-strong">Bar</strong>&lt;/div&gt;<br/>      &lt;/div&gt;<br/>    );<br/>  }</pre><pre name="14c7" id="14c7" class="graf--pre">}</pre><p name="6f59" id="6f59" class="graf--p">Importantly, these identifiers map to class strings that are guaranteed to be unique in a global context.</p><p name="05fe" id="05fe" class="graf--p graf--last">We no longer need to add lengthy prefixes to all of our selectors to simulate scoping. More components could define their own <em class="markup--em markup--p-em">foo</em> and <em class="markup--em markup--p-em">bar</em> identifiers which — unlike the traditional global selector model—wouldn’t produce any naming collisions.</p>

  6. 

  7. 

  8. <p name="e256" id="e256" class="graf--p graf--first">It’s critical to recognise the massive shift that’s occurring here.</p><p name="8051" id="8051" class="graf--p">We can now make changes to our CSS with confidence that we’re not accidentally affecting elements elsewhere in the page. We’ve introduced a sane scoping model to our CSS.</p><p name="0169" id="0169" class="graf--p">The benefits of global CSS — style re-use between components via utility classes, etc. — are still achievable with this model. The key difference is that, just like when we work in other technologies, we need to explicitly import the classes that we depend on. Our code can’t make many, if any, assumptions about the global environment.</p><blockquote name="db73" id="db73" class="graf--pullquote pullquote graf--last">Writing maintainable CSS is now encouraged, not by careful adherence to a naming convention, but by style encapsulation during development.</blockquote></div></div></section><section name="5fe1" class=" section--content"><div class="section-divider layoutSingleColumn"><hr class="section-divider"></div><div class="section-content"><div class="section-inner layoutSingleColumn"><p name="032b" id="032b" class="graf--p graf--first">As a result of this scoping model, we’ve handed control of the <em class="markup--em markup--p-em">actual</em> class names over to Webpack. Luckily, this is something that we can configure.</p><p name="b528" id="b528" class="graf--p">By default, css-loader transforms our identifiers into hashes.</p><p name="f6c6" id="f6c6" class="graf--p">For example, this:</p><pre name="98b2" id="98b2" class="graf--pre">:local(.foo) { … }</pre><p name="75ad" id="75ad" class="graf--p">Is compiled into this:</p><pre name="06d9" id="06d9" class="graf--pre">._1rJwx92-gmbvaLiDdzgXiJ { … }</pre><p name="679e" id="679e" class="graf--p">In development, this isn’t terribly helpful for debugging purposes. To make the classes more useful, we can configure the class format in our Webpack config as a parameter to css-loader:</p><pre name="6240" id="6240" class="graf--pre">loaders: [<br>  ...<br>  {<br>    test: /\.css$/,<br>    loader: &#39;css?<strong class="markup--strong markup--pre-strong">localIdentName=[name]__[local]___[hash:base64:5]</strong>&#39;<br>  }<br>]</pre><p name="d33e" id="d33e" class="graf--p">In this case, our <em class="markup--em markup--p-em">foo </em>class identifier from earlier would compile into this:</p><pre name="adae" id="adae" class="graf--pre">.<strong class="markup--strong markup--pre-strong">MyComponent__foo___1rJwx</strong> { … }</pre><p name="0931" id="0931" class="graf--p">We can now clearly see the name of the identifier, as well as the component that it came from.</p><p name="8d8d" id="8d8d" class="graf--p">Using the <em class="markup--em markup--p-em">node_env</em> environment variable, we can configure different class patterns for development and production.</p><pre name="bda0" id="bda0" class="graf--pre">loader: &#39;css?<strong class="markup--strong markup--pre-strong">localIdentName=&#39; + </strong>(<br>  process.env.NODE_ENV === &#39;development&#39; ?<strong class="markup--strong markup--pre-strong"><br>    &#39;[name]__[local]___[hash:base64:5]</strong>&#39; :<br>    &#39;<strong class="markup--strong markup--pre-strong">[hash:base64:5]&#39;<br></strong>)</pre><blockquote name="b66f" id="b66f" class="graf--pullquote pullquote graf--last">Now that Webpack has control of our class names, we can trivially<br>add support for minified classes in production.</blockquote></div></div></section><section name="830e" class=" section--content"><div class="section-divider layoutSingleColumn"><hr class="section-divider"></div><div class="section-content"><div class="section-inner layoutSingleColumn"><p name="a492" id="a492" class="graf--p graf--first">As soon as we discovered this feature, we didn’t hesitate to localise the styles in our most recent project. We were already scoping our CSS to each component with BEM — if only by convention — so it was a natural fit.</p><p name="e180" id="e180" class="graf--p">Interestingly, a pattern quickly emerged. Most of our CSS files contained nothing but local identifiers:</p><pre name="e8ea" id="e8ea" class="graf--pre"><strong class="markup--strong markup--pre-strong">:local(.</strong>backdrop) { … }</pre><pre name="a47b" id="a47b" class="graf--pre"><strong class="markup--strong markup--pre-strong">:local(.</strong>root_isCollapsed .backdrop) { … }</pre><pre name="56b6" id="56b6" class="graf--pre"><strong class="markup--strong markup--pre-strong">:local(.</strong>field) { … }</pre><pre name="3375" id="3375" class="graf--pre"><strong class="markup--strong markup--pre-strong">:local(.</strong>field):focus { … }</pre><pre name="ebb3" id="ebb3" class="graf--pre">etc…</pre><p name="ce4f" id="ce4f" class="graf--p">Global selectors were only required in a few places in the application. This instinctively led towards a very important question.</p><blockquote name="562d" id="562d" class="graf--pullquote pullquote">What if — instead of requiring a special syntax — our selectors were local by default, and global selectors were the opt-in exception?</blockquote><p name="1f39" id="1f39" class="graf--p">What if we could write this instead?</p><pre name="b489" id="b489" class="graf--pre">.backdrop { … }</pre><pre name="0cd8" id="0cd8" class="graf--pre">.root_isCollapsed .backdrop { … }</pre><pre name="c435" id="c435" class="graf--pre">.field { … }</pre><pre name="d04d" id="d04d" class="graf--pre">.field:focus { … }</pre><p name="9c8b" id="9c8b" class="graf--p">While these selectors would normally be too vague, transforming them into css-loader’s local scope format would eliminate this issue and ensure they remain scoped to the module in which they were used.</p><p name="6dd0" id="6dd0" class="graf--p">For those few cases where we couldn’t avoid global styles, we could explicitly mark them with a special <em class="markup--em markup--p-em">:global</em> syntax.</p><p name="476e" id="476e" class="graf--p">For example, when styling the un-scoped classes generated by <a href="https://facebook.github.io/react/docs/animation.html#high-level-api-reactcsstransitiongroup" data-href="https://facebook.github.io/react/docs/animation.html#high-level-api-reactcsstransitiongroup" class="markup--anchor markup--p-anchor" rel="nofollow">ReactCSSTransitionGroup</a>:</p><pre name="25f9" id="25f9" class="graf--pre">.panel <strong class="markup--strong markup--pre-strong">:global</strong> .transition-active-enter { … }</pre><p name="4f2d" id="4f2d" class="graf--p graf--last">In this case, we’re not just scoping the local <em class="markup--em markup--p-em">panel</em> identifier to our module — we’re also styling a global class that is outside of our control.</p></div></div></section><section name="e9db" class=" section--content"><div class="section-divider layoutSingleColumn"><hr class="section-divider"></div><div class="section-content"><div class="section-inner layoutSingleColumn"><p name="61be" id="61be" class="graf--p graf--first">Once we started investigating how me might implement this local-by-default class syntax, we realised that it wouldn’t be too difficult.</p><p name="eee8" id="eee8" class="graf--p">To achieve this, we leveraged <a href="https://github.com/postcss/postcss" data-href="https://github.com/postcss/postcss" class="markup--anchor markup--p-anchor" rel="nofollow">PostCSS</a> — a fantastic tool that allows you to write custom CSS transformers as plugins. One of the most popular CSS build tools today — <a href="https://github.com/postcss/autoprefixer" data-href="https://github.com/postcss/autoprefixer" class="markup--anchor markup--p-anchor" rel="nofollow">Autoprefixer</a> — is actually a PostCSS plugin that doubles as a standalone tool.</p><p name="7af3" id="7af3" class="graf--p"><strong class="markup--strong markup--p-strong">To formalise the usage of local CSS, I’ve open sourced a highly<br>experimental plugin for PostCSS called </strong><a href="https://github.com/markdalgleish/postcss-local-scope" data-href="https://github.com/markdalgleish/postcss-local-scope" class="markup--anchor markup--p-anchor" rel="nofollow"><strong class="markup--strong markup--p-strong">postcss-local-scope</strong></a><strong class="markup--strong markup--p-strong">. It’s still under heavy development, so use it in production at your own risk.</strong></p><p name="8241" id="8241" class="graf--p">If you’re using Webpack, it’s a relatively straightforward process to hook <a href="https://github.com/postcss/postcss-loader" data-href="https://github.com/postcss/postcss-loader" class="markup--anchor markup--p-anchor" rel="nofollow">postcss-loader</a> and <a href="https://github.com/markdalgleish/postcss-local-scope" data-href="https://github.com/markdalgleish/postcss-local-scope" class="markup--anchor markup--p-anchor" rel="nofollow">postcss-local-scope</a> up to your CSS build process. Rather than document it here, I’ve created an example repository — <a href="https://github.com/markdalgleish/postcss-local-scope-example" data-href="https://github.com/markdalgleish/postcss-local-scope-example" class="markup--anchor markup--p-anchor" rel="nofollow">postcss-local-scope-example</a>—that shows a small working example.</p><figure name="72b6" id="72b6" class="graf--figure graf--iframe graf--last"><div class="iframeContainer"><iframe width="700" height="250" src="/media/48009fcff6d0175040817c911d25707d?maxWidth=700" data-media-id="48009fcff6d0175040817c911d25707d" frameborder="0"></iframe></div></figure></div></div></section><section name="f940" class=" section--content"><div class="section-divider layoutSingleColumn"><hr class="section-divider"></div><div class="section-content"><div class="section-inner layoutSingleColumn"><p name="a4ed" id="a4ed" class="graf--p graf--first">Excitingly, introducing local scope is really just the beginning.</p><p name="0317" id="0317" class="graf--p">Letting the build tool handle the generation of class names has some potentially huge implications. In the long term, we could decide to stop being <em class="markup--em markup--p-em">human compilers</em> and let the computer optimise the output.</p><blockquote name="4918" id="4918" class="graf--pullquote pullquote graf--last">In the future, we could start generating shared classes between components automatically, treating style re-use as an optimisation at compile time.</blockquote></div></div></section><section name="720e" class=" section--content"><div class="section-divider layoutSingleColumn"><hr class="section-divider"></div><div class="section-content"><div class="section-inner layoutSingleColumn"><p name="ca7a" id="ca7a" class="graf--p graf--first">Once you’ve tried working with local CSS, there’s really no going back. Experiencing true local scope in our style sheets — in a way that works across all browsers— is not something to be easily ignored.</p><p name="52ec" id="52ec" class="graf--p">Introducing local scope has had a significant ripple effect on how we approach our CSS. Naming conventions, patterns of re-use, and the potential extraction of styles into separate packages are all directly affected by this shift, and we’re only at the beginning of this new era of local CSS.</p><p name="59a2" id="59a2" class="graf--p">Understanding the ramifications of this shift is something that we’re still working through. With your valuable input and experimentation, I’m hoping that this is a conversation we can have together as a larger community.</p><blockquote name="cc52" id="cc52" class="graf--pullquote pullquote">To get involved, make sure you see it with your own eyes by<br>checking out <a href="https://github.com/markdalgleish/postcss-local-scope-example" data-href="https://github.com/markdalgleish/postcss-local-scope-example" class="markup--anchor markup--pullquote-anchor" rel="nofollow">postcss-local-scope-example</a>.</blockquote><p name="edfa" id="edfa" class="graf--p graf--last">Once you’ve seen it in action, I think you’ll agree that it’s not just hyperbole — the days of global CSS are coming to an end. The future of CSS is <em class="markup--em markup--p-em">local</em>.</p></div></div></section><section name="b08a" class=" section--content section--last"><div class="section-divider layoutSingleColumn"><hr class="section-divider"></div><div class="section-content"><div class="section-inner layoutSingleColumn"><p name="ee6f" id="ee6f" class="graf--p graf--first"><em class="markup--em markup--p-em">Note: Automatically optimising style re-use between components would be an amazing step forward, but it definitely requires help from people a lot smarter than me. Hopefully, that’s where you come in ☺</em></p>