CodePen's CSS_html/css_WEB-ITnose

Front-end development whqet, csdn, Wang Haiqing, whqet, front-end development expert

Translated from: CodePen's CSS

Translator: Front-end development whqet, mainly free translation, please correct me if I am inappropriate.

Translator said: Recently, some foreign experts have shared the CSS of their own websites, from which we can understand the application of CSS-related technologies and grasp the usage specifications of CSS. Today, I will translate the CodePen's shared by Chris Coyier, hoping that it can help Everyone some help.

-------------------------------------------------- ----------------

Getting inspiration from Mark Otto's GitHub's CSS and Ian Feather's Lonely Planet's CSS, I can't wait to join the event to talk about it How we do it on the CodePen website.

Overview

1. We use SCSS (CSS preprocessor)

2. We use Autoprefixer (browser prefix compatibility tool)

3. We use the Rails Asset Pipeline (JS, CSS compression tool)

4. Make a special SCSS file to display the document directory

5. We also have styles, which are mainly for Good looking

6. We don’t apply any special architecture, except “use classes a bunch”

7. Try to ensure that each page uses 2-3 css

8. Use @mixin to do media queries so that we can turn off the feature at any time

9. Using annotations is a good idea

10. Some statistics

11. I used the word we, but most of the time it’s just me

12. Our possible future

Preprocessor

There will always be people who love or hate CSS preprocessors, but without them, using and maintaining variables on any website would be impossible. If you think that creativity will be lost due to transition to tooling, I can only laugh it off.

Frankly speaking, all mainstream preprocessors (SASS, LESS, Stylus) can achieve most of my needs, but I prefer SCSS because of the good communication community. The following is a list of the usefulness of SCSS:

a.@import

b.@mixin

c.nesting

d.variables

e.@extend

f.math

g.loops

h.working with them enough so I understand all the cool kid demos

It adds some incredible features (that I can’t even imagine).

Prefix processing

I almost never consider the browser prefix problem of css properties and values, because Autoprefixer can solve this problem very well, I especially like it when dealing with flexbox performance.

I used to use Compass a lot, but I found that 95% of what I used came from CSS3 @minxins. Instead of using @include everywhere just for prefixes, I prefer to use the same as native CSS Writing method.

One thing I miss about Compass now is its ability to generate SVG gradients, but..., it's a bit too big just for some of the things IE9 needs, so I guess I don't lose much.

Rails

I am a huge fan of Rails Asset Pipeline. For example I put these into a view

    <%= stylesheet_link_tag "about/about" %>

and it will generate a css when I need it.

<link href="http://assets.codepen.io/assets/about/about-a05e4bd3a5ca76c3fb17f2353fedbd99.css" media="screen" rel="stylesheet" type="text/css" />

We set a long expiration time. Every time we deploy, it breaks the cache by changing these garbled numbers, so, pretty good cache configuration.

At CodePen we do use Sprockets, but only for Javascript, which works like this:

    //= require common/whatever.js    //= require_tree ./../hearting/

Could have done this in CSS too, but didn’t Necessary: ​​

a. SASS can do these

b. If you use SASS to solve the problem, the dependencies are better. For example, both $variables and @mixin can be used across files.

File Organization

There is a special SCSS file that is only used to display the CSS files that need to be loaded, which is equivalent to a directory and does not do anything practical. For example, the global.scss of the website looks like this:

// General Dependencies    @import "global/colors";    @import "global/bits";// Base    @import "global/reset";    @import "global/layout";// Areas    @import "global/header";    @import "global/footer";// Patterns    @import "global/typography";    @import "global/forms";    @import "global/toolbox";    @import "global/buttons";        @import "global/modals";    @import "global/messages";    @import "global/badges";// Third-Party Components    // (none at the moment)

I try to comply with these, but there are also a lot of unexpected situations, and I have to import what should be This stuff was all thrown into a file, so I created a shape file (shady file) for this purpose.

@import "shame";  // get organized, ya schlub.

Code organization

Executed like OCD Specifications

a. Apply 2-space indentation for attributes and nesting

b. Add one space before and after the selector

c. One declaration per line (for distinction Very important)

d.: Add a space after

e. Give the end character} an indentation level equivalent to its selector

f.0 as the length , without units

g. Use hyphens, no underscores

Conventions I follow in most cases

Very relevant declaration block Do not add a blank line between

.thing {}.related-thing {}

Add a blank line between slightly related declaration blocks

