acss码表_如何使用ACSS在团队中编写更好CSS —动态Atomic CSS库

acss码表

by kushagra gour

由kushagra gour

如何使用ACSS在团队中编写更好CSS —动态Atomic CSS库 (How to write better CSS in teams with ACSS — A dynamic Atomic CSS library)

Writing good Cascading Style Sheets (CSS) is difficult and it becomes more difficult in a team where multiple developers write CSS.

编写好的级联样式表(CSS)十分困难，并且在由多个开发人员编写CSS的团队中变得更加困难。

Through this article, I attempt to introduce you to an approach to writing (or not writing…we’ll see) CSS. This approach solves almost all the issues one faces today with poorly written CSS in teams.

通过本文，我试图向您介绍一种编写(或不编写……我们将会看到)CSS的方法。 这种方法解决了团队编写CSS较差的当今几乎所有问题。

But first, let me set down some base conditions on which my article holds true.

但首先，让我为我的文章确定一些基本条件。

本文假设一些条件： (A few conditions this article assumes:)

1. You are working in a team where multiple developers write CSS.
   您正在一个由多个开发人员编写CSS的团队中工作。
2. Guidelines are hard to enforce unless there are automated tools.
   除非有自动化工具，否则很难执行准则。
3. Designers are free birds. Redesigns happen.
   设计师是自由鸟。 重新设计。

Under these conditions, I am going to present a silver bullet solution that solves almost all the problems we face due to bad CSS (Remember, CSS isn’t bad. Badly written CSS is). Let’s go through those problems to start with.

在这种情况下， 我将提出一个解决方案，该解决方案将解决由于CSS不良而引起的几乎所有问题 (请记住，CSS不错，而CSS则写得不好)。 让我们首先解决这些问题。

Disclaimer: I am not, in any way, an affiliate of the solution described in this article. I am just a developer who has felt the pain of bad CSS in a team and wants to share with fellow developers, my thoughts on how to overcome that. This article may sound promotional, but it is just because I am very excited to bring this forth everyone.

免责声明 ：无论如何，我不是本文描述的解决方案的分支机构。 我只是一个开发人员，曾在团队中感觉到CSS不好的痛苦，并想与其他开发人员分享我对如何克服这一问题的想法。 这篇文章听起来听起来很促销，但这只是因为我很高兴将大家提出来。

问题1：命名类很困难 (Problem 1: Naming classes is difficult)

Developer 1 (while coding): Looks like a header to me, let me use .headerselector for it.

开发人员1(在编码时) ：对我来说似乎是标头，让我使用.header选择器。

Developer 2 (in the pull request): This isn’t a header. It looks like a title to me. Moreover, we cannot call it just ‘header’ as that element isn’t generic enough. Let’s call it .panel-header or better .panel-title .

开发人员2(在请求请求中) ： 他不是标题。 对我来说，这似乎是标题。 而且，我们不能称其为“ header”，因为该元素不够通用。 我们称它为.panel-header或更好的.panel-title 。

Coming up with names and that are also meaningful names is the most difficult problem to solve. It is also the most difficult apsect to learn because you cannot have guidelines for what is a “meaningful” name. You can only give examples of what is not meaningful, and that can only help so far. Additionally, it’s not just about ‘being meaningful’. Classes in CSS also need to ensure they don’t conflict with other class names in future as a new developer may use the same or similar name for his class.

提出名字也是有意义的名字是最难解决的问题。 这也是最难学的学问，因为您没有关于“有意义”名称的指导。 您只能给出无意义的示例，而这仅能提供帮助。 此外，这不只是“有意义”。 CSS中的类还需要确保将来不会与其他类名冲突，因为新开发人员可能为其类使用相同或相似的名称。

可用的解决方案： (Solutions available:)

• BEM — naming conventions like BEM exist to solve this problem to some extent. But in the end it’s a guideline (we all know how easy it is to follow guidelines). BEM might prevent you from going completely ad-hoc but you still need to come up with an initial class name for your components.

  BEM -像BEM命名约定存在解决这个问题在一定程度上。 但是最后这只是一个准则(我们都知道遵循准则是多么容易)。 BEM可能会阻止您完全即席使用，但是您仍然需要为组件提供一个初始类名。

