原子弹CSS

tech2022-12-29 76

People love naming things. And developers love acronyms. And thus here we are, finding ourselves with all of these CSS naming conventions and methodologies: BEM, SMACSS, Point North, ITCSS, OOCSS, Title CSS, Idiomatic CSS, Atomic Design, SUIT CSS, Kickoff CSS, etc.

人们喜欢命名事物。开发人员喜欢首字母缩写词。因此，在这里，我们发现了所有这些CSS命名约定和方法： BEM ， SMACSS ， Point North ， ITCSS ， OOCSS ， Title CSS ， Idiomatic CSS ， Atomic Design ， SUIT CSS ， Kickoff CSS等。

We often hear “Are you using OOCSS or BEM?” but these things are not mutually exclusive. In fact, most of the time, we’re taking concepts and ideas of the aforementioned ideologies, and mixing them up, customizing them to suit (no pun intended) our own needs.

我们经常听到“您使用的是OOCSS还是BEM？” 但是这些东西并不互相排斥。实际上，在大多数情况下，我们会采用上述意识形态的概念和想法，并将它们混合在一起，进行定制以适应(而不是双关语)我们自己的需求。

So what have I been using these days? Well that would be Atomic OOBEMITSCSS. Yep. Atomic OOBEMITSCSS.

那几天我一直在用什么呢？好吧，那将是AOOmic OOBEMITSCSS。是的原子OOBEMITSCSS。

The first time I heard this ridiculous term was from a tweet via Dan Eden, who tweeted:

我第一次听到这个荒谬的说法是来自Dan Eden的推文，他在推特上写道：

@mrmrs_ @hcatlin we’re adopting OOBEMITSCSS. Not even kidding.

@mrmrs_ @hcatlin我们正在采用OOBEMITSCSS。甚至没有开玩笑。

— Daniel Eden (@_dte) May 6, 2015

— Daniel Eden(@_dte) 2015年5月6日

I’m sure he doesn’t even remember tweeting that joke, but the more I thought about it, the more I realized it wasn’t a joke, and it hasn’t left my mind since. OOBEMITSCSS is exactly we’ve adopted, too. That sounds crazy, but it makes sense when you break it down.

我确定他甚至都不记得发过那个玩笑，但我想得越多，我就越发意识到这不是个玩笑，从那以后我就再也没有离开过。我们也确实采用了OOBEMITSCSS。这听起来很疯狂，但是当您将其分解时，这是有道理的。

原子CSS (Atomic CSS)

Let’s Start with Atomic Design. Atomic Design is a systems-thinking methodology solidified by Brad Frost. Upon further research in finding how it relates to styling, I came upon this article on Atomic Sass. While I’m not using the directory structure outlined there, I do use the concepts and ideas expressed by Brad’s Atomic Design methodology in design work and extend them onto my development work (via Sass modules and components).

让我们从原子设计开始。原子设计是Brad Frost巩固的一种系统思考方法。在进一步研究发现它与样式之间的关系之后，我发现了有关Atomic Sass的文章。尽管我没有使用此处概述的目录结构，但在设计工作中确实使用了Brad的Atomic Design方法论所表达的概念和思想，并将其扩展到我的开发工作中(通过Sass模块和组件)。

The gist is basically to design and develop in terms of systems thinking — to create individual molecules or elements which, when combined and placed together, weave a web of modules, components, and eventually entire layout systems. (Officially, there are 5 components to this: atoms, molecules, organisms, templates, and pages) You can start to see this in the following example:

要点基本上是根据系统思想进行设计和开发-创建单独的分子或元素，这些元素或元素在组合并放置在一起后，将编织一个模块，组件以及最终整个布局系统的网络。 (正式有五个组成部分：原子，分子，生物，模板和页面)您可以在以下示例中开始看到它：

Take this example from my Pinterest board:

从我的Pinterest板上举个例子：

Here we see a card. This card is made up of a few atoms:

在这里，我们看到一张卡片。该卡由几个原子组成：

caption text

字幕文字 header text (pin type)

标题文字(图钉类型) body text (caption)

正文(标题) callout text (message)

标注文字(消息) callout text (title)

标注文字(标题) callout image (mini board)

标注图片(小板) source icons

源图标 local icons

本地图标 numeric treatment

数值处理 main image

主图 dividers

分隔线

These are then pulled together in sets of molecules:

然后将它们组合成分子集：

Image & Citation (main image + source icon + caption text)

