For example :. w100 {width: 100px ;}. w200 {width: 200px ;}. w300 {width: 100px ;}. m100 {margin: 100px ;}. m200 {margin: 200px ;}. m300 {margin: 300px ;}...... My understanding is: Since labels need to be semantic, the class id should also be semantic rather than completely serving the style. It is very convenient to do so, for example :. w100 {width: 100px ;}. w200 {width: 200px ;}. w300 {width: 100px ;}. m100 {margin: 100px ;}. m200 {margin: 200px ;}. m300 {margin: 300px ;}......
My understanding is: Since labels need to be semantic, the class id should also be semantic, rather than completely serving the style. It is true that this is very convenient to reply to the content: I think your .w100s should refer to the basic sample file (such as base.css) is there a general atomic class in it?
This is a good question.
Please read bin GO's article "CSS code naming convention semantic method" http://blog.bingo929.com/css-coding-semantic-naming.html first
In addition, please refer to my article "semantic again" http://ued.ctrip.com/blog? P = 2735
Semantics is divided into the semantics of html tags and css naming. Here you refer to the semantics of CSS naming.
. W100 defines a general attribute with a width of 100 PX, which can be easily attached to a module with a width. However, let's take a look at how to change the width to 200 once the demand changes? Or change to 250? In this case, you want to modify the class name in the prototype html? Obviously, this is not consistent with our original intention. Since we put CSS in a single file, we expect that the style is separated from html for easy maintenance. Once the appearance style changes, we can modify the prototype file to a minimum, you can directly modify the style.
Bin GO has a good summary: semantic naming, rather than structured naming. (It seems inappropriate at present)
Of course, this method abstracts general attributes to the maximum extent, which can save some CSS redundant code, but this is only applicable to projects with few changes in the future, that is, it is determined that this module will not change in the later stage of 100.
In another sentence, there is no silver bullet in the front-end technology, there is no best method, and there is only the most appropriate method.
--------------------------------
PS: Thanks @ He Shijun for pointing out that the "structured naming" is incorrect, because it may be a general atomic class such as "color-red, the "structured name" only refers to the name of the CSS box model. I hope this will not mislead you. "Style description naming" is more reasonable.
That's right. This is against the semantic requirement. I have criticized this widely spread anti-pattern many times. Please read these blogs in sequence:
Http://hax.iteye.com/blog/497338
Http://hax.iteye.com/blog/500015
Http://hax.iteye.com/blog/849826
In fact, it is still necessary to follow the project, and it cannot be said that this method is good or bad.
For example, projects that require rapid output and basically do not require post-maintenance (such as activity pages and news pages ). The efficiency of this pre-defined style method is very high.
Fuzzy naming is suitable for projects with a large amount of time to be optimized, or projects with a large volume to be precisely maintained.
Bootstrap basically belongs to the former.
As said by Zhiyou, NO. It can be clearly viewed during maintenance by many people, but it is not very good:
For example, if I want to change this. m100 to margin: 110px, what should I do?
Do you want to replace all. m100 used with. m110, or change the content in css without changing the name? Isn't that so ambiguous.
My suggestion (of course, you can set the name as needed ):
. W100->. w-narrow
. W200->. w-normal
. W300->. w-wide
. M100->. m-near
. M200->. m-normal
. M300->. m-far
In this way, you can maintain a clear view during deployment and make modifications flexibly.
---------------
In my personal understanding, the so-called semantics is to better understand and maintain the code service, and is not mandatory (and only for HTML ).
On the premise of being as efficient and beautiful as possible, as long as your id and class are not meaningless symbols such as p1, p2, and p3. I personally think that this practice is indeed a deep coupling between style names and HTML structures, but development and maintenance require efficiency, rather than simply pursuing pure semantics and decoupling, the final solution is a trade-off. We need to understand what the ultimate goal of design and development is. This is a tough problem. This writing method can reduce the amount of code, but it requires the cooperation of many people, such as vision, and the requirement should be determined. In case the requirement is modified, congratulations... So I don't know what the book was written with caution. I really don't know what the meaning of. w100 {width: 100px;} is. What is the abstraction of this class? If the width is 150, will the class name be changed to w150? In this case, what is the purpose of this atomic class?
The class name and id need to be semantic. If your product finds that such purely expressive classes are needed, I think they are not well designed. I 'd like to discuss the question about front-end modularization before, but I didn't expect anyone to ask me as much as possible. I also share some of my views by the way:
- Why do we need CSS semantics? If you want to use it, you should at least know the reason. You can't use it because "XX book says you want to use it like this", so I also use it like this. I personally think that in the early stages of CSS development, some people prefer to use "style information" to name selector, that is, redBox and floatArea. In this case, it is obvious that it does not meet the development needs, that is, the requirements may be changed later as mentioned by @ interjc. Therefore, we began to recommend the use of comparative semantic selector. In this way, even if the demand is changed, semantic conversion is the development trend of html and css, it is also paving the way for the later stage (where the "Most semantic" should be micro-format: http://microformats.org/).
- Why should we use modular writing? I remember reading a book "Web Front-end development practices" (http://book.douban.com/subject/4881987/The author seems to be a great guy at the front-end of Sina at the time, and he mentioned it in it. mt10 ,. fl and other selectors to split a semantic selector, which can reduce the overall amount of code. In addition, css of large websites can be divided into modular structures by using MVC design ideas.
- Does modular writing and css semantics conflict? I personally agree with @ Gu Lingling. According to my straightforward words, this means: do not simply pursue "semantic". All the knowledge you have learned is to serve the project.
- My current personal project experience does not conflict with semantics using this modular writing method. I usually use semantic writing in a relatively large area, and modular writing for labels with no more than two layers of nesting. The difference between what you start and what you finally build is always the same (that is, as mentioned by @ ). As a front-end development engineer, you can change it later, CSS (if html is already nested with the background-related code, it may be a little difficult to modify it). If it is completely modularized, it cannot meet the requirements of later stages; if you use semantic notation, more selectors will be added (for example, you only need to display the word in red ).
Semantics is only related to the HTML content and URL address. It mainly refers to the content in the head tag and the tag name, cascade relationship, and order of the content in the BODY tag.
Semantics has nothing to do with the names of CSS and class, and has no direct relationship with JS (except that AJAX-based webpages are located by using the hash addresses in URLs in GOOGLE ). If the project is finalized and rarely moved, you can use it. If the project changes a lot, it will be too difficult to change it! There are advantages and disadvantages. I have learned this before. Therefore, we recommend that you keep a few frequently used items. There is no need for w1 to w100 or something. It is too broken and many of them will not be used!