• Atomic classes — another common approach these days to go completely atomic with atomic classes. Small classes that do just one thing. Eg. Tachyons. Mix and match them to get what you need. This is a good step towards “skipping naming” altogether, but what if in future there exists no class for a particular thing? How do I customize existing atomic classes according to my design? Do all classes always load on my page whether or not I use them? We need something more.

  原子类 -如今，将原子类完全变为原子的另一种常用方法。 小类只做一件事。 例如。 快球 。 混合并匹配它们以获得您所需要的。 这是迈向“跳过命名”的一个很好的步骤，但是如果将来没有针对某个特定事物的类怎么办？ 如何根据设计自定义现有的原子类？ 是否所有类都始终加载到我的页面上？ 我们还需要更多。

问题2：选择器优势 (Problem 2: Selector strengths)

Another thing CSS developers need to be constantly aware of is that the specificity in their CSS doesn’t go haywire. If you have long complex selectors, your CSS becomes unpredictable and difficult to maintain and debug.Harry Roberts has written a lot of articles on why that is bad and what you can do to fix that.

CSS开发人员需要不断意识到的另一件事是，他们CSS的特殊性不会成为难题。 如果选择器很长，那么CSS就会变得难以预测，并且难以维护和调试.Harry Roberts写了很多文章来说明为什么这样做不好以及如何解决这个问题 。

可用的解决方案： (Solutions available:)

The best solution to this problem is to simply restrict your selectors to one class. No chaining, no nesting, no IDs. The above mentioned BEM naming and atomic classes both result in single class selectors in your CSS and hence help in solving this issue.

解决此问题的最佳方法是将选择器仅限制为一个类。 没有链接，没有嵌套，没有ID。 上面提到的BEM命名和原子类都导致CSS中使用单个类选择器，因此有助于解决此问题。

问题3：未使用CSS怎么办？ (Problem 3: What about unused CSS?)

CSS is render blocking, hence its very important to load only the critical CSS of a page synchronously and the rest, asynchronously. For the same reason, it also becomes important to prevent your CSS from creating bloat by stripping unused CSS.

CSS是呈现阻止，因此，仅同步加载页面的关键CSS并异步加载其余页面CSS非常重要。 出于同样的原因，通过清除未使用CSS来防止CSS产生膨胀也很重要。

可用的解决方案： (Solutions available:)

Many tools boast of extracting out used CSS of a page. But with single page apps coming in, this has become more difficult than ever. I am not sure how reliable or efficient they are, but that still needs an extra post-processing over your CSS.

许多 工具都夸耀出页面CSS。 但是随着单页应用程序的到来，这变得比以往更加困难。 我不确定它们的可靠性或效率如何，但是仍然需要对CSS进行额外的后处理。

问题4：重构 (Problem 4: Refactoring)

Developer 1: This CSS has become quite messy. I think we should refactor it.

开发人员1 ：此CSS变得非常混乱。 我认为我们应该重构它。

Developer 2: Do you think this selector you are modifying might also be getting used on page X? Did you check?

开发人员2 ：您认为您正在修改的选择器也可能在第X页上使用吗？ 你检查过了吗？

Developer 1: Oh damn! You are correct…I missed that. That page X is too critical to touch. Do you know why that developer used the same class on both pages?

开发人员1 ：该死！ 您是正确的…我很想念。 该页面X太关键，无法触摸。 您知道为什么该开发人员在两个页面上使用相同的类吗？

