当你讨厌 CSS 时如何编写 CSS
从 Cee-Ess-Ess 到 Cee-Ess-YES！
我讨厌 CSS。
好吧，我讨厌CSS。在学习编写代码时，CSS 似乎是一个无法操作的黑匣子。决定某物应该是什么样子的双重任务，然后使它看起来像这样似乎是不可能的。这很自然地导致了对整个艺术的根深蒂固的仇恨。
然而，事实证明，很多厌恶源于没有适当的流程来构建和编写良好的 CSS 规则。当我在从头开始构建应用程序和跳入已经建立的代码库之间移动时，我开始编译一小部分，不是规则本身，而是工作的东西，你知道，就像有规则一样但对我们这些反独裁者有好处。有一天，我进入工作，并意识到，我真的很为火上浇油我有我的待办事项列表那天的任务......和他们所有的CSS。
我的猫，埃利斯，脸上带着震惊和惊讶的表情
震惊。敬畏。轻度至中度恐怖。以手工构建的组件的名义，这是如何发生的？
事实证明，CSS 最终就像任何其他类型的编程一样。它首先是一个问题分解的任务，一旦你有了一组整洁的离散待办事项，它就像任何其他类型的编程一样令人满意和令人愉快（与我战斗，互联网）。
下面是编写有效 CSS 的标准和实践的集合。这远不是唯一的方法——如果你只从这篇文章中删除一件事，希望拥有一个系统比拥有这个系统更重要，但如果你没有系统，这是一个不错的起点。只有四个相当简单的指南，你也可以比现在更讨厌 CSS。
1. 类是为了样式。
标签用于语义，ID 用于引用。
我编写的每条 CSS 规则都与一个类相关联，理想情况下，只与一个类相关联。从一开始，这意味着当我查看我的文档并试图理解它为什么看起来如此时，我确切地知道从哪里开始追踪适用的 CSS 规则，并且它有助于最大限度地减少与不可预测的结果和意大利面的冲突代码。
这是保持我的 CSS 整洁和组织良好的关键，它对任何应用它作为原则的应用程序的可用性都有很大的回报。这种回报是一个很好的老编码最爱：关注点分离。在这种情况下，将视觉表现与语义分离。
如果你正在正确地编写 HTML（或者，让我们说实话，你的 JSX，因为现在谁在编写 HTML），你<div />的代码库中可能没有大量的s - 为什么<div>在可以的时候使用一个普通的旧的有一个<article>或一个<form>或一个<nav>或一个<footer>？（或一个<main>？你不会忘记在你的页面视图中添加适当的地标，对吗？）而且可能很想在这些元素上设置样式，特别是如果你认为，“好吧，嘿，我们可能希望我们所有的菜单都保持一致，不是吗？”
但是编写好的语义 HTML 意味着您根据元素在页面中的功能及其内容的含义来选择元素，而不是基于您希望它们的外观。An<h1>是您视图中最重要的上下文，而不是“您想要大的文本和风格化的标牌字体”。虽然很多时候，这两个关注点会一起流动，偶尔它们会发散，如果你已经在上面写了你的风格<h1>，那么你有两个选择：
- 您可以编写一些额外的 CSS 规则，以便您拥有
<h1 class="special-not-big-h1">（或更糟的是，<h1 id="special-not-big-h1">这确实会导致一些心痛），从而增加代码库的复杂性并降低其可读性。（哪个，如果你做一次，不会有这样的问题，但我们都知道这些小技巧和特殊情况开始加起来有多快，不是吗？） - 您可以决定不
<h1>为该视图的重要内容使用 ，从而让使用屏幕阅读器或其他辅助技术的人对您的页面层次结构一无所知。那真的很糟糕。
然而，如果您没有让<h1>'s 作为语义元素和样式器承担双重职责，那么您所要做的就是不要将该特定类添加到特殊情况元素中。那不是更容易吗？和更清洁？
这里的重点是打破“语义元素”和“视觉风格”之间的心理联系。如果你想要的是“大文本”，把它放在你的 css 中，不要去寻找一个不一定属于那里的元素。
2. BEM 将阻止对元素的修改成为可认证的垃圾火（CSS 的 CTF 范式）
BEM 代表“块、元素、修饰符”，是一组有助于保持 CSS 组织有序的命名约定。有相当多的命名约定系统，没有一种是适合所有情况和项目的最佳选择——就像一般的 CSS 系统一样，拥有一个比拥有任何特定的系统更重要。但是 BEM 非常方便，我认为它是开始各种应用程序的好地方（部分原因是它众所周知，因此向将来加入您项目的新开发人员解释并不难），所以让我们谈谈它是什么，为什么它很棒。
BEM 将我们的 CSS 规则分为三类，它们为如何将视觉样式应用于您的 html 提供了逻辑。BEM 鼓励您考虑视图的整个结构，并相应地分解您的样式，而不是将每个视觉需求作为一项独立的任务。无论您将 CSS 存储在何处，您的所有规则都应分为这三个部分（按层次或按字母顺序组织，只要对您的团队有意义）。
- 块：块是代码中的独立实体，它们完全独立地包含含义。很好的例子是标题、输入、菜单、复选框等。块本质上包含它自己的所有规则，而不依赖或引用父元素。块类的定义没有下划线或连字符，并使用驼峰式大小写来分隔不同的单词，例如：
.button,.mainNav,.orderedList。（经常，您会看到 BEM 中使用单个连字符来分隔块中的单词，因为这是 BEM 之外更常见的 CSS 约定，但我个人认为它会导致元素和修饰符命名的视觉混乱，并添加错别字的可能性）。 - 元素：元素是块的组成部分，它们的名称应该在语义上与其父块相关联。它们不能作为独立的部分工作——我们谈论的是导航链接、列表项或输入标题之类的东西。元素以它们的父块命名，后跟它们自己的描述性名称，用两个下划线分隔：
.mainNav__link,.orderedList__item,.checkbox__caption。 - 修饰符：修饰符是可以放在块或元素上的标志，用于更改特定项目的外观或行为（通常，这些是您的特殊情况，必须区别对待颜色、大小或位置）。：修饰符是通过附加两个连字符，然后一个描述性名称的块或元件中而得名
.button--danger，.orderedList__item--last，.list--collapsed，等等。修饰符也是我将伪类的样式规则分组的地方，因为它们本质上就是这样。
起初我很难真正看到这个系统的效用，直到我接受了一个现有的项目并将其迁移到 BEM 惯例。我构建的下一个功能/视图集比之前的要顺利得多，我完全被打倒了。
3. 可访问性是一个很好的设计指南
有时，我知道这很难相信，但请耐心等待，您编写的代码没有高保真、功能齐全的线框图。有时，您的平面设计师很烂，或者根本不存在，或者正在做 1200 万个其他项目，而这不是您日常工作流程的一部分。越来越多的时候，前端和全栈 Web 开发人员被期望，至少部分地，做一个设计师的工作。
因此，如果您正在尝试发展自己的审美，而您只是不知道从哪里开始，请首先考虑什么可以在视觉上使您的应用程序可用。而自然，当我说有用，我的意思是使用尽可能多的人越好，而不仅仅是当前身强力壮的人（这就是我们所说的话，右的人呢？）。
开发可访问的应用程序的好处在于，在大多数情况下，无论他们如何使用您的内容，它们都能为您的所有用户带来更好的体验。如果您不确定某样东西应该是什么样子，请开始考虑如何以适合尽可能多的人的方式设计它。确保行高至少为 1.5em，字体大小足够大，颜色对比度为 4.5:1 或更高，并且行长度限制为每行 80 个字符或更少。并且绝对不要单独使用颜色来向您的用户传达重要信息（特别是，尤其不要使用红色与绿色）。
真正的可访问性超出了本文的范围，但我鼓励任何编写代码的人，尤其是接触 UI 的代码，了解更多相关信息，并积极倡导团队中可用的、可访问的设计。Deque为任何有网络连接的人（并为任何残障人士提供全额奖学金）提供非凡的在线课程，万维网联盟 (W3C) 有一份关于如何满足不同级别的可访问性标准的清单，用于没有 Deque 资源的人，或者只需要进行快速参考检查的人。即使你这样做 在每一步都有一位设计师与您合作，他们可能对无障碍设计的了解比您多，而了解幕后情况的人的声音可能很重要。
4. 唯一的好耻辱是 Shame.css
我希望我足够聪明，能够创造出 Shame.css 的短语和概念。唉，我没有，所以我必须首先赞扬并赞扬Harry Roberts，一个真正的 CSS 向导，他解释了什么是 Shame.css 以及为什么它在这里和这里如此方便。
但是让我和你谈谈我如何以及为什么在我的项目或我工作的项目中使用它。如果我告诉你我在 100% 的情况下始终如一地遵循了我在这里列出的所有原则，那我就是在撒谎（而且也不能令人信服）。有时，您只需要修改标题看起来像一百万次，而您不想进入并在所有标题上添加一个新类。有时你需要一些固定的东西现在-现在-现在**和干净的代码必须在功能上退居二线。有时，这是一个星期五的下午，你只是太累了，无法直接思考。不管是什么原因，有时你会用简单的方法而不是正确的方法来做。
这些事情发生了，如果我们假装它们没有发生，我们就会失去控制它们造成的破坏的机会。
输入， Shame.css：当你写了一些 hack-y 和粗糙的 CSS 时，拥有它。把它放在自己特殊的CSS文件（或者仅仅沿着第四部分/* blocks */，/* elements */以及/* modifiers */-有/* FIX THIS SHIT ASAP */部分太）。现在您的代码正在运行，但您已采取措施确保未来 - 您不会在未来处理一团糟的糟糕风格。
Shame.css 的关键（只是为了记录，在我自己的代码中，我通常称它为“to-fix.css”或“hacks.css”，只是为了不那么消极和责备它），现在是，你的工作流程的一部分必须回到那个文件，并实际上理顺你以安静生活的名义犯下的任何 CSS 错误。理想情况下，您应该在下一次情绪低落时立即着手解决，但由于这些很难有机地实现，我喜欢正式安排时间不少于每周一次。周一早上实际上可能是一个很好的时间——这是一个很好的方式来放松一周，获得一些不太难的、有道德感的胜利，不需要大量的决策。
每当你这样做时，只要确保你做到了，否则，你并没有降低复杂性，你只是忽略了你自己的系统。
和往常一样，我想听听您认为我哪里错了，您认为我遗漏了什么，以及您将如何做得更好。怎么你开始恨CSS少？怎么你开始写更好呢？
