css编写_开始编写CSS

css编写

Don't you feel that CSS is not the same anymore? Last few years became a hot topic and many smart people talked about it. CSS is not that little thing which front-end developer should do to make the page looks pretty. It's far more then that. We care about performance and we want to produce better web sites. In this article I want to share what I learned last few months and what exactly is my vision about CSS coding. As a programmer I'm really interested in the architectural part of the things. I feel that the writing of CSS should be changed and I dig a lot. I search for the good processes, the best principles and new workflows. This post is like conclusion of journey in the world of CSS. Many people say that writing CSS is not exactly programming. I'll disagree and will say that it's equally interesting and challenging.

您不觉得CSS不再一样了吗? 过去几年成为一个热门话题,许多聪明的人都在谈论它。 CSS并不是前端开发人员应该做的让页面看起来漂亮的小事。 远不止于此。 我们关心性能,我们希望产生更好的网站。 在本文中,我想分享一下我最近几个月所学到的东西,以及我对CSS编码的确切看法。 作为程序员,我对事物的体系结构部分非常感兴趣。 我觉得应该改变CSS的编写方式,因此我做了很多工作。 我在寻找良好的流程,最佳的原则和新的工作流程。 这篇文章就像CSS世界之旅的总结。 许多人说编写CSS并非完全是编程。 我不同意并且会说这同样有趣和具有挑战性。

CSS预处理器 (CSS Preprocessors)

What happens when a programmer starts writing CSS

Ok, let's face it. Writing pure CSS is not the funnies thing in the world. The preprocessors take something which looks like CSS, make some magic and produce valid CSS code. This adds one more layer between you and the final styles which are send to the browser. That's not so bad as it sounds like, because the preprocessors provide some really helpful features.

好吧,让我们面对现实。 编写纯CSS并不是世界上最有趣的事情。 预处理器采用类似于CSS的东西,产生一些魔力并产生有效CSS代码。 这将在您和发送到浏览器的最终样式之间增加一层。 听起来还不错,因为预处理器提供了一些非常有用的功能。

级联 (Concatenation)

I think that one of the most valuable thing which came is the concatenation of your files. I'm sure, you know that when you use @import in your .css file you actually tell to the browser please, get that file too. And it does. It makes a new request which is kinda bad, because you may have a lot of files. Making additional requests decrease the performance of you application. If you use CSS preprocessors this problem is gone. They simply compile all your styles to one single .css file.

我认为最有价值的事情之一是文件的串联。 我敢肯定,您知道当在.css文件中使用@import时 ,实际上告诉浏览器,也请获取该文件 。 确实如此。 它发出了一个新请求,这有点不好,因为您可能有很多文件。 发出其他请求会降低应用程序的性能。 如果使用CSS预处理程序,则此问题将消失。 他们只是将您所有的样式编译为一个.css文件。

延伸 (Extending)

There are two main CSS preprocessors - LESS and SASS. They both support extending. Yes, it works a little bit different, but the idea is the same. You make a basic class (usually called mixin) with bunch of properties and later import these properties inside another selector. For example

CSS有两个主要的预处理器-LESSSASS 。 他们都支持扩展。 是的,它的工作原理有些不同,但是想法是相同的。 您可以创建具有一堆属性的基本类(通常称为mixin),然后将这些属性导入另一个选择器中。 例如