图片和引文(主图片+源图标+字幕文本) Pin Metadata (pin type text + hr + body text + [local icon + numeric treatment] x2)

固定元数据(固定字型文本+小时+正文文本+ [本地图标+数字处理] x2) Callout (callout image + callout text (message) + callout text (title))

标注(标注图片+标注文字(消息)+标注文字(标题))

Those molecules then comprise an organism aka the card itself:

然后这些分子就构成了生物，也就是卡片本身：

(Image & Citation) + (Pin Metadata) + divider + (Callout)

(图像与引文)+(引脚元数据)+分隔线+(标注)

The home page of Pinterest is full of these organisms. They make up a big part of the homepage layout:

Pinterest主页上充满了这些生物。它们占首页布局的很大一部分：

These elements are reused and remixed in other places on the site:

这些元素在站点的其他位置被重复使用和重新混合：

In the above “pin view” modal (which we see by clicking the “Pin It “button), we see the same treatment as we do on the homepage without the callout on the bottom, and placed in a different context.

在上面的“固定视图”模式(通过单击“固定”按钮可以看到)中，我们看到了与首页相同的处理，底部没有标注，并且放置在不同的上下文中。

This is the view from clicking the image itself. Notice how the same header treatment and on the *type* of pin and source icon follows us throughout both of these views on the site. Atomic design thinking allows us to create modular, consistent design systems.

这是单击图像本身的视图。请注意，在网站上的所有这两个视图中，相同的标题处理以及“ pin”和“ source”图标的* type *都遵循着我们。原子设计思想使我们能够创建模块化，一致的设计系统。

边界元 (BEM)

BEM is the system I use to mark things up. BEM Stands for Block, Element, Modifier. This is especially useful on a huge team, like the one I am now working within at IBM. I wrote a post about it once, but other people have written better posts since (I can’t believe that was 2013!).

BEM是我用来标记事物的系统。 BEM代表块，元素，修饰符。这对于一个庞大的团队尤其有用，就像我现在在IBM工作的那个团队一样。我曾经写过一篇关于它的文章，但是自那以后，其他人写了更好的文章(我不敢相信那是2013年！)。

So let’s take a look back at our first example of the card:

因此，让我们回顾一下卡片的第一个示例：

How would we mark this up? Well we would separate the markup based on its atomic structure first. This means we would start at the most basic level, and extend from there. Let’s isolate a small section to examine its markup. (note: I am intentionally disregarding treatment for links and interaction here in this example, but the ideas for marking those up persist. Using atomic markup allows for easy reuse of script actions whenever building components. I.e. the action for clicking the heart will always change its styling, such as fill color, and increase the hearts-count)

我们将如何标记呢？好吧，我们将首先根据其原子结构来分离标记。这意味着我们将从最基本的层次开始，然后从那里扩展。让我们隔离一小部分来检查其标记。 (注意：在本示例中，我故意忽略链接和交互的处理，但是标记这些标记和标记的想法仍然存在。使用原子标记可以在构建组件时轻松重用脚本操作。即，单击心脏的操作将始终发生变化其样式(例如填充颜色，并增加心数)

These class names are semantic to the content presented, and are broken up by their atomic molecules. Those molecules become the blocks in BEM. We don’t have modifiers in the above example, but if we wanted to separate the metadata of hearts (i.e. if *only* the heart was clickable), for instance (normally I’d just use a pseudo-element for the icon), we could write it like this:

这些类名称是所呈现内容的语义，并且被其原子分子分解。这些分子成为BEM中的块。在上面的示例中，我们没有修饰符，但是，例如，如果我们想分离心脏的元数据(即，如果*仅*心脏是可点击的)(通常，我只会对图标使用伪元素) ，我们可以这样写：

Some argue that this leads to long selectors (it does), but semantically it makes a ton of sense and really cleans up your markup by limiting the number of classes you use. And by limiting I mean, seriously, try to use only **one class per element** if you can. Frankly, I find BEM invaluable for use within teams and works really well in an object-oriented manner (read on friends!).

有人认为这会导致选择器变长(的确如此)，但从语义上讲，这很有意义，并且通过限制使用的类数来清理标记。通过限制，我的意思是，认真的说，如果可以的话，请尝试仅对每个元素仅使用一个类。坦白地说，我发现BEM对于在团队中使用非常有价值，并且以面向对象的方式非常有效(请读朋友！)。

OOCSS (OOCSS)

OOCSS stands for Object-Oriented CSS. From Nicole Sullivan’s OOCSS workshop:

OOCSS代表面向对象CSS 。来自Nicole Sullivan的 OOCSS 研讨会：

Basically, a CSS “object” is a repeating visual pattern, that can be abstracted into an independent snippet of HTML, CSS, and possibly JavaScript. That object can then be reused throughout a site.

基本上，CSS“对象”是重复的视觉模式，可以抽象为HTML，CSS以及可能JavaScript的独立代码段。然后可以在整个站点中重复使用该对象。

The examples Nicole shows in her workshop use multiple classes to achieve this format, which, at this point, may leave you thinking: “Wait. Doesn’t this contradict BEM?” Nope. It doesn’t have to. We have Sass to make things right :) So it’s less OOCSS and more OOSCSS!

