Shulou(Shulou.com)06/03 Report--

This article introduces the relevant knowledge of "what programming specifications does CSS have". In the operation of actual cases, many people will encounter such a dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

When participating in large-scale, long-lasting, and large-scale projects, it is extremely important for all developers to follow the following rules:

Keep CSS easy to maintain

Keep the code clear and easy to understand

Maintain the extensibility of CSS

In order to achieve this goal, we have to adopt many methods.

The first part of this document will explore grammar, format, and analyze the structure of CSS; the second part will focus on methodology, thinking framework, and views on writing and planning CSS.

CSS document analysis

No matter what documentation we write, we should maintain a unified style, including unified comments, unified syntax, and unified naming conventions.

General principles

Keep the line width below 80 bytes. Gradient-related syntax and URL in comments can be regarded as exceptions, after all, there is nothing we can do about this part.

I prefer to use four spaces instead of Tab indentation and split the declaration into multiple lines.

Single file and multiple files

Some people like to write everything in one file, but after I migrated to Sass, I began to split the style into multiple small files. This is all very good practice. Whichever you choose, the following rules will apply, and you won't have any problems if you follow them. The only difference between the two is the catalog and block title:

Catalogue

At the beginning of CSS, I maintain a directory, like this:

CSS Code copies content to the clipboard

/ *-*

$CONTENTS

\ *-* /

/ * *

* CONTENTS.You're reading it!

* RESET.Set our reset defaults

* FONT-FACE.Import brand font files

, /

This directory can tell other developers exactly what is contained in this file. Each item in this catalog is the same as its corresponding block title.

If you are maintaining a single file CSS, the corresponding blocks will also be in the same file. If you are writing a set of small files, each item in the directory should correspond to the corresponding @ include statement.

Block title

The catalog should correspond to the title of the block. As follows:

CSS Code copies content to the clipboard

/ *-*

$RESET

\ *-* /

The block title prefix $allows us to limit our search to the block title when we use the [Cmd | Ctrl] + F command to find the title name.

If you are maintaining a large file, leave five lines between blocks, as follows:

CSS Code copies content to the clipboard

/ *-*

$RESET

\ *-* /

[Our

Reset

Styles]

/ *-*

$FONT-FACE

\ *-* /

The gaps in these chunks help distinguish blocks when flipping quickly in large files.

If you are maintaining multiple CSS connected by include, put a title in the header of each document. There is no need for such a blank line.

Code order

Try to write rules in a specific order, which will ensure that you make the most of the meaning of the first C in CSS: cascade, cascading.

A well-planned CSS should be arranged as follows:

The Root of everything in Reset

Element types do not have class H2, ul, etc.

The most general and basic design patterns of objects and abstract content

All extensions extending from an object and their child elements

Patch for abnormal state

In this way, when you write CSS in turn, each block can automatically inherit the attributes of the block before it. In this way, you can reduce the parts of the code that cancel each other out, reduce some special problems, and form a better CSS structure.

For more information on this, Jonathan Snook's SMACSS is highly recommended.

CSS style set analysis

CSS Code copies content to the clipboard

[selector] {

[property]: [value]

[]

}

[selector] {

[attribute]: [value]

[]

}

When writing CSS styles, I am used to following these rules:

Class names are concatenated with a hyphen (-), except for the BEM nomenclature mentioned below

Indent 4 spaces

The declaration is split into multiple lines

Statements are arranged in relevance rather than alphabetical order

Prefixed declarations are indented appropriately to align their values

Indent the style set to reflect DOM

Keep the semicolon at the end of the last declaration.

For example:

CSS Code copies content to the clipboard

.widget {

Padding:10px

Border:1px solid # BADA55

Background-color:#C0FFEE

-webkit-border-radius:4px

-moz-border-radius:4px

Border-radius:4px

}

. widget-heading {

Font-size:1.5rem

Line-height:1

Font-weight:bold

Color:#BADA55

Margin-right:-10px

Margin-left:-10px

Padding:0.25em

}

We can find that. Widget-heading is a child element of .widget because the style set of the former is indented one more level than the latter. In this way, indentation allows developers to quickly get such important information when reading the code.