Developer 2: No idea. He left the company. Let’s just leave the CSS as it is :(

开发人员2 ：不知道。 他离开了公司。 让我们照原样保留CSS :(

I have nothing more to say here. That dialogue explains it all.

我在这里无话可说。 对话说明了一切。

If I am to summarize above problems, I would say that writing good (scalable, readable, maintainable) CSS is definitely possible. However, doing so in a huge team is extremely difficult. Even if you try to make it right in a team, it would require a constant effort of someone to enforce all the best practices.

如果我要总结以上问题，我会说编写好的(可伸缩，可读，可维护)CSS绝对是可能的。 但是，在庞大的团队中这样做非常困难。 即使您试图在团队中做到正确，也需要有人不断努力以实施所有最佳实践。

In a team, the most non-obvious but perfect solution would be — to stop writing CSS!

在团队中，最不明显但最完美的解决方案是-停止编写CSS！

“Wait, what are you saying? That’s not possible!”. You might be thinking so, but let me introduce you to something.

“等等，你在说什么？ 那是不可能的！”。 您可能会这样想，但让我向您介绍一些事情。

多合一解决方案— ACSS(雾化器) (The all-in-one solution — ACSS (Atomizer))

ACSS (derived from Atomic CSS) is a component-based framework for styling through atomic classes developed at Yahoo! And Atomizer is a tool that actually facilitates that. I’ll explain more. But before that, let me show you how you do styling in ACSS.

ACSS (源自Atomic CSS)是一种基于组件的框架，用于通过Yahoo!开发的原子类进行样式设置。 而Atomizer是实际上可以简化这一过程的工具。 我会解释更多。 但是在此之前，让我向您展示如何在ACSS中进行样式设置。

To follow along with the code samples in this article, I suggest you install Web Maker (a front-end playground that supports writing ACSS without any build setup) on Chrome browser.

为了跟随本文中的代码示例，我建议您在Chrome浏览器上安装Web Maker (支持无需编写任何构建设置即可编写ACSS的前端游乐场)。

Now say you have a button that needs to be styled with usual padding, background, color etc properties. This is how it would look like in ACSS:

现在说您有一个需要使用常规填充，背景，颜色等属性设置样式的按钮。 这是在ACSS中的样子：

 I am a button

One suggestion — make no judgment by the first look at this syntax. Keep reading, give it time, discuss, and then decide. The classes on the button tag might look different but you would agree they are guessable to a large extent about what they do. It’s a button with blue background-color , whitecolor , 10px padding , inline-block display , pointer cursor and changed to redbackground-color on hover.

一个建议-初看此语法时不要做出判断。 继续阅读，给它时间，讨论，然后决定。 button标记上的类可能看起来有所不同，但是您会同意它们在很大程度上可以猜测它们的作用。 它与蓝色按钮b ack g round- c olor ， 白色 c olor ，10px的 p adding ， 内联块 d isplay ， 指针 cur sor和改变为红色 background-color上悬停。

If you have installed Web Maker already, open it by clicking the Web Maker icon in your Chrome browser’s top-right side. Paste the above HTML in the HTML code pane and select Atomic CSS as the mode in CSS code pane. As soon as you do this, you’ll see some automatic CSS generated in the CSS code pane, like so:

如果您已经安装了Web Maker ，请单击Chrome浏览器右上角的Web Maker图标将其打开。 将上述HTML粘贴到HTML代码窗格中，然后在CSS代码窗格中选择Atomic CSS作为模式。 完成此操作后，您将在CSS代码窗格中看到一些自动生成CSS，如下所示：

The CSS you see is generated by the Atomizer tool I mentioned above. Basically, it reads HTML (or any file), detects ACSS classes from them and generates CSS for those detected classes. So you write just HTML with appropriate classes you want to use and CSS is auto-generated!

您看到CSS是由我上面提到的Atomizer工具生成的。 基本上，它读取HTML(或任何文件)，从中检测ACSS类，并为检测到的类生成CSS。 因此，您只编写了要使用的适当类HTML，并且CSS是自动生成的！

Now that we know how you do styling in ACSS, let’s see how it’s the best CSS methodology your team can have.

既然我们知道了您如何在ACSS中进行样式设置，那么让我们看看它是您的团队可以拥有的最佳CSS方法。

内联，但不是内联？ (Inline, but not inline ?)

As you can see we are always writing classes inline on the tags. That is what I meant by inline styling. But please don’t confuse it with the “inline styles”.Unlike inline styles, our inline classes translate to actual CSS classes in a cachable stylesheet. So basically we are getting the same power as inline styles (writing things quickly) but still get completely valid atomic CSS as output.

如您所见，我们总是在标记上内联编写类。 这就是我所说的内联样式。 但是请不要将其与“内联样式”混淆。 与内联样式不同，我们的内联类在可缓存的样式表中转换为实际CSS类。 因此，基本上，我们可以获得与内联样式相同的功能(快速编写内容)，但仍获得完全有效的原子CSS作为输出。

不再命名！ ？ (No more naming! ?)

My absolute favorite advantage. You’ll never ever have to think a nice, semantic, and non-conflicting name for a class.

我绝对喜欢的优势。 您将永远不必为类考虑一个好的，语义清晰且无冲突的名称。

A very famous saying goes:

有句非常著名的话：

There are only two hard things in Computer Science: cache invalidation and naming things. — Phil Karlton

在计算机科学中只有两件难事：缓存无效和命名。 — 菲尔·卡尔顿

超级容易的更新和重构 (Super easy updates and refactoring)

Go to the HTML and change classes to update some styling. Remove any class from anywhere without the fear of breaking anything elsewhere.

转到HTML并更改类以更新某些样式。 从任何地方删除任何课程，而不必担心会破坏其他地方的内容。

没有一个未使用CSS字节吗？ (Not a byte of unused CSS ?)

Since Atomizer generates CSS from the classes you have actually used, you never have unused CSS in your stylesheet. Isn’t that the crazy performance we have all been looking for? There is also a tool where you can check how much a website can benefit from ACSS — https://atomize-io.herokuapp.com/

由于Atomizer从实际使用的类生成CSS，因此样式表中永远不会有未使用CSS。 这不是我们所有人一直在寻找的疯狂表现吗？ 还有一个工具，您可以在其中检查网站可以从ACSS中受益多少— https://atomize-io.herokuapp.com/

没有针对新开发人员的指南？ (No guidelines for new developers ?)

All you need to give a new developer as part of your CSS onboarding is a syntax guide for ACSS and a class reference link — https://acss.io/reference. This is a page where you can easily search the ACSS class for any property:value. Even this convention embeds in your memory as you keep using it.

作为CSS 入门的一部分，您需要为新开发人员提供的是ACSS的语法指南和类参考链接— https://acss.io/reference 。 在此页面中，您可以轻松地在ACSS类中搜索任何property：value。 当您继续使用它时，即使该约定也嵌入您的内存中。

Also, there is a nifty little Visual Code extension by Pankaj Parashar that auto-suggests these classes right in the editor. So even the reference isn’t required with that extension. Developer onboarding is done!

另外， Pankaj Parashar提供了一个漂亮的Visual Code扩展 ，可以在编辑器中自动建议这些类。 因此，即使扩展名也不需要参考。 开发人员入职完成！

Apart from these advantages, there are several more goodies that ACSS comes with.

除了这些优点之外，ACSS还提供了其他一些优点。

• We generally keep using same old property/value pairs across an app. Thus the generated stylesheet essentially stops growing after a certain point. Because each unique property/value pair comes once in the final stylesheet.

  我们通常会在应用程序中继续使用相同的旧属性/值对。 因此， 生成的样式表在某一点之后基本上停止增长 。 因为每个唯一的属性/值对在最终样式表中都只出现一次。

• Because of the above point, you could actually use the same stylesheet across your suite of multiple products as it would never be so big. Same cached CSS stylesheet for all products!

  由于以上几点，您实际上可以在多个产品套件中使用相同的样式表，因为它永远不会太大。 所有产品的缓存CSS样式表相同！

• Pull request that feels like a dream. Imagine pull requests where you don’t see any .css files. No more checking classes for meaningfulness or specificity conflicts. Because you know correct atomic CSS, which should be present, would be generated. Won’t that be a wonderland?

  拉请求，感觉就像一个梦。 想象一下在没有任何.css文件的情况下的拉取请求。 不再需要检查类的有意义性或特异性冲突 。 因为您知道会生成应该存在的正确原子CSS。 那不是一个仙境吗？

神话破灭 (Myth busting)

Lots of myths have developed regarding ACSS across the Internet. This is because of shallow evaluation of the framework and judgment at first sight.

关于Internet上的ACSS的神话已经发展了很多。 这是因为对框架的浅薄评估和一见钟情。

与内联样式相同。 这不好！ (It’s same as inline styling. It’s bad!)

No, it’s not. We have already seen above. It’s definitely as powerful as inline styling but inherits no cons from it.

不，这不对。 我们已经在上面看到了。 它绝对与内联样式一样强大，但没有继承任何缺点。

很难一遍又一遍地编写所有相同的类集。 (It’s hard to write all those same set of classes over and over.)

Yes, it is. ACSS says it’s a component based framework. If you are not templating each of your components and are already duplicating HTML, say to create a button every time, ACSS isn’t for you.

是的。 ACSS表示这是一个基于组件的框架。 如果您不打算对每个组件进行模板化并且已经在复制HTML，那么说每次创建一个按钮，ACSS都不适合您。

For example you should be creating buttons using an abstracted button component like so:

例如，您应该使用抽象按钮组件创建按钮，如下所示：

Hello World

which should get compiled into something like:

应该编译成类似以下内容的文件：

Hello World

上课根本没有意义 (The classes make no sense at all)

I agree they are different and might look repulsive at first sight. But every atomic class framework comes with its own convention of naming things. And trust me, ACSS has the best of the naming convention. Read more about why they chose such naming.

我同意它们是不同的，乍一看可能令人反感。 但是每个原子类框架都有其自己的命名约定。 相信我，ACSS具有最好的命名约定。 阅读更多关于他们为什么选择这种命名的信息 。

I would like to quote a paragraph from one of Harry Robert’s article:

我想引用哈里·罗伯特 ( Harry Robert)的一篇文章的一段：

A common argument against BEM is that it’s ugly; I dare say that if you shy away from code based purely on its looks then you’re often missing the point. Unless the code becomes unnecessarily difficult to maintain, or genuinely more difficult to read, then perhaps you do need to think twice before using it, but if it ‘just looks odd’ but has a valid purpose, then it should definitely be fully considered before writing it off. — Harry Roberts

反对BEM的一个普遍论点是它很丑。 我敢说，如果您仅仅基于代码的外观回避代码，那么您常常会错过这一点。 除非代码变得不必要地难以维护或真正难以阅读，否则在使用它之前，您确实需要三思而后行，但是，如果代码“看起来很奇怪”但具有有效的用途，那么在使用它之前一定要进行充分考虑写下来。 — 哈里·罗伯茨

But here we are, using BEM to make our code bases sane.

但是在这里，我们使用BEM来使我们的代码基础更加健全。

我将无法在ACSS中做X事 (I won’t be able to do X thing in ACSS)

You’ll be amazed to see what all is possible by mere classes provided in ACSS. Pseudo-elements, flexbox, media queries, you name it. And the convention they came up with to do all these things is simply brilliant! Though there might be certain things not possible yet in ACSS, like CSS Grids, you can always open an issue or contribute to Atomizer.

您会惊奇地发现，仅通过ACSS中提供的类，一切皆有可能 。 您可以使用伪元素，flexbox，媒体查询。 他们提出来做所有这些事情的约定真是太好了！ 尽管ACSS中可能尚无法实现某些功能，例如CSS Grids，但是您始终可以提出问题或为Atomizer做出贡献 。

到底 (In the end)

I would request you give ACSS a try if you understand the pain of writing and managing CSS in a team. And remember, using ACSS doesn’t mean you cannot write plain CSS. Tools should be used where they work best. If there is something you feel plain CSS would be more appropriate for, you should definitely use it.

如果您了解在团队中编写和管理CSS的痛苦，请尝试ACSS。 请记住，使用ACSS并不意味着您不能编写纯CSS。 应在最有效的地方使用工具。 如果您觉得普通CSS更适合于某些东西，则绝对应该使用它。

Also, ACSS isn’t alone taking this approach. There are similar alternatives like Blowdry CSS, Cell CSS etc, each bringing their own style of achieving the same thing.

而且，并非只有ACSS采取这种方法。 还有类似的替代方案，例如Blowdry CSS ， Cell CSS等，每种替代品都具有实现同一事物的自己的风格。

If you have any questions regarding ACSS, you can ping Thierry Koblentz, the man himself from ACSS team, on Twitter. Ask a question at the FAQ compilation he maintains or join the Atomizer group on Gitter. Or put in the comments of this article.

如果您对ACSS有任何疑问，可以在Twitter上 ping Ahi团队的Thierry Koblentz 。 在他维护的FAQ汇编中提出问题，或加入Gitter上的Atomizer组 。 或放入本文的评论。

Finally, I would like to thank Thierry Koblentz and Jitendra Vyas for reviewing this article.

最后，我要感谢Thierry Koblentz和Jitendra Vyas对本文的审阅。

If you like this article, show your love by clapping?? on the article. Also follow me on Twitter, where I share more front-end articles and side-projects of mine.

如果您喜欢这篇文章，请鼓掌表示爱意？？ 在文章上。 也可以在Twitter上关注我，在这里我可以分享我的更多前端文章和附带项目。

更多阅读 (More to read)

• https://www.smashingmagazine.com/2013/10/challenging-css-best-practices-atomic-approach/ — by Thierry Koblentz

  https://www.smashingmagazine.com/2013/10/challenging-css-best-practices-atomic-approach/-蒂埃里·科布伦茨(Thierry Koblentz)

• Atomizer GitHub repo — https://github.com/acss-io/atomizer

  Atomizer GitHub存储库-https: //github.com/acss-io/atomizer

• ACSS documentation — https://acss.io/quick-start.html

  ACSS文档- https://acss.io/quick-start.html

• ACSS FAQs compiled by Thierry — https://github.com/thierryk/ACSS-QA

  蒂埃里(Thierry)编写的ACSS常见问题解答— https://github.com/thierryk/ACSS-QA

• ACSS playground — https://webmakerapp.com

  ACSS游乐场— https://webmakerapp.com

翻译自: https://www.freecodecamp.org/news/acss-a-dynamic-atomic-css-library-402dff9756e0/

acss码表