Nicole在她的工作室中显示的示例使用多个类来实现这种格式，此时，您可能会想： “等等。这与BEM并不矛盾？” 不。不必。我们有Sass来解决问题：)因此，少了OOCSS，更多了OOSCSS ！

I like to think of the way I write my Sass as Object-Oriented. If we think of the card as an “object” which pulls in various “classes” to comprise it, we can still keep everything nested nice and neat with the use of the almighty ampersand (if you’ve read any of my previous blog posts you’ll know how much I love the ampersand.

我喜欢考虑将Sass编写为面向对象的方式。如果我们将卡片视为吸收各种“类别”以构成卡片的“对象”，则仍可以使用全能的＆符使所有内容嵌套得井井有条 (如果您已阅读我以前的任何博客文章，您会知道我有多喜欢＆符。

Example time! Let’s use the metadata section for this, as it provides a good example of hidden complexity:

时间示例！让我们为此使用元数据部分，因为它提供了隐藏复杂性的一个很好的例子：

We’ll want to be thinking modularly and in the realm of object-oriented encapsulation. Icons are a great start:

我们将要在面向对象的封装领域进行模块化思考。图标是一个很好的开始：

%icon { content: ''; display: block; &--pins { @extend %icon; background-image: url('../img/pins.svg'); } &--heart { @extend %icon; background-image: url('../img/heart.svg'); } }

Woah. What’s going on here? Well A) like I said earlier, I overuse ampersands, so make sure you’re familiar with those. B) We’re creating an invisible (aka “placeholder selector“) in Sass. This means that none of this code is processed into CSS until we @extend it. All of our icons will have some shared properties (in this case, content: '' and display: block). Then we specify the background-image for each individual icon while *extending* the styled from its parent block. This can be done with a simple @each loop and icons can be organized within a map to make things cleaner. Nothing is being output here, but technically, this is what’s going on behind-the-scenes:

哇。这里发生了什么？嗯，就像我之前说的，我过度使用了＆符号，因此请确保您熟悉这些符号。 B)我们在Sass中创建一个不可见的(又名“ 占位符选择器 ”)。这意味着在我们@extend之前，这些代码都不会被处理成CSS。我们所有的图标都将具有一些共享属性(在这种情况下， content: ''和display: block )。然后我们为每个单独的图标指定背景图像，同时“扩展”其父块的样式。这可以通过一个简单的@each循环来完成，并且可以在地图中组织图标以使内容更整洁。这里没有输出任何内容，但是从技术上讲，这是幕后情况：

