CSS team spirit: CSS best practices team development

How many times have you taken over projects developed by others, but have you found the author's code ideas messy? Or do you work with several team members to develop code on their own? Or you can review the projects you developed many years ago. I don't remember what you thought? I always encounter this kind of thing. In fact, I spent nearly 300 hours fixing the css that the supplier provided facepalm-inducing. These 300 hours have filled me with frustration, not only because of myself, but also because of my team members. In addition, he occupies valuable time and resources that should have been spent on new projects if the supplier has followed some basic guidelines in his css. It will save him valuable time and money, not to mention that I will treat him better. In this article, you will learn to write the best practices of CSS to help you avoid inconsistencies and redundancy. In fact, developing standards in this way simplifies team development. A well-structured css is based on a good structure. This css helps me and anyone who wants to update this code in the future to better understand and quickly locate the desired style. Before writing a style, I first defined a css file structure and divided the Blocks Based on Different content on the page. Generally, these structures are common to every website: 1. header2.Navigation3. main content4.Sidebar5. footer added necessary annotations in my style file, to indicate where the style of each part starts/* --- GLOBAL --- * // * --- HEADER --- * // * --- NAV --- * // * --- CONTENT ---*//*--- SIDEBAR --- * // * --- FOOTER --- */Note that the first part of global is commented, it is not for specific content of a website, but for general styles on the website, such as layout structure, basic styles such as titles, paragraphs, lists, and links. Setting a general style in the style header helps the whole site better continue the common style and overwrite it as needed. The more css the more organizations need to create super-large websites. when processing a lot of css, I will add level-2 comments to each block. For example, in global, I define a level-2 Structure classification: /* --- GLOBAL --- * // * -- Structure -- * // * -- Typographic -- * // * -- Forms -- * // * -- Tables -- * // * --- HEADER --- * // * --- NAV --- * // * -- Primary -- * // * -- Secondary -- * // * --- CONTENT --- * // * --- SIDEBAR ---*//*--- FOOTER --- */you can also see that I added a secondary annotation to NAV, the main navigation and secondary navigation respectively. In fact, for small websites with few css, I usually do not use second-level annotations. However, for large css files, secondary annotations are proven to be useful. Free formatting the comment format you use depends entirely on you. The example you see above is my favorite method with my team. Some people also like to use two lines to define their annotation format:/* HEADER ------------------------------ */others use special characters such as '=' as the marker for search characters: /* = Header ---------------------------- */some people do not use second-level annotations. They use a completely different structure, not based on the page content, but are divided by element types such as headers, images, lists, and so on. The key is to define and use the format you like. Want to divide by content elements? No problem. If you want to make a lower-case comment, do it. Do not want to use level 2 comment indent? You don't need to use the time. You don't like to use the time to connect characters? OK. You only need to do the most meaningful things for you and your team. We have understood the structure of comments, but you should talk to your team's colleagues about how to use the comments. It is necessary to share the details of the css file that has been written between the team members. In my team, we added some summary notes for creating and updating css files in the header of the css file. /* ---- TITLE: Main screen styles | AUTHOR: EPL | UPDATED: 03/23/10 by EPL ---- */the header information is useful when processing multiple style sheets. For example, a screen, a hack for printing, or moving or even about ie. The author's information allows team members to know who to look for when css goes wrong. The updated information allows the team to understand who made the last update and the Update time. Your summary comments only need to contain useful information for your team. Skip this step if you do not need the author information. If you want to add the copyright statement. I have even seen addresses and contact information in the abstract. /* ---- IE6 screen styles (ie6.css) Company ABC 1234 Avenue of the Americas New York, NY 10020 http://companyabc.com Updated: 03/23/10 by EPL ---- */one of the most useful css comments I have ever encountered is the color value used by the website. /* --- COLORS: green # b3d88c | Blue #0075b2 | Light Gray # eee | Dark Gray # 9b9e9e | Orange # f26522 | Teal # 00a99d | Yellow # fbc112 --- */The color value is useful in the development stage, saves you time in color testing and searching from other styles. You don't need to know whether the hexadecimal value is blue. You just need to find the color value and copy and paste it. In my team, we add General color values to the css file header. We need to add a summary comment after all style declarations and annotations. We also try to keep keywords as simple and convenient as possible for maintenance, but how complicated it is depends on you. The format depends on you. You can place all defined color values in one row for display, or divide them into multiple rows for display: /* --- COLORS Green # b3d88c Blue #0075b2 Light Gray # eee Dark Gray # 9b9e9e Orange # f26522 Teal # 00a99d Yellow # fbc112 --- */Likewise, find the best format that is helpful to your needs, and maintain its consistency once defined. Development and debugging sometimes have to wander between my css and other members of the team during my development process. At this time, annotations will be used. When I sometimes think about why css has such a bug in ie, I just need to go away. You or your colleagues take notes, including possible styles and unsolved puzzles:/* -- // -- Styling for link states is pending new changes from designer, please don't edit | EPL 03/23/10 -- \ -- */a, a: link, a: visited {color: #0075b2; text-decoration: none;}: hover, a: focus, a: active {color: # b3d88c;} to make them different, I usually use a format different from other annotations, while keeping them as detailed as possible. Or use the most suitable format. </Span> remember, once you complete development and debugging, These annotations are useless. They are not related to your work or css. Their existence will only increase the size of your files. Style resetting is very popular. They appear in the header of the Style File and are used to set the basic style of html elements displayed across browsers:/* --- RESET --- */html, body, div, span, applet, object, iframe, h1, h2, h3, h4, h5, h6, p, blockquote, pre, a, abbr, acronym, address, big, cite, code, del, dfn, em, font, img, ins, kbd, q, s, samp, small, strike, strong, sub, sup, tt, var, dl, dt, dd, ol, ul, li, fieldset, form, label, legend, table, caption, tbody, tfoot, thead, tr, th, td {margin: 0; padding: 0; border: 0; outline: 0; font-weight: inherit; font-style: inherit; font-size: 100%; font-family: inherit; vertical-align: baseline;} the above example is taken from Eric Meyer's reset document, which I often use. However, I tend to remove labels that I cannot use. I suggest you do the same. For example, my team built almost no <kbd> or <iframe>, <applet>, or some of the above elements. Therefore, I remove these element selectors. Although there is only a small difference in page loading or file size, I feel this is helpful to avoid the problem of unused tags among team members. If I do not want to overwrite the built-in style of the browser, I can also edit and reset the style sheet, for example, how to handle unordered list. In this case, I make sure these elements are not included in the style sheet declaration. However, I should clarify that css resetting does not apply to everyone. You have many reasons for not using it. If you want to reset the style, keep your reset style sheet as clean and special as possible. One of the biggest headaches of naming conventions is that they encounter css written by others, and are defined class names and id names that are meaningless. For example :. f23 {background: # fff; border: 1px solid # ff0; font-weight: bold; padding: 10px;} I don't know at all. what does f23 mean. Even worse, there is no comment in any form. I don't know what. f23 represents. Is it the title? Main content? Or navigation? In this case, especially for large websites, it may waste a lot of time to find the location where the class name appears. If the author uses a name as agreed, such as those meaningful and content-based styles :. alert {background: # fff; border: 1px solid # ff0; font-weight: bold; padding: 10px;} as you can see, class name. alert provides more context information than the class name composed of a random number. It is not just context, but semantic naming can also save time. Considering the frequent change of a company's brand, if the css you develop uses the class name rather than the semantic class name and id name, when searching for and maintaining css, you will spend more time than expected. For example, if you define a bluebox class name for a piece of content on the website and use the blue tone of the company logo. Then the company reorganized. They now use the red logo, and then your. blueBox will be meaningless. Therefore, you not only need to update the hexadecimal color value of the style sheet, but also need to modify all references in the label to the blueBox. On the contrary, if you use callOut as the class name (or the same meaningful name), you will save a lot of effort. Class Name abuse in the use of css, I tend to be less or less. You cannot specify a class name for each element, which means you should specify a class name for each element. When I fixed the poor css of the vendor, I found that class names were abused and appeared in many places that were not needed. For example, each lable label defines a lable class name, and each form defines a form. However, in our design and structure, we only need to set a style for a form element, which also contains only one label element. Form. form {float: right; margin: 0; padding: 5px;} label. label {clear: both; float: left; text-align: right; width: 145px;} the resulting css itself and its redundancy are not terrible, what's terrible is his confusion. As a designer saw this form class, he may wonder if it was another style table that also defined the form class name and then searched for a style that does not exist. This is why I wasted time. The class name is not specific. The above is just a simple example. One of the more crazy examples of class names I 've encountered is the desire to give special elements <div id = "feature"> <ul> <li> <a href = "# newServices"> New services </a> </li> <a href = "# newProducts"> New Products </a> </li> </ul> </div> note the tabs class name is applied to every tag in the above structure? The following css directory list is displayed: div. tabs ul. tabs li. tabs {float: left; font-weight: bold; padding: 3px;} the simplest solution for li should be: # feature li {float: left; font-weight: bold; padding: 3px;} if you do not need a class name for the element-defined style, do not use it. Using too many class names not only makes your structure and css very bloated, but also loses their meaning in css. You may have noticed that in the final example, I only use # feature as the selector rather than div # feature. It is only appropriate to add a div to distinguish other selectors. Otherwise, it will only burden your team. In addition, we recommend that you use as few special statements as possible to cover any style in the future. At last, I don't like many categories. You may still have an impression. Although I do not advocate unnecessary and redundant class names, I am a loyal fan of retaining element performance through multiple classes. However, there may be some differences in understanding :. announcement {background: # eee; border: 1px solid #007b52; color: #007b52; font-weight: bold; padding: 10px ;}. newsAnnouncement {background: # eee; border: 1px solid #007b52; color: #007b52; float: right; font-weight: bold; padding: 10px;} the two statements above, except. newsAnnouncement has one more float, all of which are identical. So I can write the same style as below rather than repeatedly :. announcement {background: # eee; border: 1px solid #007b52; color: #007b52; font-weight: bold; padding: 10px ;}. floasd {float: right;} and then add two class names to my news content <div class = "announcement flovat"> but it is slow, didn't I say I should name the name based on the agreed name instead of the performance? Yes, but there is always an exception in everything. Yes. florecognition is a class name, but it applies to this situation and can be used in other situations that require multiple classes, so this is a frequently used method by my team. In my 300 hours of suffering, the group selector encountered another problem: identical styles appear in multiple styles, and the only difference is that their selectors are declared different: # productFeature {background: # fff; border: 1px solid # 00752b; float: left; padding: 10px ;}# contactFeature {background: # fff; border: 1px solid # 00752b; float: left; padding: 10px; }# serviceFeature {background: # fff; border: 1px solid # 00752b; float: left; padding: 10px ;} this not only makes the css file too bloated, but also makes maintenance a nightmare. The solution is to merge them into a style Declaration: # productFeature, # contactFeature, # serviceFeature {background: # fff; border: 1px solid # 00752b; float: left; padding: 10px ;} to update a style, you only need to modify one declaration instead of three. One row or multiple lines of books? All the css instances shown in this article use the multi-row format. Each pair of attributes and values occupies a single row. This is a widely used Convention, not only in css files, but also in books and articles. Many people think his readability is good, that is why I used him in this article. However, in my work with the team, especially for large css files, I write the style as one line: 1. alert {background: # fff; border: 1px solid # ff0; font-weight: bold; padding: 10px;} for me and my team, the single line is more readable. When you search for css, it becomes very troublesome to search for multiple rows. In comparison, it is easier to search for a single row. For you and your team, select the most suitable format for your team and keep using it. Do they need to be sorted alphabetically? We recommend that you sort each declaration in alphabetical order to quickly find an attribute. I didn't care about such things in the past, but after dealing with the messy css of the suppliers, I realized that applying some ideas to the style declaration organizations was a good idea. Although I found it useful to sort by alphabet, I still organize Attributes Based on context. For example, I like to put all the box model attributes together. If I use absolute positioning, I will put these attributes together: # logo {border: 1px solid #000; margin: 0; padding: 0; position: absolute; top: 5px; right: 3px;} There is no right or error here, just decide which attribute to sort and always use it. The use of css abbreviations is always a way to improve your css level. He also applies to the team, which not only facilitates browsing, but also facilitates setting standards that everyone complies. This reduces the time spent on thinking and writing styles. If you use a value of 0, you do not need to specify the unit: margin: 2px 3px 0px 4px to margin: 2px 3px 0 4px color mode hexadecimal color value if it is composed of three logarithm, you can extract a number from each group to make up the color value short: color: # ff0000 written as color: # If the margin, padding, and border values in the f00 box model attribute box model are the same, they can be combined: padding-top: 5px; padding-right: 5px; padding-bottom: 5px; padding-left: 5px merged into padding: 5px if the upper and lower values are the same as the left and right values, you only need to write two. padding: 5px 10px 5px 10px merged into padding: 5 PX 10px font attributes multiple font attributes can be merged into one font-style: italic; font-weight: bold; Font-size: 90%; font-family: Arial, Helvetica, sans-serif; merged into font: italic bold 90% Arial, helvetica sans-serif background color attribute www.2cto.com background attributes can also be merged with background-color: # fff; background-image: url(logo.png); background-repeat: no-repeat; background-position: 0 10%; merged into background: # f00 url(logo.png) no-repeat 0 10% note the last two examples, font and background attributes. The Declaration Order of attribute values must follow w3c standards. Verification, verification, and re-verification although some people think that verification css needs to specify a good verification rule, I do not force this, But he absolutely has requirements. Verify that your work is ready to be shared to other members of the team, so he should meet the following requirements: 1. easy development and troubleshooting 2. ensure that the current and future Browser display is consistent 3. ensure quick page loading 4. as part of accessibility 5. write it out correctly.