css css2 css3_如何编写真正糟糕CSS

css css2 css3

Everyone talks about ‘tips’ and ‘pro-tips’ for writing great CSS.

每个人都在谈论编写出色CSS的“技巧”和“专业技巧”。

That’s fine, but maybe seeing what bad CSS looks like will give you a different perspective. Heck, it may even do you some good!

很好，但是也许看到不良CSS外观会给您带来不同的看法。哎呀，它甚至对你有好处！

Let me take you through a journey on how to write really bad CSS.

让我带您了解如何编写非常糟糕CSS。

Ready?

准备？

Note: even if you swear by CSS-in-JS and do not love vanilla CSS, we all agree on thing: we all still have to know some CSS…

注意：即使您对CSS-in-JS宣誓就职并且不喜欢香草CSS，我们都同意这一点：我们仍然都必须了解一些CSS ...

So, whether you write CSS, or some superset such as SASS, or just CSS-in-JS, you will still benefit from knowing exactly what bad CSS looks like.

因此，无论您是编写CSS还是编写诸如SASS之类的超集，或者只是编写CSS -in-JS ，您仍将受益于确切了解不良CSS的外观。

谁写评论？没有人。 (Who Writes Comments? No one.)

It’s so easy to slip here that you won’t notice very quickly.

滑到这里很容易，您不会很快注意到。

We all know it. You’re so smart, everyone else doesn’t come close. Even though CSS isn’t the most expressive of “languages”, you can make assumptions about browser quirks, fix them, and assume you’ll understand what you’ve done few weeks down the line.

我们都知道。你真聪明，其他人都不是很接近。即使CSS并不是“语言”中最具表现力的，您也可以对浏览器的怪癖做出假设，加以修正，并假设您将了解几周后所做的工作。

How smart, huh?

多么聪明吧？

Put your pride aside, and save yourself and other teammates the stress.

放下自豪感，节省自己和其他队友的压力。

If you’re using a not-so-obvious technique, or have fixed some browser quirk, or anything at all you think isn’t expressive enough, write that comment! It doesn’t hurt.

如果您使用的不是很明显的技术，或者已解决了一些浏览器怪癖，或者您认为根本无法表达的任何内容，请写评论！没伤

复杂选择器之地 (The Land of Complex Selectors)

Yeah! You just learned CSS and feel on top of the world. So, time to show off some selector muscles.

是的您刚刚学习了CSS，就可以身处世界之巅。因此，该展示一些选择器肌肉了。

Bad move.

不好的举动。

By making selections with too many CSS selectors, you may have successfully made your CSS extremely unmaintainable. It is now highly dependent on the HTML structure of your app.

通过使用过多CSS选择器进行选择，您可能已经成功地使CSS极难维护。现在，它高度依赖于应用程序HTML结构。

If the structure of the markup changes slightly, you need to go refactor your CSS as well. Not the easiest of workflows.

如果标记的结构稍有变化，则还需要重构CSS。这不是最简单的工作流程。

Just add a class to the element and get on with life!

只需在元素上添加类，然后继续生活！

Even in scenarios where you need to qualify selectors with multiple classes, always favour simplicity.

即使在需要使用多个类限定选择器的场景中，也始终倾向于简化。

Simple is good, almost always!

简单就是好，几乎总是如此！

性能？沟那个！ (Performance? Ditch That!)

So, I get it. You just don’t care about performance. You don’t care about the business, clearly. If you did, you wouldn’t annoy your users with your terrible non-performant selectors.

所以，我明白了。您只是不关心性能。显然，您并不关心公司。如果这样做，您将不会因可怕的性能不佳的选择器而惹恼您的用户。

But wait…

可是等等…

I understand that computers have grown faster and browsers continue to be optimised. Regardless, simple selectors should always be preferred, and understanding how the browser traverses the DOM to find your selector is still a thing!

我了解计算机的增长速度越来越快，浏览器也在不断优化。无论如何，始终应该首选简单的选择器，并且了解浏览器如何遍历DOM来找到您的选择器仍然是一件事情！

Chances are, you read through your selectors from left to right.

您很可能会从左到右通读选择器。

However, the browser matches the selectors from right to left, so it can eliminate elements that don’t match as quickly as possible.

但是，浏览器从右到左匹配选择器，因此它可以尽快消除不匹配的元素。

If you knew this, you’d probably be more lenient on the browsers. They deserve your love.

如果您知道这一点，则可能会对浏览器更为宽容。他们应该得到你的爱。

Considering the example graphic above, the browser will match all elements (*) and also check if they are descendants of body.

考虑上面的示例图形，浏览器将匹配所有元素(*)，并检查它们是否是body后代。

body * {  ... }

But why? Almost every visible element is ideally a descendant of the <body> element. That’s just a needless inefficient check.

但为什么？理想情况下，几乎每个可见元素都是<bo dy>元素的后代。那只是不必要的低效检查。