%icon, %icon--pins, %icon--heart { content: '; display: block; } %icon--pins { background-image: url('../img/pins.svg'); } %icon--heart { background-image: url('../img/heart.svg'); }

So continuing on, let’s see what the block looks like when written in a object-oriented Sassy way. Let’s just get a grounds for some typography that we’ll instantiate in a moment when building out our component:

接下来，让我们看看以面向对象的Sassy方式编写块时的样子。让我们为一些排版奠定基础，我们会在构建组件时立即实例化这些排版：

%font-stack--body { // actual Pinterest font stack (!) font-family: 'Helvetica Neue','Helvetica','ヒラギノ角ゴ Pro W3','Hiragino Kaku Gothic Pro','メイリオ','Meiryo','ＭＳＰゴシック',arial,sans-serif; } %font-stack--headers { @extend %font-stack--body; font-weight: 600; //headers are the same typeface as everything else but have a heavier weight } %type--base-body { @extend %font-stack--body; //extend the body stack } %type--base-h2 { @extend %font-stack--headers; //extend headers (which extend body stack and give them a heavier weight) font-size: 1.5em; //font-size adjustment }

And now to the molecule! This is where it gets really delicious:

现在到分子！这是真正美味的地方：

.metadata { &__pin-type { @extend %type--base-h2; //extend base header styling } &__caption { @extend %type--base-body; //extending normal body copy } &__hearts { &:hover { color: red; //unique hover color } &:after { @extend %icon--heart; // extending heart icon on pseudo element } } &__pins { &:hover { color: green; //unique hover color } &:after { @extend %icon--pins; // extending pins icon on pseudo element } } }

What does that look like in CSS? Despite all of the nesting, we output one single class for everything!

CSS看起来像什么？尽管有所有嵌套，但我们为所有内容输出一个类！

.metadata__pins:after, .metadata__hearts:after { content: '; display: block; } .metadata__pins:after { background-image: url('../img/pins.svg'); } .metadata__hearts:after { background-image: url('../img/heart.svg'); } .metadata__pin-type, .metadata__caption { font-family: 'Helvetica Neue','Helvetica','ヒラギノ角ゴ Pro W3','Hiragino Kaku Gothic Pro','メイリオ','Meiryo','ＭＳＰゴシック',arial,sans-serif; } .metadata__pin-type { font-weight: 600; } .metadata__pin-type { font-size: 1.5em; } .metadata__hearts:hover { color: red; } .metadata__pins:hover { color: green; }

Bellisimo!

贝里西莫！

ITCSS (ITCSS)

Okay, this is where we pull it all together. We’re almost at the finish line! So. Let’s talk ITCSS. First of all, what is ITCSS? Well IT (lol) is a methodology for how to author your stylesheets that answers the exigent question of of how the heck do I order my styles?

好的，这是我们将它们组合在一起的地方。我们快到终点了！所以。让我们谈谈ITCSS。首先，什么是ITCSS ？ IT (lol)是一种用于编写样式表的方法，该方法可以回答有关如何订购样式的紧急问题？

Here is an excellent visual, stolen directly from Harry Roberts’ blog post on the Specificity Graph (sorry, hope you don’t mind!)

这是一个很棒的视觉效果，直接从Harry Roberts的Specificity Graph博客文章中被盗(对不起，希望您不要介意！)

In Essence:

在本质上：

这是您的特异性图(大概)如下所示： (This is what your specificity graph (probably) looks like:)

这就是您的特异性图应该看起来像： (This is what your specificity graph should look like:)

The specificity graph is an analysis of your CSS code specificity. When using !important statement and overriding your code earlier-than-necessary, it creates these dramatic peaks, causing you to then need to override it again to override the too-specific override. Do you see why this is problematic? Not only is it confusing and non-semantic, but it also causes you to write less-performant code and produce larger stylesheets because of all of your overrides. Your stylesheet size can be represented as the area below the graph.

特异性图是对CSS代码特异性的分析。当使用!important语句并在比必要的时间更早地覆盖代码时，它将创建这些引人注目的峰值，从而使您需要再次覆盖它以覆盖过于具体的覆盖。您知道这为什么有问题吗？它不仅令人困惑且不语义，而且由于所有替代，还会导致您编写性能较低的代码并生成较大的样式表。您的样式表大小可以表示为图表下方的区域。

How, you ask? In the example above, we see that we supply the broadest styles first, and then we only apply specific styles when we need to, to the element or modifier. Otherwise, we extend from existing code, that is created earlier in the flow of the styles. It helps to organize your stylesheets modularly, and use the first few imports as helpers or variables that don’t output any CSS (like the placeholder selectors for icons and typography). I could (and have) written entire posts on this subject (and have even made a tool for authoring your stylesheet architecture, forcing you to plan a route before delving in).

你怎么问？在上面的示例中，我们看到我们首先提供了最广泛的样式，然后仅在需要时才将特定样式应用于元素或修饰符。否则，我们从现有的代码，也就是在样式的流之前创建扩展。它有助于模块化地组织样式表，并将前几个导入用作不输出任何CSS的帮助程序或变量(例如，用于图标和排版的占位符选择器)。我可以(并且已经 )撰写了有关该主题的整篇文章(甚至制作了一个用于编写样式表体系结构的工具，迫使您在深入研究之前计划一条路线)。

So there you have it, Atomic OOBEMITSCSS.

因此，您已经有了Atomic OOBEMITSCSS 。

翻译自: https://www.sitepoint.com/atomic-oobemitscss/

最新回复(0)