Web ページ再構築の場合、CSS Zen Garden は、Web ページのレイアウトがテーブルから HTML + CSS に変更されたことを示します。長年にわたり、HTML5、CSS3、新しいテクノロジー、新しいプロパティなど、Web サイトがますます複雑になるにつれて、ますます多くの開発者が CSS スキルの向上を考え、試み始めています。では、どこから始めましょうか? Web ページの再構築作業では、どのような開発習慣を身につけるべきでしょうか?不適切な CSS の使用法とは何ですか?この悪いCSSをどうすればよいでしょうか。今日の記事では、避けるべき CSS の 10 の悪い使用方法について説明します。もちろん、正しい使用方法も紹介します。
誰でも理解しやすいように、これら 10 の悪い使用法を、重さ、ワークフロー、独善性の 3 つの主要なカテゴリに分類しました。
いわゆるマシュー効果として、悪い CSS を書くと、この悪いコードの悪い点は、さらに悪いコードが生成されることです。 CSS のバグを解決する必要があり、唯一の解決策が次のとおりであることが判明した場合: より多くのレベルのセレクター、ID セレクターを使用するか、さらに悪いことに、最後のキラーまでインライン スタイル (inline-style) を使用します。上記の使用法はすべて、最終的には「過剰な重量」というエラーにつながります。
CSS の重みは、特定の CSS ルールの使用方法によって異なります。
#layout #header #title .logo a { display: block; }
上記の CSS セレクターの文字列を見ると、これはセマンティックであり、シンプルで明確な「優れた」セレクターであると思われるかもしれません。左から右に読むことに慣れている場合は、次のように理解できるかもしれません。「まずメイン レイアウト領域を見つけ、次にヘッダー領域を見つけ、次にタイトル領域を見つけ、次にロゴ領域を見つけ、次にすべてのレイアウト領域を見つけます」その中のアンカー「ポイント」。CSS の場合、これは非常に具体的で正確な位置決めですが、実際には、そのような正確な位置決めが必要になる機会はほとんどありません。 CSS を過度に重視すると、スタイル シートの保守がより困難になり (あなたのシフトを引き継ぐ同僚の気持ちを考えたことがありますか!)、さらに読みにくくなり、理解しにくくなります (これほど多くの宣言とレイヤーを重ねて何をしているのでしょう)長いリスト）？ 01. ID の悪用 CSS の重みは、使用するセレクターの種類 (ID、クラス、タグ) によって異なります。例:
#my-link{color: red}.my-link{color: yellow}a{ colour: blue}このような小さなテストを行うには、次のようなハイパーリンクがあります。他のスタイルを定義しない場合、ブラウザによってレンダリングされる最終結果は何色になるでしょうか。
<a href="#" id="my-link" class="my-link">举个栗子</a>
ID 属性の重みが 3 つの中で最も高いため (ID は Web ページ内で 1 回のみ使用でき、その重み値は 100)、最終的な色は赤になります。他の人形は栗を抱えて勝利しました。
CSS の重みによると、上記のインスペクターでわかるように、id の隣の重みは class クラスであり、最後に tag タグです。
もちろん、上で挙げたような「id/calss/tag を同時に使用する」という状況は、実際のアプリケーションではまだ稀ですが、日常の開発では、次のような状況に遭遇することがよくあります。これは私たちのプロジェクトの 1 つで、ヘッダーにボーダーレスになるようにリンクを設定することにしました。
#header a { border:2px dashed #000 }次に、HTML クラスに特別なリンクを追加しました。これで問題は解決しましたか? 答えはいいえだ！ id の重みが非常に高いため、ニーズを達成するにはより重みの高い宣言が必要です。正しい書き方は次のとおりです:
.special-link { border:none }
この状況がコードプロセスで発生し続けるとします。ヘッダー領域に別の特別なハイパーリンクリンクを特別なスタイルに設定する場合、どのように対処すればよいでしょうか? ? ID の重要性が高いということは、ID の悪用は間違いなく悪い考えであることを意味します。
では、この問題をどうやって解決すればよいでしょうか? ID の代わりにクラスを使用します。
#header .special-link { border: none }上記の例は ID がごちゃごちゃしているだけでなく、ID をいじることによって引き起こされる高重量の問題と同じように、非常に長くなる場合もあります。セレクターの大きなリスト (3 レベル以上) 作成するウェイトが多すぎると、大量のウェイトが大量に存在することになります。
では、この問題を簡単に解決するにはどうすればよいでしょうか?現在の栗のように、.logo クラスでニーズを解決できるのであれば、それほど長い文字列を記述する必要はありません。一般的に、セレクターの数は最大でも 2 つまたは 3 つになるように制御する必要があります。
03.インラインスタイルインラインスタイルはCSSの重みの諸悪の根源であり、CSSを使用する本来の目的（構造スタイルの分離）を根本的に破壊するものでもあります。私たちのエンジニアがついにテーブルという魔法の洞窟から抜け出し、外部スタイルシートを受け入れたとき、スタイルと構造を混同してはならないことを知っていたはずです。
根据 css 权重级的特性，内联样式只能被!important 所覆盖。一般来说，这就意味着，如果某猿使用了!important，他们更多是被逼的没办法才这么用(对应英文 reactive)，而不是想这么用(preoactive)。的确!important在 css 样式表中用起来十分方便，但我们最好是聪明地、小心翼翼地碰她、用他，而不是把他当做救命稻草(救命稻草用多了，迟早也会从救命稻草变成压死骆驼的稻草)。
下面举例怎么解决内联样式的问题，就两步 1.复制删除 2.粘贴 。剔除内联样式，转移到样式表之中吧。
04.从上至下式的粗放命名说完 css 权重，接下来我们来谈谈其他 CSS 的糟糕用法。假设我们开始了一个新项目，设计师丢给我们一份 psd，我们开始在 html 中写基本的框架。
根据结构从下至上式的命名方式模糊化了 html 结构，工程师常常根据上下结构来命名id 和 class，而不是具体的设计元素，例如#header,content，这常常会导致长选择器(举个例子如. menu ul li a｛ ｝)，这样的后果是我们的代码变得难以调试和维护。怎么解决这个问题呢？我们应该尝试从网页中分离出设计元素，这同样可以减少我们代码中的冗余。
05.冗余/重复冗余意味着你写 css 的过程中不断重复某些代码。在使用编程语言的时候， 我们很好理解重复(造轮子)意味着浪费时间，我们在 code 中应该遵循 DRY 原则(Don’t repeat yourself)。什么情况下我们会重复造轮子呢？举个栗子：
.some-title { font-weight: bold; }.some-other-title { font-weight: bold; color: red }实际上，我们可以有个更好的解决办法
.some-title, .some-other-title { font-weight: bold; }.some-other-title { color: red; }比如说我们要添加一个不同颜色的标题，我们可以使用一个常用的命名，或者添加一个具体的 class 类。
<h3 class="some-title pop">我的标题/h3>
这个有点面向对象的CSS的思想在里面，使用 Sass 中的 @extend 特性可以很好地解决我们这个问题。
在 Sass 之中，你可以使用@extend 继承选择器，被继承的选择器的样式也被继承。这个特性使得我们可以很方便管理不同的样式，举个栗子：
.some-title { font-weight: bold; }.some-other-title { @extend .some-title; color: red; }当CSS预处理编译器将.scss转换成.css文件时，我们最终输出的样式是：
.some-title, .some-other-title { font-weight: bold; }.some-other-title { color: red; }最终输出的是一模一样的效果，解决重复和冗余的问题，要求我们在写 css 的时候心中对 html 层级结构要有个大致的规划，思考不同的设计元素之间的层级和关系，我们规划得越清晰，最终输出的 css 也越精简。
06.精简你的单位如果你的样式表中混杂着 px,em,rem等等单位，是时候改变了，业内著名的web开发者Rachel Nabors 呼吁大家统一使用em为字体大小单位，他曾说「我看其他人的样式表第一件事就是看字体样式，然后把所有的font-size的单位换成em」，这几年用户使用的终端越来越多样(不同的终端、不同的浏览器使用的默认字体大小存在差异)，使用绝对字体大小px变得越来越不可控，使用em等相对大小的字体则避免了这个问题。
如果你想在转成em对这些单位有个深入点的了解，推荐你阅读《CSS文字大小单位PX、EM、PT》。
当然，如果你就是不喜欢em和他们嵌套特性，那么你可以更进一步了解 CSS3 中推出的新单位rem。
不同单位在 web 设计之中的战争还在继续(可参考文章CSS Font-Size: em vs. px vs. pt vs. percent
)，学习一点相关知识对我们提高代码可维护性至关重要。
下面我们进入到这篇博文的第三也是最后一个部分「自以为是」，这些坏习惯包括：增加不必要的东西，错误，无意义的 css。
07.向下兼容和无效的规则在开发的过程中，如果你不需要使用 css3 之类的高大上代码就能实现效果，那再好不过了。可是，作为工程师的你在 Chrome 最新版本上面看到的效果，并不意味着你的用户能在他们的浏览器上看到同样的效果(考虑过 IE 的感受没有)，一个十分糟糕的坏习惯就是完全忽略向下兼容性。
如果你在项目中使用rgba()，你是否测试过这个属性的兼容性？如果没有，那你最好祈祷没有 IE8的用户会访问你的网站。你是否写全了针对不同浏览器的不同的规则(-webkit,-ms -moz 等等)？解决这个问题，可以使用 CSS LInt检测下你的 css 代码，CSS Lint的检测规则包括错误的和不合理的地方。
08.(没有意义)不起作用的样式Harry Roberts的Code smells in CSS是关于 css 糟糕用法的经典文章。他举了几个可有可无的不起作用样式的栗子：
h2{font-size:2em;margin-bottom:0.5em;padding-bottom:0.5em;border-bottom:1px solid #ccc;}.no-border{padding-bottom:0;border-bottom:none;}Roberts 推荐的重构精简方法是删掉属性为0和none的属性值。
h2{font-size:2em;margin-bottom:0.5em;}.headline{padding-bottom:0.5em;border-bottom:1px solid #ccc;}如果你像重构之前的那样写法，h2是一个我们在web 设计中会不断重复用到的元素，这个本质上「你写了更多的代码却没有实现了更少的样式效果」，如果我们接下来又要设置一个h2的属性为其他样式，那代码会得很乱。
Harry Roberts是 inuit.css 框架的作者。
09.巧而不巧:用 Hack 不意味着你是个好 Hacker负的 margin 边距，!important等等，上面的这些就是我们所说的 hack 用法(此 hack 非针对IE 兼容的 hack，也可以理解成 cheater 作*弊*用法)，如果其他人问我们为什么要这么写？我们可能只需要回答「管他呢，反正能实现效果」。
当我们为自己使用这些充满「弊」端的方法而略不放心的时候，一个解决办法就是把我们的这些 hack 放到一个特定的样式表文件hack.css之中。
任何时候你意识到你写了一个 css 的 hack 用法的时候，你直接把这些代码放到这个hack.css 之中(或者样式表的特定区域：通过注释跟其他样式区分开)，这个专属区域是个好解决方案因为他最终会在用户端隐藏。
当我们养成了这个习惯，我们可以十分清晰地知道我们写了哪些 hack ，同样可以方便我们了解我们使用这些 hack 的情景，让我们可以知道如何避免这些 hack 。我们有许多写 hack 用法的理由，但是如果我们不记录我们为什么 hack，我们将不会从我们这些 hack 中学到我们为什么要错误地这么用。
10.糟糕的文档和注释昨天在微博上看到一个段子「程序员最讨厌的四件事：写注释、写文档、别人不写注释、别人不写文档 …」。
写文档和注释绝对不是一个有意思的事情，但却是一个最重要的事情(尤其是涉及到项目后续可维护性时)，文档可以有效地让其他人知道你的代码是干什么的，同时其他人理解你的 css。对于大部分语言(html,css,php,JavaScript) ，开发者可以直接在代码文件中写上注释(文档)。
Nabors 曾说「我曾YY：如果我今天写完一个项目的 css 但是明儿我却挂掉了，有一个人幸运地接手我这个项目，那他看得懂我的这些代码是什么意思吗？」。尽量地让我们的样式表中的结构清晰，如果不能让人立马知道你的选择器指的是哪里的样式，可以尝试添加注释(什么！你还说注释增加css 文件大小！难道你不知道压缩工具么！)。
第一步是在必须的地方做好注释，第二步是使用工具把css文件中的这些注释转换成一个合适的文档。推荐可以使用css_doc和KSS。
css_doc 跟 JavaDoc类似，他的转换原理基于 CSSDOC. KSS(Knyle Style Sheets)，对于前端和设计师来说都十分有益。
在这篇文章中，我们介绍了一些常见的 css 糟糕用法，指出了为什么我们应该避免这些用法和应该使用什么正确的用法。还是这句话”Doin something is always better than nothing”，行动起来总比什么都不做要好点，未雨绸缪有备无患。
今天你看完这篇文章，知道了10个糟糕的 CSS 用法，这不意味着你明儿去上班就把你过去所有的代码都重构一遍。从点滴开始，一步一步来才是我们开发工作的正确做法。在接下来的工作中，注意这些细节，避免这些「小」错误，让我们的代码更漂亮点。终有一天，我们会发现”Code is poetry”。
本文章转载自http://www.creativebloq.com/css3/avoid-css-mistakes-10135080
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
