CSS selectors all exist within the same global scope.\u00a0Anyone who has worked with CSS long enough has had to come to terms with its aggressively global nature\u200a\u2014\u200aa model clearly designed in the age of documents, now struggling to offer a sane working environment for today\u2019s modern web applications.\u00a0Every selector has the potential to have unintended side effects by targeting unwanted elements or clashing with other selectors. More surprisingly, our selectors may even lose out in the global specificity war, ultimately having little or no effect on the page at all.<\/p>\n
Any time we make a change to a CSS file, we need to carefully consider the global environment in which our styles will sit. No other front end technology requires so much discipline just to keep the code at a minimum level of maintainability.\u00a0But it doesn\u2019t have to be this way.\u00a0It\u2019s time to leave the era of global style sheets behind.<\/p>\n
It\u2019s time for local CSS.<\/em><\/p>\n In other languages, it\u2019s accepted that modifying the global environment<\/strong> is something to be done rarely, if ever.<\/p><\/blockquote>\n In the JavaScript community, thanks to tools like Browserify, Webpack and JSPM, it\u2019s now expected that our code will consist of small modules, each encapsulating their explicit dependencies, exporting a minimal API.<\/p>\n Yet, somehow, CSS still seems to be getting a free pass.<\/p>\n Many of us\u200a\u2014\u200amyself included, until recently\u200a\u2014\u200ahave been working with CSS so long that we don\u2019t see the lack of local scope as a problem that we can solve without significant help from browser vendors. Even then, we\u2019d still need to wait for the majority of our users to be using a browser with proper Shadow DOM support.<\/p>\n We\u2019ve worked around the issues of global scope with a series of naming conventions like OOCSS<\/strong>, SMACSS<\/strong>, BEM<\/strong> and SUIT<\/strong>, each providing a way for us to avoid naming collisions and emulate sane scoping rules.<\/p>\n We no longer need to add lengthy prefixes to all of our selectors to simulate scoping. More components could define their own foo and bar identifiers which\u200a\u2014\u200aunlike the traditional global selector model\u2014wouldn\u2019t produce any naming collisions.<\/p>\n The benefits of global CSS\u200a\u2014\u200astyle re-use between components via utility classes, etc.\u200a\u2014\u200aare 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\u2019t make many, if any, assumptions about the global environment.<\/p>\n Writing maintainable CSS is now encouraged, not by careful adherence to a naming convention<\/strong>, but by style encapsulation during development.<\/p><\/blockquote>\n Once you\u2019ve tried working with local CSS, there\u2019s really no going back. Experiencing true local scope in our style sheets\u200a\u2014\u200ain a way that works across all browsers\u2014 is not something to be easily ignored.<\/p>\n 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\u2019re only at the beginning of this new era of local CSS.<\/p>\n Understanding the ramifications of this shift is something that we\u2019re still working through. With your valuable input and experimentation, I\u2019m hoping that this is a conversation we can have together as a larger community.<\/p>\n 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. <\/em><\/p>\n","protected":false},"excerpt":{"rendered":" Every selector has the potential to have unintended side effects by targeting unwanted elements or clashing with other selectors. More surprisingly, our selectors may even lose out in the global specificity war, ultimately having little or no effect on the page at all. Any time we make a change to a CSS file, we need to carefully consider the global environment in which our styles will sit. No other front end technology requires so much discipline just to keep the code at a minimum level of maintainability.<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":"","_links_to":"","_links_to_target":""},"categories":[20],"tags":[22,25,27,30],"class_list":["post-4229","post","type-post","status-publish","format-standard","hentry","category-business","tag-travel","tag-tech","tag-life","tag-sport"],"yoast_head":"\nimport<\/strong> styles from<\/strong> '.\/MyComponent.css';\nimport<\/strong> React, { Component } from<\/strong> 'react';\nexport default class<\/strong> MyComponent extends<\/strong> Component {\n render<\/strong>() {\n return (\n <div>\n <div className={styles.foo<\/strong>}>Foo<\/strong><\/div>\n <div className={styles.bar<\/strong>}>Bar<\/strong><\/div>\n <\/div>\n );\n }<\/pre>\nprocess.env.NODE_ENV === 'development' ?\n '[name]__[local]___[hash:base64:5]<\/strong>' :\n '[hash:base64:5]'\n<\/strong>)<\/pre>\n