CSS combat: Write CSS style sheet reference standard combat

Article Introduction: Point Separation (SoC). He has let us accept expansion, scrap, redundancy, caching or even more. Now, I'm convinced that the only way to do this is to stay away from this principle to improve our author style sheet.

When it comes to CSS, I believe in the divine principle--point separation (SoC). He has let us accept expansion, scrap, redundancy, caching or even more. Now, I'm convinced that the only way to do this is to stay away from this principle to improve our author style sheet.

For the context of never hearing about the SOC principle in web design, it involves some commonly known as "three-layer separation":

• Structure
• Performance
• Behavior

To avoid some concerns, divide it into separate resources: an HTML document, one or more style files, and one or more javasctript files.

But when it comes to the presentation layer, "best practices" have gone beyond the separation of resources. CSS authors are entirely likely to handle them through stylesheets, such as the CSS Zen garden written by Dave Shea is an excellent project. The CSS Zen Garden is a reference standard that most, if not all, developers use to write style sheets.

Standard

Today I can practice to help me explain related issues, I will use a very common module: Media objects. It combines HTML tags and CSS styles and will be the starting point for us to start exploring.

Template structure

In our template, there is a container ()div.mediacontaining a link container ()a.img, followed by adivcontainer (div.bd):

<div
					class="media">
			<a
					href="http://twitter.com/thierrykoblentz"
					class="img">
			
			</a>
			<div
					class="bd">         @thierrykoblentz 14 minutes ago     </div>
			</div>

Css

We set the container to 10pxmargin, while giving the container anddiv.bdsetting it to a BFC. In other words, the container contains a floating link anddiv.bdcannot be around the link. Set a 10 pixelmargin(on the floating side) between the picture and the text at the same time:

.media
			{     margin:
									10px;
					}
			.media, .bd
			{     overflow: hidden;
					_overflow: visible;
					zoom:
									1;
					}
			.media
			.img
			{     float: left;
					margin-right:
									10px;
					}
			.media
			.img
			img
			{     display: block;
					}

Results

This is the manifestation of a container, there is a picture in the link and text around the side:

When new requirements arise

Suppose we now need to display the text on the other side of the image.

Template structure

Very luckyBFCMagic, now we need to modify the link style style. To do this, we add a new class name to the pictureimgExt.

<div
					class="media">
			<a
					href="http://twitter.com/thierrykoblentz"
					class="imgExt">
			
			</a>
			<div
					class="bd">         @thierrykoblentz 14 minutes ago     </div>
			</div>

Css

We will add a right floating style to the links and modify theirmarginvalues:

.media
			{     margin:
									10px;
					}
			.media, .bd
			{     overflow: hidden;
					_overflow: visible;
					zoom:
									1;
					}
			.media
			.img
			{     float: left;
					margin-right:
									10px;
					}
			.media
			.img
			img
			{     display: block;
					}
			.media
			.imgExt
			{     float: right;
					margin-left:
									10px;
					}

Results

The image is now displayed on the other side:

When another requirement arises

Let's say we now need to set the text smaller on the normal page. To do this, we create a new rule that uses#rightRailthe selector as the context:

Template structure

Our module is now placed in adiv#rightRailcontainer:

<div
					id="rightRail">
			<div
					class="media">
			<a
					href="http://twitter.com/thierrykoblentz"
					class="img">
			
			</a>
			<div
					class="bd">             @thierrykoblentz 14 minutes ago         </div>
			</div>
			</div>

Css

Once again, we create an extra rule that uses the descendant selector this time#rightRail .bd:

.media
			{     margin:
									10px;
					}
			.media, .bd
			{     overflow: hidden;
					_overflow: visible;
					zoom:
									1;
					}
			.media
			.img
			{     float: left;
					margin-right:
									10px;
					}
			.media
			.img
			img
			{     display: block;
					}
			.media
			.imgExt
			{     float: right;
					margin-left:
									10px;
					}
			#rightRail
			.bd
			{     font-size: smaller;
					}

Results

Here is our original module, shown indiv#rightRail:

What's wrong with this module?

• changing a simple style to a module in a style sheet can give you a new effect : there must be a way to write more CSS rules for the style style that you need.
• A combination selector is a common style (.media,.bd{}): Using a combination selector instead of using a class to define the same style, resulting in more CSS.
• we have six rules, and four rules are based on context : Context-sensitive rules are difficult to maintain. Styles are not reusable with these rules.
• RTL and LTR interfaces become complex : change direction, we need to cover some of our styles (that is, write more rules). For example:

