»更好的阅读体验
原文链接
所有的CSS选择器共享同一个全局作用域。
每个接触CSS足够长时间的人一定都对CSS全局特性感到困扰 - 这种在文档型网页时代设计出来的模式，面对当今的Web应用，想要提供良好的开发环境却未免显得乏力。
每个选择器都有可能带来意想不到的影响，比如指向不需要的元素或者与其他选择器产生冲突。更始料不及的是，选择器的权重甚至可能在全局作用域中败下阵来，导致样式在页面中发挥不了任何作用。
任何时候我们修改CSS文件，我们都需要小心翼翼地考虑这些样式在全局环境下的影响。没有任何一个前端技术是需要如此之多的规范，仅仅是为了保证代码最小程度的可维护性。
但这本不该如此。
是时候将全局样式抛之脑后。
是时候拥抱本地CSS。
其他语言中，全局环境下少量的永久性修改是可以被接受的。感谢JavaScript社区提供的这些工具， Browserify， Webpack和 JSPM，让我们的代码可以由一小块一小块的模块组合而成，这些模块中只需要明确指定它们的依赖，并且导出少量的API接口。
然而，不知为何，CSS似乎依旧无人问津。
我们中的许多人 - 包括我自己，直到现在 - 使用CSS太久了以至于我们觉得CSS缺失本地作用域是一个我们无法解决，只能等所有人都用上支持 Shadow DOM的浏览器才能解决的问题。
我们使用过一系列的命名规范来解决全局作用域的问题，比如 OOCSS， SMACSS， BEM和 SUIT，这些规范为我们提供了避免命名冲突的方法并提供了一套可用的作用域规则。
毫无疑问，这是迈向良性CSS的关键一步，但即便如此，这些规范都没有解决样式表的真正问题。无论我们选择使用哪种规范，我们还是会被全局选择器所困扰。
但2015年4月22日这天，一切都迎来改变。
正如我们不久前的博文 - “BEM 你的下一代JavaScript组件”- 中提到的，我们可以使用 Webpack在JavaScript模块中导入CSS。如果这对于你来说不太熟悉，你最好先阅读 这篇文章，不然你可能会忽略接下来介绍的关键点。
使用Webpack的 css-loader加载器，像这样导入组件的CSS：
require('./MyComponent.css'); 乍一看 - 即使没注意到我们导入的是CSS而不是JavaScript - 这行代码也显得相当奇怪。
通常，require调用会给当前的作用域提供一些东西。如果没有，这很可能是引入了影响全局的模块 - 通常这都是糟糕的设计。
但这是CSS - 全局的影响是必须的。
至少我们是这么认为的。
在 2015年4月22日， Tobias Koppers- 永不知疲惫的Webpack作者 - 为css-loader加载器一个新功能的提交了第一个迭代版本，当时该功能名叫placeholders，就是现在众所周知的 local scope。
这个功能让我们能够从CSS文件中把类名导入到JavaScript代码中。
简单来说，不这么写：
require('./MyComponent.css'); 而是这么写：
import styles form './MyComponent.css';
那么，这个例子中，styles变量到底等于什么？
为了了解CSS文件到底 输出了什么，让我们来看看样式表的写法：
:local(.foo) { color: red;}:local(.bar) { color: blue;} 上述代码中，我们使用css-loader加载器的特定语法 :local(.identifier) 输出了两个标识 - foo和bar。
我们可以在JavaScript文件中使用这些标识对应的类名。例如，我们使用 React：
import styles from './MyComponent.css';import React, { Component } from 'react';export default class MyComponent extends Component { render() { return (
Foo
查看更多关于全局CSS的终结_html/css_WEB-ITnose的详细内容...
声明：本文来自网络，不代表【好得很程序员自学网】立场，转载请注明出处：http://www.haodehen.cn/did112249