// less
.bordered(@color: #000) {
    border: dotted 2px @color;
}
.header { .bordered; }
.footer { .bordered(#BADA55); }

// compiles to
.header {
    border: dotted 2px #000000;
}
.footer {
    border: dotted 2px #bada55;
}


The problem here is that if you define a mixin without parameters i.e. if you have just

这里的问题是,如果您定义不带参数的混合,即

.bordered {
    border: dotted 2px #000;
}


this goes to the final compiled CSS file, no matter if it is used or not. It's like that, because it is a valid selector. In SASS we have a little bit more flexibility. There are mixins, extends and placeholders (if you want to see the exact difference between them I strongly recommend checking this article). Let's get the following SASS and its compilation:

无论是否使用,都会转到最终的已编译CSS文件。 就是这样,因为它是一个有效的选择器。 在SASS中,我们有更多的灵活性。 有mixin,extends和占位符(如果您想了解它们之间的确切区别,我强烈建议您检查一下本文 )。 让我们获取以下SASS及其编译:

// sass
@mixin bordered($color: #000) {
    border: dotted 2px $color;
}
.header { @include bordered; }
.footer { @include bordered(#BADA55); }

// compiles to
.header {
    border: dotted 2px black; 
}
.footer {
    border: dotted 2px #bada55; 
}


It looks almost the same. But if we go to the second use case and define a place holder:

看起来几乎一样。 但是,如果我们转到第二个用例并定义一个占位符:

// sass
%bordered {
    border: dotted 2px #000;
}
.header { 
    @extend %bordered; 
}
.footer { 
    @extend %bordered; 
}

// compiles to
.header, .footer {
    border: dotted 2px #000; 
}


There are two good things happening. First, there is no .bordered class compiled. Second, SASS combines the selectors and it makes our CSS a little bit shorter.

有两件事正在发生。 首先,没有编译的.bordered类。 其次,SASS结合了选择器,这使我们CSS短了一些。

组态 (Configuration)

Both LESS and SASS support definition of variables. You can later access those variables and use them as values for your properties.

LESS和SASS都支持变量的定义。 您以后可以访问这些变量,并将它们用作属性的值。

// sass
$brand-color: #009f0A;
...
h1 {
    color: $brand-color;
}


That's a good feature, because you may store some important things like company colors or grid widths in one place. If you need to change something you don't need to go through all your code.

这是个好功能,因为您可以将一些重要的内容(例如公司颜色或网格宽度)存储在一个地方。 如果您需要更改某些内容,则无需遍历所有代码。

Another handy usage of the variables is interpolation. The following example demonstrates the idea:

变量的另一个方便用法是插值。 下面的示例演示了该想法:

// sass
@mixin border($side) {
    border-#{$side}: solid 1px #000;
}
.header {
    @include border("left");
}

// compiles to
.header {
    border-left: solid 1px #000; 
}


反对预处理器 (Against the preprocessors)

  • The preprocessor is a tool, i.e. it's one more thing which you have to add to your environment. You may want to integrate it into your application. This of course requires additional coding.

    预处理器是一种工具,也就是说,它是您还必须添加到环境中的另一件事。 您可能需要将其集成到您的应用程序中。 当然,这需要附加的编码。
  • If you don't want to mess your code with such a thing, then you will probably need a watcher. Another instrument which monitors your files and once something is updated fire compilation. If that's the case then you have to run the watcher every time when you start working on the project. Maybe you will optimize the process over the time, but it's still something that you should care about.

    如果您不想将代码弄乱,那么您可能需要一个观察者。 另一台监视文件并且一旦有更新的工具就会启动编译。 如果是这种情况,那么您每次开始处理项目时就必须运行观察程序。 也许您会随着时间的推移优化流程,但这仍然是您应该关注的事情。
  • Very often the developers look only their .less or .sass files. However the output is what it matters. You may have elegant and optimized SASS code, but this doesn't mean that you will end up with the same beautiful CSS code. You may have some really interesting specificity problems. So, check the compiled version regularly.

    开发人员经常只看他们的.less或.sass文件。 但是,输出才是最重要的。 您可能拥有优雅且经过优化的SASS代码,但这并不意味着您将获得相同的漂亮CSS代码。 您可能会遇到一些非常有趣的特异性问题。 因此,请定期检查编译版本。

边界元 (BEM)

What happens when a programmer starts writing CSS

Ok, I found a new tool to play with. The preprocessors probably save a lot of time, but they can't write a good architecture alone. The first thing which I started thinking of is a naming convention. Let's get the following HTML markup:

好的,我找到了可以使用的新工具。 预处理程序可能节省了很多时间,但是它们不能单独编写好的架构。 我开始想到的第一件事是命名约定。 让我们获取以下HTML标记:

<header class="site-header">
    <div class="logo"></div>
    <div class="navigation"></div>
</header>


A possible styling may look similar to

可能的样式可能类似于

.site-header { ... }
.logo { ... }
.navigation { ... }


This will work of course, but it has a problem - reading the CSS you can't understand that, for example, the logo belongs to the header. You may have another little logo image used in the footer. The next logical step is to write a descendant selector.

当然可以,但是有一个问题-阅读CSS,您可能无法理解,例如徽标属于标题。 您可能在页脚中使用了另一个小的徽标图像。 下一步逻辑是编写后代选择器。

.site-header .logo { ... }


However using such selectors is not very good idea, because it tights styles to specific tags hierarchy. What if I want to move the logo outside the header tag? I'll lose the styling. The other thing which you could do is to add site-header in the name of the logo's class:

但是,使用这样的选择器并不是一个好主意,因为它会将样式收紧到特定的标签层次结构。 如果我想将徽标移到标题标签之外怎么办? 我会失去样式的。 您可以做的另一件事是在徽标类的名称中添加site-header

.site-header-logo { ... }


That's good, self explanatory, but it doesn't work in all the cases. Later, during December I may want to use a Christmas version of the logo. So, I can't write

很好,不言自明,但并非在所有情况下都有效。 稍后,在十二月期间,我可能要使用徽标的圣诞节版本。 所以我不会写

.site-header-logo-xmas { ... }


because my logic is to write the selector like that so it matches the nesting of the tags in the html.

因为我的逻辑是这样编写选择器,以便它与html中标记的嵌套匹配。

BEM could be the answer of the situation. It means Block, Element, Modifier and creates some rules, which you could follow. Using BEM, our little example will be transformed to:

BEM可能是这种情况的答案。 这意味着块,元素,修饰符并创建一些规则,您可以遵循这些规则。 使用BEM,我们的小例子将转换为:

.site-header { ... } /* block */
.site-header__logo { ... } /* element */
.site-header__logo--xmas { ... } /* modifier */
.site-header__navigation { ... } /* element */


I.e. site-header is our block. The logo and the navigation are elements of that block and the xmas version of the logo is modifier. Maybe it looks simple, but it's really powerful. Once you start using it will find that it makes your architecture better. The arguments against BEM are mainly because of the syntax. Yes, maybe it looks a little bit ugly, but I'm ready to make a sacrifice in the name of the good system.

网站标题是我们的街区。 徽标和导航是该块的元素,徽标的圣诞节版本为修饰符。 也许看起来很简单,但确实功能强大。 一旦开始使用它,就会发现它使您的体系结构变得更好。 反对BEM的参数主要是因为语法。 是的,也许看起来有点丑陋,但是我准备以良好系统的名义做出牺牲。

(good reading: here and here)

(良好的阅读: 这里这里 )

OOCSS (OOCSS)

What happens when a programmer starts writing CSS

Once I found BEM I was able to name my classes correctly and I started thinking about composition. Maybe the first thing which I read was an article about Object oriented CSS. Object oriented programming sometimes is about adding abstractions and CSS language supports that. Using preprocessors or not, OOCSS is something that you should know about. As a coder I found this concept really close to my usual programming, in JavaScript for example. There are two main principles:

一旦找到了BEM,我就可以正确地命名我的班级,然后我开始考虑合成。 也许我读的第一件事是有关面向对象CSS的文章。 面向对象的编程有时是关于添加抽象的,而CSS语言则对此提供了支持。 是否使用预处理器,OOCSS是您应该了解的。 作为一名编码人员,我发现这个概念与我通常的编程非常接近,例如JavaScript。 有两个主要原则:

结构与皮肤分开 (Separate structure and skin)

Let's use the following example:

让我们使用以下示例:

.header {
    background: #BADA55;
    color: #000;
    width: 960px;
    margin: 0 auto;
}
.footer {
    background: #BADA55;
    text-align: center;
    color: #000;
    padding-top: 20px;
}


There are few styles which are duplicated. We may extract them in another class like that:

很少有重复的样式。 我们可以像这样将它们提取到另一个类中:

.colors-skin {
    background: #BADA55;
    color: #000;
}
.header {
    width: 960px;
    margin: 0 auto;
}
.footer {
    text-align: center;
    padding-top: 20px;
}


So, we have an object colors-skin which we could extend. The html markup may look like that:

因此,我们有一个可以扩展的颜色皮肤对象。 html标记可能如下所示:

<div class="header colors-skin"> ... </div>
<div class="colors-skin"> ... </div>
<div class="footer colors-skin"> ... </div>


There are several benefits of that change:

该更改有几个好处:

  • We have a class, which may be used several times.

    我们有一个类,可能会多次使用。
  • If we need a change we need to make it in only one place

    如果我们需要更改,则只需在一个地方进行
  • We removed duplication in our CSS file, which makes its file size lower

    我们删除了CSS文件中的重复项,从而使文件大小更小

容器和内容分开 (Separate container and content)

The idea here is that every element should have the same styles applied no matter where it is put in. So, you should avoid the usage of selectors similar to the following

这里的想法是每个元素无论放置在什么位置都应应用相同的样式。因此,应避免使用类似于以下内容的选择器

.header .social-widget {
    width: 250px;
}


It's because if you move .social-widget outside the .header container the width will be different. In general, that's not a good practice. Especially for components which are used all over the page. This principle encourage modular CSS and I strongly recommend to take enough time trying it. Personally, for me, following the principle means producing better CSS.

这是因为如果您将.social-widget移到.header容器之外,则宽度会有所不同。 通常,这不是一个好习惯。 尤其适用于整个页面使用的组件。 该原则鼓励模块化CSS,我强烈建议您花足够的时间进行尝试。 就我个人而言,遵循原则意味着产生更好CSS。

框架 (The framework)

If you open the OOCSS repository on GitHub you will see a framework. Yes, the framework uses object oriented CSS concept and yes, it has a bunch of cool ready-to-use components. From some time I don't like frameworks. If you think a bit you will see that the word framework has two parts frame and work. And indeed you work in a frame. You actually make a deal with that thing and you have to play by its rule. I prefer to use micro-frameworks or something which gives me only the base. Of course I don't mean to reinvent the wheel, but I'm always trying to find the balance. Very often, the ready-to-use solutions lead to messy and complex systems. My advice is to build things with only one an specific purpose. If you try to cover as many cases as possible you will end up with ... you know - a framework.

如果您在GitHub上打开OOCSS信息库 ,则会看到一个框架。 是的,该框架使用面向对象CSS概念,是的,它有很多很酷的即用型组件。 从某些时候开始,我不喜欢框架。 如果你觉得有点,你会看到这个词框架有两个部分框架工作 。 实际上,您是在框架中工作。 实际上,您要处理该事物,并且必须按其规则进行操作。 我更喜欢使用微框架或仅给我基础的东西。 当然,我并不是要重新发明轮子,但我一直在努力寻找平衡。 通常,即用型解决方案会导致系统混乱而复杂。 我的建议是只针对特定目的构建事物。 如果您尝试涵盖尽可能多的案例,您将最终得到……一个框架。

However, I strongly recommend checking the OOCSS framework. It's an unique piece of knowledge and maybe it will fit in your needs. The repository is hosted by Nicole Sullivan. She is a pioneer in OOCSS and if you have some free time I'll suggest to check here presentations/talks.

但是,我强烈建议您检查OOCSS框架。 这是一门独特的知识,也许可以满足您的需求。 该存储库由Nicole Sullivan托管。 她是OOCSS的先驱,如果您有空闲的时间,我建议您在此处查看演示文稿/讲座

SMACSS (SMACSS)

What happens when a programmer starts writing CSS

Another popular concept is SMACSS. SMACSS stands for scalable and modular architecture for CSS. Jonathan Snook introduces something like style guide for the CSS developers. The idea is to separate your application into the following categories:

另一个流行的概念是SMACSS 。 SMACSS代表CSS的可扩展和模块化体系结构。 Jonathan Snook为CSS开发人员介绍了类似样式指南的内容。 想法是将您的应用程序分为以下几类:

  • Base - basic default styles usually used for a simple selectors. Like clearfix for example.

    基本-通常用于简单选择器的基本默认样式。 例如clearfix。
  • Layout - grids definition

    布局-网格定义
  • Module - a group of elements which combined form a module. Like for example header or sidebar.

    模块-组成一个模块的一组元素。 例如标题或侧边栏。
  • State - contains different states of elements. Definition of rules if particular object is hidden, pressed, expanded etc ...

    状态-包含元素的不同状态。 如果特定对象被隐藏,按下,扩展等,则定义规则...
  • Theme - oriented more to the visual parts of the things. Similar like the state category.

    主题-面向事物的视觉部分。 类似于州类别。

I don't have experience using SMACSS, but it is quite popular and indeed promotes good ideas. The very good thing is that it is more like a concept then a framework. So, you are not tight to any strict rules, classes or components.

我没有使用SMACSS的经验,但是它非常流行并且确实在推广好的想法。 很好的是,它更像是一个概念而不是框架。 因此,您并不严格遵守任何严格的规则,类或组件。

原子设计 (Atomic design)

What happens when a programmer starts writing CSS

Knowing about OOCSS and SMACSS I searched for an appropriate metaphor and very soon I landed on this page. It's a presentation of the great concept Atomic Design. Its author is Brad Frost, which is a well known web developer working mainly in the responsive and mobile world.

了解OOCSS和SMACSS之后,我搜索了一个适当的隐喻,很快我就进入了此页面 。 这是伟大概念Atomic Design的展示 。 它的作者是Brad Frost ,这是著名的Web开发人员,主要在响应和移动世界中工作。

The idea is really interesting. Following some chemistry terminology, we could say that the basic unit of the matter is the atom. Brad moves this to CSS saying that our pages are build by atoms. An atom could be

这个想法真的很有趣。 遵循一些化学术语,我们可以说物质的基本单位是原子。 布拉德(Brad)将其移至CSS,表示我们的页面由原子构建。 一个原子可能是

<label>Search the site</label>


or

要么

<input type="text" placeholder="enter keyword" />


I.e. atoms contain some basic styling of DOM elements. Like color palette, font sizes or transitions. Later those parts could be combined into molecules. For example:

即原子包含DOM元素的一些基本样式。 像调色板,字体大小或过渡一样。 后来这些部分可以结合成分子。 例如:

<form>
    <label>Search the site</label>
    <input type="text" placeholder="enter keyword" />
    <input type="submit" value="search" />
</form>


So the form element contains several atoms. Abstracting the things like that brings flexibility, because we may use the same atoms to build another molecule. Together with that, we could reuse the same form in different contexts.

因此, 表单元素包含几个原子。 抽象这样的事物带来了灵活性,因为我们可以使用相同的原子来构建另一个分子。 除此之外,我们可以在不同的上下文中重用相同的表单

Brad didn't stop there. The organisms are something which is build of molecules. Following the same approach we may write the following and call it an organism:

布拉德没有就此止步。 生物是分子构建的东西。 按照相同的方法,我们可以编写以下内容并将其称为有机体:

<header>
    <div class="logo">
    <nav>
        <ul>
            <li><a href="#">Home</a></li>
            <li><a href="#">About</a></li>
            <li><a href="#">Contacts</a></li>
        </ul>
    </nav>
    <form>
        <label>Search the site</label>
        <input type="text" placeholder="enter keyword" />
        <input type="submit" value="search" />
    </form>
</header>


The next thing in the concept are the templates. They are not related to the chemistry directly, but are put into web context. Once we start combining different organisms we are building template. Later those templates form our final pages.

概念中的下一件事是模板。 它们与化学React没有直接关系,但是被置于网络环境中。 一旦我们开始结合不同的生物,我们将建立模板。 后来,这些模板构成了我们的最终页面。

You are probably already using similar approach to build your applications. However, naming the things in a reasonable manner brings good architecture. You and all your team mates will have something to catch on, during the development. Separation of the things to atoms and molecules is kinda important part, because it improves both, the working process and the maintenance of your web application.

您可能已经在使用类似的方法来构建应用程序。 但是,以合理的方式命名事物会带来好的架构。 在开发过程中,您和您的所有团队成员都会有所收获。 将事物分离为原子和分子是很重要的部分,因为它可以改善Web应用程序的工作过程和维护。

有机CSS (OrganicCSS)

What happens when a programmer starts writing CSS

Before a couple of months I wrote an article about Organic. It's a great small framework for JavaScript applications. It's more like a design pattern, and I personally like it a lot. I even used Organic in several projects and everything works pretty well. If you are interested in it, I strongly recommend reading the blog post here.

几个月前,我写了一篇关于有机食品的文章 。 这是一个用于JavaScript应用程序的小型框架。 它更像是一种设计模式,我个人非常喜欢它。 我什至在几个项目中都使用了Organic,并且一切正常。 如果您对此感兴趣,强烈建议阅读此处的博客文章。

When I read the Brad Frost's article I was already familiar with similar concept, because I knew about Organic. Brad's work is amazing, but I decided to go deeper and try to write my own micro framework based on atomic design concept. I chose SASS as a preprocessor and create a repository in Github - https://github.com/krasimir/organic-css.

当我阅读Brad Frost的文章时,我已经熟悉类似的概念,因为我了解有机食品。 Brad的工作很棒,但我决定更深入地尝试基于原子设计概念编写自己的微框架。 我选择SASS作为预处理器,并在Github- https://github.com/krasimir/organic-css中创建一个存储库。

原子 (Atoms)

Let's start with the smallest part of the framework - the atom. Its definition in wikipedia is The atom is a basic unit of matter. In the context of CSS, I think that it is a property and its value. For example:

让我们从框架的最小部分开始-原子。 它在维基百科定义是:原子是物质的基本单位 。 在CSS的上下文中,我认为它是一个属性及其值。 例如:

margin-top: 24px;


Adding atoms just by writing styles directly inside the classes is not what I wanted. Because if I type something like that

仅通过直接在类内部编写样式来添加原子不是我想要的。 因为如果我输入类似的内容

body {
    margin-top: 24px;
}
header {
    margin-top: 24px;   
}


the preprocessor will leave that as it is. The result which I want to get at the end is:

预处理器将保持原样。 我想最后得到的结果是:

body, header {
    margin-top: 24px;
}


In SASS this effect is achievable by using place holders. I.e.

在SASS中,使用占位符可以实现此效果。 即

%margin-top-24 {
    margin-top: 24px;
}
body {
    @extend %margin-top-24; 
}
header {
    @extend %margin-top-24; 
}


So, I had to use placeholders. This also means that I had to have a lot of predefined placeholders, which I can use. At that moment, I decided that the framework will contain only atoms. And maybe few molecules with generic functions like the usual reset.css, grid definition and so on. I wanted to write something which acts as a base for the CSS development. Maybe project after project I'll see some patterns, which could be put in the core, but as a start I wanted to keep the repo clean and simple.

因此,我不得不使用占位符。 这也意味着我必须拥有很多可以使用的预定义占位符。 那时,我决定框架将仅包含原子。 也许只有少数具有通用功能的分子,例如通常的reset.css ,网格定义等。 我想写一些东西作为CSS开发的基础。 也许一个接一个的项目,我会看到一些模式,这些模式可以放在核心中,但是作为开始,我想保持回购的简洁和简洁。

To make the things a little bit more consistently, I created a mixin for atom definition. So, here is an example:

为了使事情更加一致,我为原子定义创建了一个mixin。 因此,这是一个示例:

@include define-atom("block") {
    display: block;
}
@include define-atom("font-family") {
    font-family: Georgia;
}


Using this approach I created a bunch of atoms, which I could easily apply in every project. You can check them here. I used some good practices from other frameworks so, not all the credits go to me. There is also a mixin for combining atoms in a molecule:

使用这种方法,我创建了一堆原子,可以轻松地将其应用到每个项目中。 您可以在此处检查它们。 我使用了其他框架的一些良好做法,因此,并不是所有功劳都归功于我。 还有一种用于将分子中的原子结合的混合素:

@mixin header { // <- molecule called 'header'
    @include atoms((
        block,
        clearfix,
        font-family
    ));
}


分子 (Molecules)

Molecule is a DOM element which needs styling, but doesn't have children. Or if it has children they are not directly connected to it. For example <img src="logo.jpg" /> could be a molecule. If you find difficult to recognize the molecules in your page, just think of what is build by atoms. If some element is build by other molecules it is probably an organel. Just a few lines above I showed how to define a molecule:

分子是需要样式但没有子元素的DOM元素。 或者,如果它有孩子,则它们没有直接连接到它。 例如, <img src =“ logo.jpg” />可以是一个分子。 如果您发现难以识别页面中的分子,只需考虑一下原子构成的内容。 如果某些元素是由其他分子构建的,则可能是细胞器。 上面几行显示了如何定义分子:

@mixin login-box { 
    @include atoms((
        block,
        font-size-20,
        margin-top-23,
        bold
    ));
}


There is something interesting, which I faced with. Let's get the body tag. What it is? Is it a molecule or something else? Sure, it needs some styling via atoms, but in general contains other molecules. It should be something else. I made the conclusion that the CSS should be the leading part. I.e. if the body needs few atoms for its styling then it is a molecule, which means that, in theory, I should not attach any other molecules to it. This may seem a little bit impractical, but in most of the cases will keep you from using descent selectors, which is a good sign.

我遇到了一些有趣的事情。 让我们获取body标签。 这是什么? 是分子还是其他? 当然,它需要通过原子进行某些样式设置,但通常包含其他分子。 应该是别的东西。 我得出的结论是CSS应该是主要部分。 即,如果人体需要很少的原子进行造型,则它是一个分子,这意味着从理论上讲,我不应该在其上附加任何其他分子。 这似乎有些不切实际,但是在大多数情况下,您将无法使用下降选择器,这是一个好兆头。

细胞器 (Organelles)

Once you recognize which DOM elements are molecules you will see what organelles are. For example, the typical form element is a great example of organelle. It contains molecules like label, input or textarea.

识别出哪些DOM元素是分子后,您将看到什么细胞器。 例如,典型的形状元素是细胞器的一个很好的例子。 它包含诸如标签,输入或文本区域之类的分子。

.login-form {
    @include label;
    @include input;
    @include textarea;
}


The organelles are maybe the first part of the framework, which is tightly connected to the current application. The atoms and molecules could be transferred between the different projects while the organelles may not.

细胞器可能是框架的第一部分,它与当前应用程序紧密相连。 原子和分子可以在不同的项目之间转移,而细胞器则不能。

更多抽象 (More abstractions)

Very often you may want to combine several organelles in something else. If that's the case then add another abstractions.

很多时候,您可能希望将其他一些细胞器结合在一起。 如果是这样,则添加另一个抽象。

Atom → Molecule → Organelle → Cell → Tissue → Organ → Sys → Organism


It's a matter of choice how you will continue constructing your CSS. I used OrganicCSS only in one project so far, but I could say that it brings clarity. I put the different elements in their own directories and named the classes like that so I can easily find out what exactly I'm working with. For example if there is an organelle called header I simply change it to o-header. Later, when I read the HTML markup I could see that the CSS styles for this element are in organelles folder.

如何继续构建CSS是一个选择问题。 到目前为止,我仅在一个项目中使用了OrganicCSS,但是我可以说它带来了清晰度。 我将不同的元素放在它们自己的目录中,并像这样命名这些类,这样我就可以轻松地找到我正在使用的对象。 例如,如果有一个名为header的细胞器,我只需将其更改为o-header即可 。 稍后,当我阅读HTML标记时,我可以看到此元素CSS样式位于Organelles文件夹中。

结论 (Conclusion)

It was an interesting journey. I don't know if I'm going to use OrganicCSS in the future but that's not the most important part. The things which I've learned are what it matters. I knew that I had to change my CSS development process and I did it. I believe that we should talk more about architecture in CSS. As you can see we have a lot of good resources out there. We just have to find them, learn what they do and how they work. Only then we could decide what to use or not. Even better, when you see the whole picture you are able to create something which fits better in your needs.

这是一个有趣的旅程。 我不知道将来是否要使用OrganicCSS,但这不是最重要的部分。 我学到的东西很重要。 我知道我必须更改CSS开发流程,并且做到了。 我相信我们应该更多地讨论CSS中的体系结构。 如您所见,我们有很多好的资源。 我们只需要找到它们,了解它们的作用和工作方式。 只有这样,我们才能决定使用或不使用什么。 更好的是,当您看到整个图片时,便可以创建更适合您需求的东西。

翻译自: https://davidwalsh.name/starting-css

css编写

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值