.thing {}.another-thing {}

Very bad Add two blank lines between relevant declaration blocks

.thing {}.totally-different-thing {}

Some specifications that I don’t care much about

The order of attributes, related The attributes appear in classic combinations, or casually.

The style to use for comments.

在实际使用中，我甚至不遵循自己写的规范。

架构

我的理论是，尽量给所有元素添加一个类，我不知道这点不是不是接近于SMACSS，OOCSS，BEM，或者诸如此类。

当然，不是说我不再进行任何嵌套，或者强制规定可以嵌套几层，我只是不进行深度嵌套。

一般来说，我经常这样做：

.box {   h2 {    &:after {    }  }}

这个时候我会想，我是否应该给h2一个类，我是否应该把这种类型的标题做成一个可重用组件。然后我就不在意了，因为以后如果它变得非常常用，我可以很容易的修改。

总体哲学是保持较低的特殊性。因为无论多棒的可重用性，它总是可能多次覆盖，因此选择器的特殊性越低，越容易覆盖。而且这种覆盖我们可以比较容易的再次覆盖，不用走ID选择器或者!important这种极端。

rem作文字的单位，px作其他单位，当然也有意外。

请求

我努力保证每个页面加载2-3个css请求

global.css

page.css (if not the editor)

section.css (if needed)

尽量减少页面的请求数量，但是不至于说把所有的东西都放到一个文件中去。CodePen有太多的单独页面CSS，如果都放到一块去global.css将不堪重负，我没有试过，也许那一天试试也很有意思，起个名字叫做squiCSSh_it_real_good.

媒体查询

我使用@minxin实现媒体查询，有时我采用“this width and bigger”，有时采用“this width and smaller”（可以看看媒体查询逻辑）。类似于这样：

@mixin breakpoint($point) {  @if ($MQs == true) {    @if $point == baby-bear {      @media (max-width: 500px) { @content; }    }    @if $point == mama-bear {      @media (max-width: 700px) { @content; }    }    @if $point == papa-bear {      @media (max-width: 800px) { @content; }    }    @if $point == super-bear {      @media (max-width: 1280px) { @content; }    }    @if $point == reverso-baby-bear {      @media (min-width: 501px) { @content; }    }    @if $point == reverso-mama-bear {      @media (min-width: 701px) { @content; }    }    @if $point == reverso-papa-bear {      @media (min-width: 801px) { @content; }    }    @if $point == reverso-super-bear {      @media (min-width: 1281px) { @content; }    }    @if $point == exclusive-baby-bear {      @media (max-width: 500px) { @content; }    }    @if $point == exclusive-mama-bear {      @media (min-width: 501px) and (max-width: 800px) { @content; }    }    @if $point == exclusive-papa-bear {      @media (min-width: 801px) and (max-width: 1280px) { @content; }    }    @if $point == iOS {      @media (min-device-width: 768px) and (max-device-width: 1024px), (max-device-width: 480px) {         @content;       }    }  }}

注意mixin头部的语句“@if ($MQs == true) ”实现媒体查询功能的开启与关闭功能，在内容目录的scss文件头部声明一个变量$MQs（true或者false）控制开关。因为CodePen里的一些页面需要响应式布局而另一些页面不用，没有采用响应式布局的页面可能跳转到一个专门的移动端版本中去。

注释

我是一个注释自由主义者，主要是因为我从不后悔，如果之后该注释不够明朗、不太贴切，我会直接删掉该注释。

.drag-from-pen-grid {  padding-bottom: 52px; /* adding this to make room for pagination. A little magic-numbery... */}

一些统计

一共有160个单独的SCSS文件，我从来不担心找不到文件，因为Sublime提供了强大的查询功能，而且文件具有命名清晰、结构明了。

SCSS文件共13345行

global.css文件11.8k

page.css文件5.5k

editor.css文件6.2k

css文件不是影响性能的关键因素，自定义字体四倍与它，JS文件10倍与它。

仅仅是我

网站由三个人合作开发，CSS方面主要是我负责。

未来

我现在没有lint，我将会lint javascript，那会很好

我没有创建本地资源地图，只是因为我觉得现在Sass/chrome不能很好的支持

我没有一个真正的模式类库。创建一个可视化的模式类库也许会很棒。

Enjoy it.

----------------------------------------------------------

前端开发whqet，关注web前端开发，分享相关资源，欢迎点赞，欢迎拍砖。
---------------------------------------------------------------------------------------------------------