We can also find that. Widget-heading 's declarations are arranged according to their relevance:. Widget-heading is an interline element, so let's add font-related style declarations first, followed by others.

The following is an example that is not split into multiple lines:

CSS Code copies content to the clipboard

.t10 {width:10%}

.t20 {width:20%}

.t25 {width:25%} / * 1Acer 4 * /

.t30 {width:30%}

.t33 {width:33.333%} / * 1Acer 3 * /

.t40 {width:40%}

.t50 {width:50%} / * 1Acer 2 * /

.t60 {width:60%}

.t66 {width:66.666%} / * 2Acer 3 * /

.t70 {width:70%}

.t75 {width:75%} / * 3ax 4pm /

.t80 {width:80%}

.t90 {width:90%}

In this example (from inuit.css's table grid system), putting CSS on one line makes the code more compact.

Naming convention

I usually concatenate class names with a hyphen (-) (for example. Foo-bar instead of .foo _ bar or .foobar), but I use the BEM (Block, Element, Modifier) naming method at certain times.

BEM naming can make selectors more standardized, clearer, and more semantic.

The nomenclature follows the following format:

CSS Code copies content to the clipboard

.block {}

.block _ _ element {}

.block-- modifier {}

Where:

.block represents some basic abstract element

.block _ _ element represents a child element that makes up .block

.block-- modifier represents a different state or version of .block.

For example:

CSS Code copies content to the clipboard

.person {}

.person-- woman {}

.person _ _ hand {}

.person _ _ hand--left {}

.person _ _ hand--rightright {}

The basic element we describe in this example is a person, and then that person may be a woman. We also know that people have hands, which are part of the human body, and hands have different states, like the left hand and the right hand.

In this way, we can delimit the namespace of the selector according to the parent element and communicate the function of the selector, for example, according to whether the selector is a child element (_ _) or the different state of its parent element (-).

Thus,. Page-wrapper is an independent selector. This is a canonical name because it is not a child of other elements or other states; however, .widget is associated with other objects, it should be a child of .widget, so we should rename it to .widget _ _ heading.

BEM naming is not very good-looking and quite lengthy, but it allows us to quickly learn about the functions of elements and the relationships between elements by name. At the same time, the repetitive part of BEM syntax is very beneficial to gzip compression algorithm.

Whether you use BEM naming or not, you should make sure that class is properly named, and that you abstract element naming to improve reusability (for example,. Ui-list,.media). Child elements should be named as accurately as possible (for example, .user-avatar-link). Don't worry about the number or length of class names, because well-written code gzip can also be effectively compressed.

Class in HTML

To ensure readability, separate the class name with two spaces in the HTML tag, for example:

XML/HTML Code copies content to the clipboard

The additional spaces should make it easier to read and locate when using multiple class.

JavaScript hook

Do not use a marked CSS-style class as an JavaScript hook. Mixing JS behaviors with styles will not be handled separately.

If you want to bind JS to certain tags, write a class specific to JS. To put it simply, delimit a namespace with the prefix .js -, such as .js-toggle,.js-drag-and-drop. This means that we can bind both JS and CSS through class without causing trouble because of conflicts.

XML/HTML Code copies content to the clipboard

The tag above has two class, and you can use one of them to style the sortable column and the other to add sorting.

I18n

Although I (Harry Roberts, the original author of the CSS Guideline document) is an Englishman, and I have always spelled colour instead of color, I think it is better to use American spelling in CSS for the sake of unity. CSS and most other languages are written in American spelling, so there is a lack of uniformity if you write color:red in. Colour-picker {}. I used to advocate using two spellings at the same time, such as:

CSS Code copies content to the clipboard

. color-picker

. colour-picker {

}

But I recently worked on a large Sass project with a lot of color variables (such as $brand-color,$highlight-color, etc.). It's hard to maintain two spellings for each variable, and it takes twice as much work to find and replace.

So in order to unify, name all class and variables after the usual spelling of the project you are involved in.

Notes

I use document block style comments with a line width of no more than 80 bytes:

CSS Code copies content to the clipboard

/ * *

* This is a docBlock style comment

*

* This is a longer description of the comment, describing the code in more

* detail. We limit these lines to a maximum of 80 characters in length.

*

* We can have markup in the comments, and are encouraged to do so:

*

Lorem

*

* We do not prefix lines of code with an asterisk as to do so would inhibit

* copy and paste.

, /

/ * *

* this is a DocBlock style comment.

*

* this starts with a more detailed and longer comment text. Of course, we need to limit the line width to 80 bytes.

*

* We can embed HTML tags in comments, and this is also a good idea:

*

Lorem

*

* if it is an embedded tag in the comment, do not precede it with an asterisk so as not to be copied into it.

, /

The code should be described in as much detail as possible in the comments, because what is clear to you may not be the case for others. Every part of the code is written with comments to explain it in detail.

Extended usage of annotations

Comments have many advanced uses, such as:

Quasi-modified selector (Quasi-qualified selectors)

Code label

Inheritance tag

Quasi-modified selector (Quasi-qualified selectors)

You should avoid overdecorating selectors, for example, if you can write .nav {}, try not to write ul.nav {}. Excessive modification of the selector will affect the performance, affect the class reusability, and increase the privacy of the selector. These are all things you should try your best to avoid.

But sometimes you may want to tell other developers the scope of class. Take the. product-page as an example, this class looks like a root container, which may be a html or body element, but the. product-page alone cannot tell.

We can describe our planned scope of class by adding a quasi-modifier before the selector (that is, commenting out the previous type selector):

CSS Code copies content to the clipboard

/ * html*/.product-page {}

In this way, we can accurately know the scope of the class without affecting reusability.

Other examples include:

CSS Code copies content to the clipboard

/ * ol*/.breadcrumb {}

/ * p*/.intro {}

/ * ul*/.image-thumbs {}

In this way, we can know the scope of class without affecting the code privacy.

Code label

If you have written a new set of styles, you can tag it, for example:

CSS Code copies content to the clipboard

/ * *

* ^ navigation ^ lists

, /

.nav {}

/ * *

* ^ grids ^ lists ^ tables

, /

.matrix {}

These tags allow other developers to quickly find the relevant code. If a developer needs to find parts related to the list, he can quickly locate .nav, .matrix and other related parts by searching ^ lists.

Inheritance tag

If you apply object-oriented thinking to CSS writing, you will often find two parts of CSS that are closely related (one is based on one and the other is extension). We can use inheritance tags to establish a close relationship between the original element and the inherited element. These are written in the comments as follows:

In the basic style of the element:

CSS Code copies content to the clipboard

/ * *

* Extend `. Foo` in theme.css

, /

.foo {}

In the extension style of the element:

CSS Code copies content to the clipboard

/ * *

* Extends `. Foo` in base.css

, /

.bar {}

In this way, we can build a close connection between two pieces of code that are far apart.

Write CSS

The previous chapters focused on how to plan CSS, which are rules that are easy to quantify. This chapter will explore more theoretical things, as well as our attitudes and methods.

Write new components

When writing new components, write the HTML section before you start working on CSS. This allows you to determine exactly which CSS attributes can be inherited and avoid repeated waste.

If you write the tag first, you can focus on the data, content, and semantics, and then add the class and CSS styles you need.

Object-oriented CSS

I write code in an object-oriented CSS way. I divide components into structure (object) and appearance (extension). As analyzed below (note that this is not an example):

CSS Code copies content to the clipboard

.room {}

.room-kitchen {}

.room-bedroom {}

.room-bathroom {}

We have many rooms in the house, and they all have common parts: floors, ceilings, walls and doors. We can put these shared parts into an abstract .room {} class. But we have other rooms that are different: a kitchen may have floor tiles, bedrooms may have carpets, bathrooms may have no windows, but bedrooms will have, and the walls of each room may be different. The idea of object-oriented CSS enables us to abstract the same part into the structural part, and then use a more specific class to expand these features and add special processing methods.

So instead of writing a large number of different modules, efforts should be made to find repeated design patterns in these modules and abstract them into a reusable class that can be used as a basis and then write special cases of other extension modules.

When you want to write a new component, split it into structure and appearance. Use the most generic class to ensure reusability when writing structural parts, and use more specific class to add design methods when writing appearances.

Overall Arrangement

All components do not declare width, but are determined by their parent elements or grille system.

Never declare height. Height should only be used for things whose dimensions are already fixed, such as pictures and CSS Sprite. Height should not be declared on elements such as pforce _ ulre _ div. You can use a more flexible line-height if necessary.

The grille system should be understood as a bookshelf. It is they that hold the content, rather than putting it together as content, just as you put up the bookshelf and then put it in. Separating the grille system from other attributes of the elements is more helpful to the layout than declaring their size, and also makes our front-end work more efficient.

You shouldn't add any styles to the grille system, they're just for layout. Add styles inside the grille system. Do not add box model related properties in any case in the grille system.

UI size

I set the UI size in many ways, including percentage, px,em,rem and simply nothing.

Ideally, the grille system should be set as a percentage. As mentioned above, because I use the grille system to fix the column width and page width, I can ignore the size of the element.

I use rem to define font size and use px to make it compatible with older browsers. This can have the advantages of both em and px. Here is a very beautiful Sass Mixin, which can be used to generate rem and px compatible with old browsers if you declare the basic font size (base-font-size) elsewhere.

CSS Code copies content to the clipboard

@ mixin font-size ($font-size) {

Font-size:$font-size + px

Font-size:$font-size / $base-font-size + rem

}

I only use px on elements that are already fixed in size, including pictures and CSS Sprite whose dimensions have been fixed with px.

Font size

I will define some class similar to the principle of the grille system to declare the font size. These class can be used for double headings. For this, please read Pragmatic, practical font-sizing in CSS.

Abbreviated

The abbreviation CSS should be used with caution.

It's easy to write attributes like background: red;, but you actually mean to declare background-image: none; background-position: top left; background-repeat: repeat; background-color: red; at the same time. Although most of the time there will be no problem, but even if there is only one problem, it is worth considering whether to give up the abbreviation or not. This should be changed to background-color: red;.

Similarly, statements like margin: 0; are really concise and refreshing, but they should be written as clearly as possible. If you just want to change the bottom margin, be more specific and write it as margin-bottom: 0;.

At the same time, the attributes you need to declare should also be clearly written, so that other attributes should not be affected by shorthand. For example, if you only want to change the margin at the bottom, don't use margin: 0, which will clear the other margins as well.

Although the abbreviation is good, it is also easy to abuse.

ID

Before we start dealing with selectors, keep this in mind:

Never use ID in CSS.

In HTML, ID can be used for JS and anchor positioning, but in CSS you only need to use class, not even an ID.

The advantage of Class lies in its reusability and low degree of privacy. Privacy can easily lead to problems in a project, so it is particularly important to reduce it. ID is 255 times more private than class, so never use it in CSS.

Selector

Be sure to keep the selector short and efficient.

Selectors located by the location of page elements are not ideal. Selectors such as .sidebar h4 span {} are so dependent on relative positions that it is difficult to maintain their style if you move span outside h4 and sidebar.

Complex selectors will affect performance. The more complex the selector structure (for example, .sidebar h4 span has three layers and the. content ul pa is four layers), the more expensive the browser will be.

Try to make the style independent of its positioning, and try to keep the selector simple and clear.

As a whole, selectors should be as short as possible (for example, there is only one layer of structure), but class names should not be too brief, for example,. User-avatar is much better than. Usr-avt.

Keep in mind that class doesn't matter whether they are semantic or not; you should pay attention to whether they are reasonable. Don't emphasize that class names should be semantic, but focus on using names that are reasonable and not out of date.

Over-modified selector

As mentioned earlier, over-modified selectors are not ideal.

Over-decorated selectors are those like div.promo. There's a good chance you can get the same effect with .promo. Of course, you may occasionally need to decorate class with element types (for example, you write a .error and want it to display differently in different element types, such as .error {color: red;} div.error {padding: 14px;}), but most of the time you should try to avoid it.

Take another example of an overdecorated selector, ul.nav li a {}. As mentioned earlier, we can delete ul immediately because we know that .nav is a list, and then we can find that a must be in li, so we can rewrite the selector to .nav a {}.

Selector performance

Although the performance of browsers is improving and CSS rendering is getting faster and faster, you should still focus on efficiency. This problem can be avoided by using a short, non-nested selector instead of a global selector (* {}) as the core selector, avoiding the increasingly complex new CSS3 selector.

Translation note, core selector: the browser parsing selector is in the order from right to left, and the rightmost element is the element in effect of the style, which is the core selector.

The purpose of using the CSS selector

Rather than trying to navigate to an element with a selector, it's better to add a class directly to the element you want to style. Let's take a selector like .header ul {} as an example.

Suppose this ul is the site-wide navigation for this site, it is located in header, and so far it is the only ul element in header. Header ul {} does work, but it's not a good way to do it. It's easily obsolete and obscure. If we add another ul to header, it will apply the style we wrote for the navigation section, even if that's not what we envisioned. This means that we either have to ReFactor a lot of code or write a lot of new styles for the later ul to offset the previous impact.

Your selector must match the reason why you want to add style to this element. Think about it, "did I locate this element because it's a ul under .header, or because it's my site navigation?" "this will determine how you should use the selector.

Make sure your core selector is not a type selector, nor is it an advanced object or abstract selector. For example, you will not find selectors such as .sidebar ul {} or .footer .media {} in our CSS.

Express clearly: go straight to the element you want to add the style to, not its parent element. Don't take it for granted that HTML won't change. Use CSS to directly hit the elements you need, rather than opportunistic.

! important

Use! important only on auxiliary class. It is also possible to use! important to raise the priority, for example, if you want to keep a rule in effect, you can use .error {colorRedimportance;}.

Avoid active use! important. For example, don't use CSS when it is complex, organize and ReFactor the previous parts, keep the selector short and avoid using ID to pull out the effect.

Magic number and absolute Positioning

Magic numbers (Magic Number) are those numbers that "happen to be effective". It is very bad to use magic numbers because they only cure the symptoms rather than the root causes and lack expansibility.

For example, using. Dropdown-nav li:hover ul {top: 37px;} to move down the drop-down menu is far from a good idea, because the 37px here is a magic number. The reason why 37px works is that. Dropbox-nav happens to be higher than 37px at this time.

At this point, you should use. Dropdown-nav li:hover ul {top: 100%;}, that is, no matter how high the dropbox-down is, the drop-down menu will move down 100%.

Whenever you want to put numbers in your code, think twice. If you can replace it with a keyword (for example, top: 100%, which means "pull from top to bottom"), or if you have a better solution, try to avoid direct numbers.

Every number you leave in CSS is a promise you make that you don't want to keep.

Conditional judgment

Styles written specifically for IE are basically avoidable, and the only thing that needs to be handled specifically for IE is to deal with content that IE does not support (such as PNG).

In short, if you ReFactor CSS, all layouts and box models don't have to be extra compatible with IE. In other words, you basically don't use or similar compatible IE writing.

Debugging

If you want to solve the CSS problem, remove the old code before you write a new one. If there is a problem with the old CSS, writing new code will not solve it.

Delete the CSS code and HTML until there is no BUG, and then you will know what the problem is.

Sometimes writing an overflow: hidden or other code that hides the problem does have an immediate effect, but there may be no problem with overflow at all. Therefore, it is necessary to get to the root of the problem, not simply cure the symptoms.

CSS preprocessor

I use Sass. It should be used flexibly. Using Sass can make your CSS more powerful, but don't nest it too complicated. In Vanilla CSS, you can only use nesting where necessary, for example:

CSS Code copies content to the clipboard

.header {}

.header. Site-nav {}

.header. Site-nav li {}

.header. Site-nav li a {}

This method of writing is completely useless in ordinary CSS. The following is a bad way to write Sass:

CSS Code copies content to the clipboard

.header {

. site-nav {

Li {

A {}

}

}

}

If you use Sass, try to write:

CSS Code copies content to the clipboard

.header {}

. site-nav {

Li {}

A {}

}

This is the end of the content of "what are the programming specifications for CSS". Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.