.rtl
			.media
			.img
			{     margin-right: auto;
					/* reset */
					float: right;
					margin-left:
									10px;
					}
			.rtl
			.media
			.imgExt
			{     margin-left: auto;
					/* reset */
					float: left;
					margin-right:
									10px;
					}

Meet atomic cascading Style sheets

A Tom IC: units in a component make up a larger system.

As we all know, the smaller the unit, the more reusable it can be.

Think of code as Lego. The code can be broken into small pieces. --@csswizardry (Via@stubbornella) #btconf

By breaking styles into blocks of cells, we can map the blocks of cells to a single class in a style, not a lot. This rule will result in a finer-grained rule, which in turn improves reusability.

Let's reconsider the media's use of this new method.

Template structure

We used five class names and none of the classes were content-related:

<div
					class="Bfc M-10">
			<a
					href="http://twitter.com/thierrykoblentz"
					class="Fl-start Mend-10">
			
			</a>
			<div
					class="Bfc Fz-s">         @thierrykoblentz 14 minutes ago     </div>
			</div>

Css

Each class is associated with a specified style. In most cases, this means that we have a declaration rule.

.Bfc
			{     overflow: hidden;
					zoom:
									1;
					}
			.M-10
			{     margin:
									10px;
					}
			.Fl-start
			{     float: left;
					}
			.Mend-10
			{     margin-right:
									10px;
					}
			.Fz-s
			{     font-size: smaller;
					}

Results

How about this?

Now we are ignoring the class name and the concern is to do so (or not).

• no context style : We don't use up and down 誩 or background selectors, which means that our style has no weight.
• The direction (left and right) is "abstract": The container uses RTL rules in the style sheet, such as the following code, without overwriting the style:

.Fl-start
			{     float: right;
					}
			.Mend-10
			{     margin-left:
									10px;
					}

Similar names, same attributes, different property values.

But the most important thing to note is that we beautify the template style. We have to change the modal context style. Now edit the HTML template instead of the style sheet.

I believe this approach has changed, because it narrows it down considerably. Our style is not global, just the module and block-level style. We can change the style of a module without worrying about destroying other pages. We don't have to do anything to add any rules to this stylesheet, just create a new class name and rule:

There is no redundancy. Selectors are not duplicates, and styles are part of a single rather than another. For example, a page in a style sheet contains 72floatdeclarations.

Also, discard a style--for example, always keep the picture on the left side of the module--and that doesn't make any style rules obsolete.

Sounds good, doesn't it?

It's not blowing, is it? I heard you say, "It's against every rule of the book." This is not in line with inline styles. Your class name is mysterious, but it is also not semantically.

This is fair. Let's solve these problems.

About the class name without semantics

If you look at the skills of the Web site management of the consortium, it says "good name does not change", you will see that the argument is about maintenance, not semantics itself. Also, it's easier to modify a style in a CSS file than to modify it in multiple HTML files. If you change the style of one element and ask us to modify the declaration,.border4pxit will be a bad class name, which is associated with the name. Other words:

.border4px
			{border-width:2px;}

On the class name of semantic ambiguity

In most cases, these class name names follow the syntax of Zen Coding--View the Zen Coding character Chart (PDF)--now called Emmet. In other words, they are simple abbreviations.

About the style associated with (left and right), including a combination declaration. For example, BFC represents the block format context.

About imitating inline styles

I hope the following figure will help you clean up:

• particularity (specificity): This technique is not as@stylespecific as it is. The weight of his style is very low , because all just rely on a single class name, not like.parent .bd{}this descendant selector, choose to0.0.2.0(have about the weight of the relevant tutorials, please check the CSS specificity:things you Should Know). "The Chinese version can click on some things you should know--css weight".
• Redundancy (verbosity): Most classes use abbreviations to declare a style (for example, theM-10representation ismargin:10px). Some class names, such as a.Bfccollection of more than one style, such as the mapping portion of the previous illustration. There are other classes that usestartandenddo this in keywords, without usingleftandrightvalues (see the abstract section above).

Here are@stylesome of the advantages:

• scope: A style is a "sandbox" that connects contacts together.
• Portability (portability): because styles are encapsulated in some, you can move into modules without losing their style. Of course, we still need stylesheets, but because the context structure is not restricted, modules can be placed on any page, in the Web or even in the network.