我吮吸命名的东西，所以我什至不打扰。 (I Suck at Naming Things, so I don’t even bother.)

There are only 2 hard things in computer science. Naming things and …

在计算机科学中只有两件难事。命名事物并…

Yeah, I think you already heard that somewhere. Naming things can be hard, but that doesn’t mean you shouldn’t give them some thought, or go completely cryptic.

是的，我想您已经在某处听到了。命名可能很困难，但这并不意味着您不应该给他们一些想法，也不应该完全保密。

I doubt there’s any situation where it makes sense to use single letters as class names.

我怀疑在任何情况下都可以使用单个字母作为类名。

.u {  font-size: 60rem;}

And what about super-specific class names?

那么超级特定的类名呢？

.former-black-now-red-paragraph {  color: red;}

Those don’t do any good, either.

那些也没有任何好处。

While the name may seem to convey some meaning, you very likely have broken a huge part of the class’s re-usability. Which, by the way, is the primary reason for having classes.

尽管该名称似乎传达了一些含义，但您很可能已经破坏了该类的可重用性的很大一部分。顺便说一下，这是拥有类的主要原因。

Now, if you wanted to style a regular red the paragraph, the previous name is just so specific, it wouldn’t make sense.

现在，如果您想为段落设置普通的red样式，则先前的名称是如此具体，因此没有任何意义。

Use meaningful names, but just don’t overdo it.

使用有意义的名称，但不要过度使用。

我听说课程很棒。过度使用它们！ (I Heard Classes were Great. Overuse them!)

Classes are great, and everyone loves them. But, as with everything else, too much of something is generally a bad idea.

课堂很棒，每个人都喜欢。但是，与其他所有内容一样，过多的内容通常不是一个好主意。

You see, if a group of classes will mostly be used together, just group them into one class.

您会看到，如果一组类将大部分一起使用，只需将它们分组为一个类即可。

When you choose to group these classes is perhaps subjective. If you’re building an atomic library of some sort, you may tend towards this.

选择分组时，这些可能是主观的。如果您要构建某种原子库，则可能会倾向于这样做。

If you’re writing a large app, you’re likely better off grouping classes in a meaningful way, as opposed to having a ton of classes on a single element.

如果您正在编写大型应用程序，则最好以有意义的方式对类进行分组，而不是在单个元素上创建大量类。

When possible, avoid over modularised classes.

尽可能避免过度模块化的类。

我是CSS纯粹主义者。我不做SASS，LESS等 (I am a CSS Purist. I don’t do SASS, LESS, etc.)

You’re a CSS purist, I’m a CSS purist, we’re both purists. Let’s get that out of the way.

您是CSS纯粹主义者，我是CSS纯粹主义者，我们都是纯粹主义者。让我们摆脱它。

Now, to the bone of contention.

现在，争论的焦点。

There are definitely use cases where just writing vanilla CSS is great! For example, if I’m not using a CSS-in-JS solution for my React projects, I could decide to go the pure CSS route. It doesn’t hurt.

在某些使用案例中，仅编写原始CSS就是一件好事！例如，如果我的React项目没有使用CSS-in-JS解决方案，那么我可以决定采用纯CSS路线。没伤

However, if you’re writing a large app with a ton of vanilla CSS flying around, I bet introducing a CSS preprocessor will make your development more interesting and contribute towards a more maintainable CSS codebase.

但是，如果您正在编写一个带有大量香草CSS的大型应用程序，那么我敢说引入CSS预处理程序将使您的开发更加有趣，并有助于建立更易于维护CSS代码库。

Again, I’m not saying use preprocessors every single time. I’m saying don’t just close out that option. It could save you!

同样，我并不是说每次都使用预处理器。我是说不要仅仅关闭该选项。这样可以救你！

您在那里有很多重要风格！ (You’ve got a lot of Important Style there!)

I hate CSS. It just never works. So, what’s the fix?

我讨厌CSS。它永远都行不通。那么，解决方法是什么？

Have a ton of !important all over the place when I need to override any declarations. Haha!

当我需要覆盖任何声明时，到处都有很多!important的信息!important 哈哈！

While this sounds like a decent plan to your lazy self, over-using the !important rule will only result in a grossly unmaintainable CSS document.

虽然这听起来像是您懒惰自己的一个不错的计划，但是过度使用!important规则只会导致CSS文档非常难以维护。

The next time you need to use !important, be sure you’re not doing so because you’re too lazy to fix your cascade issues.

下次需要使用!important ，请确保您没有这样做，因为您懒得解决级联问题。

CSS isn’t that bad. Embrace it.

CSS还不错。接受它。

想编写更好CSS吗？ (Want to write Better CSS?)

I have created a free CSS guide to get your CSS skills blazing, immediately. Get the free ebook.

我已经创建了一个免费CSS指南，可让您立即掌握CSS技能。获取免费的电子书。

翻译自: https://www.freecodecamp.org/news/how-to-write-truly-terrible-css-214c26c6f729/

css css2 css3