A bloated path

Because the style of the module is directly dependent on the class name, they can achieve whatever effect we want. For example, if we need to create a simple two-column layout, all we need to do isdivreplace the original link in the template. Looks like this:

<div
					class="Bfc M-10">
			<div
					class="Fl-start Mend-10 W-25">         column 1     </div>
			<div
					class="Bfc">         column 2     </div>
			</div>

All we need to do is add an extra rule to the style sheet:

.Bfc
			{     overflow: hidden;
					zoom:
									1;
					}
			.M-10
			{     margin:
									10px;
					}
			.Fl-start
			{     float: left;
					}
			.Mend-10
			{     margin-right:
									10px;
					}
			.Fz-s
			{     font-size: smaller;
					}
			.W-50
			{     width:
									50%;
					}

Compared with traditional methods:

<div
					class="wrapper">
			<div
					class="sidebar">         column 1     </div>
			<div
					class="content">         sidebar     </div>
			</div>

Here we need to create three new class names, add an extra style rule and Group selector:

.wrapper, .content, .media, .bd
			{     overflow: hidden;
					_overflow: visible;
					zoom:
									1;
					}
			.sidebar
			{     width:
									50%;
					}
			.sidebar, .media
			.img
			{     float: left;
					margin-right:
									10px;
					}
			.media
			.img
			img
			{     display: block;
					}

I think the code above is a good demonstration of the SOC principle. In my experience, it just adds a style sheet size.

In addition, the larger the file, the more it consists of complex rules and selectors. Then no one dares to edit an existing style rule:

• We are afraid to modify the style rules, fearing that modifying the existing style rules will destroy something.
• Instead of modifying existing style rules, we can only create new style rules because we are not sure that the latter is 100% secure.

In other words, we make things worse because we make the files more and more bloated.

Nowadays, people are accustomed to very large style sheets, and many programmers think they are familiar with their fields. Instead of thinking about reducing the bloat, they use tools such as preprocessor to help them deal with it. Chris Eppstein tells us:

LinkedIn has over 1100 sass files (230K lines per scss file) and more than 90 developers writing sass each day.

CSS bloated contrast HTML bloated

Let's face them together: the data must right side the place. Consider the following two types of structure

<div
					class="sidebar">
			<div
					class="Fl-start Mend-10 W-25">

In many cases, the semantically typed class name uses more bytes (.wrapperand comparisons) than the class name of the table image.Bfc. But I don't think it's a really worrying problem, and in contrast, most applications now usedata-attributes.

This is the benefit of gzip coming in because the high redundancy class name will get better compression throughout the document. The same applies to style sheets, where we have a lot of redundant styles:

.M-1
			{margin:
									1px;}
			.M-2
			{margin:
									2px;}
			.M-4
			{margin:
									4px;}
			.M-6
			{margin:
									6px;}
			.M-8
			{margin:
									8px;}

Cache

The rules on the surface do not change. The style sheet is made of these sophisticated toolset, and the author can find everything they need. Through their characteristics, they stop enlarging the file and become immutable. And immutable is the most user-friendly cache.

No better..buttonClass name?

The techniques discussed here do not prohibit semantic class names and rules, and group selector declaration styles. The idea is simply to evaluate the benefits of commonly used methods, rather than using it as a de facto technique to beautify a Web page. In other words, we are a few cases of restricting the "component" approach, which is very meaningful.

For example, you may find that our stylesheet has the following rules. These rules set our style, we do not create simple classes or rules to ensure cross browsing support.

. button {Display:inline-block;
					*display:inline;
					Zoom:1;
					Font-size:bold 16px/2em Arial;
					Height:2em;
					Box-shadow:inset 1px 1px 2px 0px #fff;
					Background:-webkit-gradient (linear, left top, left bottom, color-stop (0.05, #ededed), Color-stop (1, #dfdfdf));
					Background:linear-gradient (center top, #ededed 5, #dfdfdf 100%);
					Filter:progid:DXImageTransform.Microsoft.gradient (startcolorstr= "#ededed", endcolorstr= "#dfdfdf");
					Background-color: #ededed;
					Color: #777;
					Text-decoration:none;
					Text-align:center;
					text-shadow:1px 1px 2px #ffffff;
					border-radius:4px;
					border:2px solid #dcdcdc;
					}. Modal {position:fixed;
					top:50%;
					left:50%;
					-webkit-transform:translate ( -50%,-50%);
					-ms-transform:translate ( -50%,-50%);
					Transform:translate ( -50%,-50%);
									*width:600px;
					*margin-left: -300px;
					*top:50px;
					} @media \0screen {. modal {width:600px;
					Margin-left: -300px;
					top:50px;  } }

On the other hand, you will see the rules listed below in the style (that is, the style is bound to a particular module), because I like to use the same style with multiple classes: one for font size, color, one for floating, and so on.

.news-module
			{     font-size:
									14px;
					color:
									#555;
					float: left;
					width:
									50%;
					padding:
									10px;
					margin-right:
									10px;
					}
			.testimonial
			{     font-size:
									16px;
					font-style: italic;
					color:
									#222;
					padding:
									10px;
					}

Do we include all the possible styles in our style sheet?

The idea is to have a rule where the author can choose whatever style they want. Cross-site style styles are common enough to make these styles a part of a style sheet. If a style is too specific, then we will rely on@style(style attributes). In other words, we would rather modify the tag than the stylesheet. The main purpose is to create a rule table to solve various design patterns. For example,floatthe basic rules of an element can be addedhelperto a class name to complete.

/** * One liner with ellipsis * 1. We inherit hyphens:auto from the body, the which would break "Ell" in table cells * *.
					Ell {max-width:100%;
					White-space:nowrap;
					Overflow:hidden;
					Text-overflow:ellipsis;
					-webkit-hyphens:none;
					* * 1/-ms-hyphens:none;
					-o-hyphens:none;
					Hyphens:none; }/** * Kinda Line-clamp * Two lines according to default font-size and Line-height * *.
					Lineclamp {display:-webkit-box;
					-webkit-line-clamp:2;
					-webkit-box-orient:vertical;
					font-size:13px;
					line-height:1.25;
					max-height:32px;
					_height:32px;
					Overflow:hidden; }/** * reveals an hidden element on:hover Or:focus * Visibility can is forced by applying the class "revealnested-" On "* ie8+ * *: Root.
					Nestedhidden {opacity:0; }: Root. Nestedhidden:focus,: Root. Revealnested:hover.
Nestedhidden,: Root			. Revealnested-on.
					Nestedhidden {opacity:1;
		 }

How about this size?

We have just released a brand new My Yahoo, which relies heavily on this technology. This is its comparison with other Yahoo products (gzip compressed):

Our stylesheet is about 17.9kb in size (about 3KB is resizable) and it is shareable (with other attributes of the style sheet). The reason is that no rule contains the content.

End

Because the class name of the image is always considered "out of bounds", we and the community do not really investigate their use needs. In fact, in the name of best practice, we have dismissed every opportunity to explore our potential benefits.

At Yahoo, @renatoiwa, @StevenRCarlson and I am developing a project that uses this new CSS architecture. "Chinese version, you can click here to read". The code appears to be predictable, reusable, maintainable, and extensible. So far, these are the results we have experienced:

• less bloated: We can create an entire module without adding a single line of styles to the style sheet.
• Rapid development: styles are controlled by content-independent classes, so we can copy and paste existing modules.
• Free RTL Interface: usestartandendkeywords have great meaning. It omitted for us the writing of additional style rules for the context RTL.
• Good caching: a large number of CSS can be shared across products and properties.
• Very small maintenance (CSS aspect): There is only one set of small style rules that change over time.
• less Abstract: There is no need to find a template's style rule in a style sheet. This is all the markings.
• third-party development: A third party can apply a template to a project without attaching a stylesheet (or a style block). There is no custom rule, which means that the third party does not break the rules and that there is no proper namespace.

Note that maintaining CSS is easier than maintaining HTML in terms of maintenance, so it's simple that we can do no styling cleanup in CSS. But if we have to keep it simple, then we also face some painful things.

Finally note

A couple of weeks ago, I heard Colt Mcanlis say "tools, not rules", fast search returns this word:

 

We all need new knowledge, new methods, new best practices, and I We need to be able to share them.

 

Translator Sign Language: the entire translation according to the original line, and in the translation process slightly individual understanding of the technology. If the translation has the wrong place, but also please peer friends pointing. Thank you!

If you want to reprint, please indicate the source:

English Original: http://coding.smashingmagazine.com/2013/10/21/ challenging-css-best-practices-atomic-approach/

Chinese translation: htpp://www.w3cplus.com/css/ challenging-css-best-practices-atomic-approach.html