Geekly Articles each Day
📜 ⬆️ ⬇️

Google HTML / CSS Code Guide

From translator


I am pleased to have read these recommendations and now I offer you a translation.

Introduction


This guide describes the rules for formatting and formatting HTML and CSS code. Its goal is to improve the quality of the code and facilitate collaboration and infrastructure support.

This refers to working versions of files using HTML , CSS and GSS.
')
It is allowed to use any tools to minify the compilation or obfuscation of the code, provided that the overall quality of the code is preserved.


General design rules


Protocol

Do not specify a protocol when turning on resources on the page

Omit the protocol name ( http : , https:) in links to images or other media resources, style files or scripts, of course, if these files are accessible via both protocols.

The absence of a protocol makes the reference relative, which prevents the mixing of resources from different protocols and slightly reduces the file size.

Not recommended:
<script src="http://www.google.com/js/gweb/analytics/autotrack.js"></script>

Recommended:
  <script src="//www.google.com/js/gweb/analytics/autotrack.js"></script>

Not recommended:
  .example { background: url(http://www.google.com/images/example); }

Recommended:
  .example { background: url(//www.google.com/images/example); }



General formatting


Indentation

Always use two spaces to indent.

Do not use tabs and do not mix tabs with spaces.

Recommended:
  <ul> <li> <li> </ul>

Recommended:
  .example { color: blue; }



Register

Always write in lower case.

All code must be written in lower case: This refers to the element names, attribute names, attribute values ​​(except for text / CDATA ), selectors, properties and their values ​​(except text).

Not recommended:
  <A HREF="/"></A>

Recommended:
  <img src="google.png" alt="Google">



Spaces at the end of the line

Remove spaces at the end of the line.

Spaces at the end of lines are optional and complicate the use of diff.

Not recommended:
  <p>?_

Recommended:
  <p> .



General meta rules


Encoding

Use UTF-8 (without BOM).

Make sure your editor uses UTF-8 encoding without byte order mark (BOM).

Specify encoding in HTML templates and documents with <meta charset = "utf-8"> . Omit the encoding for css-files: for them UTF-8 is set by default.

(You can learn more about encodings, and how to use them at this link: Character sets and encodings in XHTML, HTML CSS (English) .)


Comments

If possible, explain your code where necessary.

Use comments to clarify your code: what it does, what it answers for, and why the selected solution is used.

(This item is optional because it makes no sense to expect that the code will always be well documented. The usefulness of commenting depends on the complexity of the project and may vary for HTML and CSS code.)


Tasks

Mark tasks for the to-do list using TODO .

Mark tasks with the TODO keyword. do not use other common formats, such as @@ .

Enclose contacts (username or mailing list) in parentheses: TODO (contact) .

Describe the task after the colon, for example: TODO: Task .

Recommended:
  {# TODO(Ivan Ivanov):    #} <center></center>

Recommended:
  <!-- TODO:    --> <ul> <li></li> <li></li> </ul>



HTML design rules


Document type

Use HTML5.

HTML5 (HTML syntax) is recommended for all html documents: <! DOCTYPE html> .

(It is recommended to use HTML with the text / html content type. Do not use XHTML, as application / xhtml + xml (English) , is worse supported by browsers and limits the possibility of optimization.)


HTML validity

If possible, use valid HTML.

Use valid HTML code, except when use does not allow you to achieve the file size required for the desired level of performance.

Use tools like W3C HTML validator (English) to check the validity of the code.

Validity is an important and yet measurable quality of the code. Writing valid HTML facilitates the study of technical requirements and limitations and ensures proper use of HTML.

Not recommended:
  <title></title> <article>

Recommended:
  <!DOCTYPE html> <meta charset="utf-8"> <title></title> <article> .</article>


Semantics

Use HTML as intended.

Use elements (sometimes incorrectly called “tags”) by purpose: headings for headings, p for paragraphs, a for links, etc.

This makes it easier to read, edit, and maintain the code.

Not recommended:
  <div onclick="goToRecommendations();">All recommendations</div>

Recommended:
  <a href="recommendations/">All recommendations</a>



Alternative for multimedia

Always specify alternative content for multimedia.

Try to specify alternative content for multimedia: for example for images, videos or animations specified using canvas . For pictures, this is a meaningful alternative text ( alt ), and for video and audio, decrypt text and captions if possible.

Alternative content can help people with disabilities. For example, it is difficult for a person with poor eyesight to understand that in the picture if @alt is not specified for it. Other people can have a hard time understanding what the video or audio recording says.

(If alt is redundant for an image, or it is used only for decorative purposes in places where CSS cannot be used, use empty alternative text alt = "" )

Not recommended:
  <img src="spreadsheet.png">

Recommended:
  <img src="spreadsheet.png" alt="Spreadsheet screenshot.">



Division of responsibility

Separate structure, design and behavior.

Keep the structure (layout), design (styles) and behavior (scripts) separately and try to minimize the interaction between them.

Make sure that documents and templates contain only HTML, and that HTML serves only to define the structure of the document. Transfer all code responsible for styling into style files, and code responsible for behavior into scripts.

Try to reduce their intersections to a minimum, including the minimum number of style files and scripts in the templates.

Separating structure from presentation and behavior helps facilitate code maintenance. Changing templates and HTML documents always takes more time than changing style files or scripts.

Not recommended:
  <!DOCTYPE html> <title>HTML sucks</title> <link rel="stylesheet" href="base.css" media="screen"> <link rel="stylesheet" href="grid.css" media="screen"> <link rel="stylesheet" href="print.css" media="print"> <h1 style="font-size: 1em;">HTML </h1> <p>     - ,     : <u>HTML -  !!1</u> <center>  ,      ,      . </center>

Recommended:
  <!DOCTYPE html> <title>My first CSS-only redesign</title> <link rel="stylesheet" href="default.css"> <h1>  CSS </h1> <p>     ,  -  :          HTML <p> !



Mnemonic links

Do not use mnemonic links.

It makes no sense to use mnemonic links, such as & mdash; , & rdquo; , or & # x263a; when all commands in files, editors use the same encoding (UTF-8)

The only exception to this rule is the HTML service characters (for example, < and & ) as well as auxiliary and “invisible” characters (for example, an unbreakable space).

Not recommended:
    : &ldquo;&eur;&rdquo;.

Recommended:
    : “€”.



Optional tags

Do not use optional tags. (not necessary)

To reduce file size and better readability of the code, optional tags can be omitted. The HTML5 specification has a list of optional tags.

(It may take some time for this approach to be used everywhere, because it is very different from what web developers usually teach. From the point of view, consistency, and simplicity of the code, it’s best to omit all the optional tags and not some of them).

Not recommended:
  <!DOCTYPE html> <html> <head> <title>  -  .</title> </head> <body> <p>.</p> </body> </html>

Recommended:
  <!DOCTYPE html> <title>-!</title> <p>-



'Type' attribute

Do not specify the type attribute when connecting styles and scripts to the document.

Do not use the type attribute when connecting styles (except for options when using something other than CSS) and scripts (except options when it is not JavaScript).

Specifying the type attribute in this case is not necessary because HTML5 uses text / css (English) and text / javascript (English) by default. This will even work in older browsers.

Not recommended:
  <link rel="stylesheet" href="//www.google.com/css/maia.css" type="text/css">

Recommended:
  <link rel="stylesheet" href="//www.google.com/css/maia.css">

Not recommended:
  <script src="//www.google.com/js/gweb/analytics/autotrack.js" type="text/javascript"></script>

Recommended:
  <script src="//www.google.com/js/gweb/analytics/autotrack.js"></script>



HTML formatting rules


Formatting

Select a new line for each block, table or list item and indent for each child element.

Regardless of the styles specified for the element (CSS allows you to change the element's behavior using the display property), move each block or table element to a new line.

Also, indent all the elements nested in a block or table element.

(If you encounter difficulties due to whitespace between list elements, it is allowed to put all li elements on one line. Lintu [the utility for checking the quality of the code of an approx. Lane] is recommended in this case to issue a warning instead of an error.

Recommended:
  <blockquote> <p><em>Space</em>, the final frontier.</p> </blockquote>

Recommended:
  <ul> <li> <li> <li> </ul>

Recommended:
  <table> <thead> <tr> <th scope="col"> <th scope="col"> <tbody> <tr> <td>$ 5.00 <td>$ 4.50 </table>



CSS design rules


CSS validity

If possible, use valid CSS code.

Except where browser dependent code is required, or validator errors, use valid CSS code.

Use tools like the W3C CSS Validator to check your code.

Validity is an important and yet measurable quality of the code. Writing valid CSS helps get rid of redundant code and ensures proper use of style sheets ...


Class IDs and Names

Use template or meaningful class names and identifiers.

Instead of using ciphers, or describing the appearance of an element, try using the name of a class or identifier to express the meaning of its creation, or give it a generic name ...

It is recommended to choose names that reflect the essence of the class, because they are easier to understand and, most likely, will not need to be changed in the future.

Template names are simply a variant of the name for elements that have no special purpose or that are not different from their brothers and sisters. Usually they are needed as “Helpers.”

Using functional or template names reduces the need for unnecessary changes to the document or templates.

Not recommended:
  /*  :    */ #yee-1901 {} /*  :    */ .button-green {} .clear {}

Recommended:
  /* :     */ #gallery {} #login {} .video {} /* :   */ .aux {} .alt {}



Names of identifiers and classes

For identifiers and classes, use names as long as necessary, but as short as possible.

Try to formulate what exactly this element should do, and be as brief as possible.

This use of classes and identifiers contributes to facilitating understanding and increasing code efficiency.

Not recommended:
  /*   */ #navigation {} .atr {}

Recommended:
  /*  */ #nav {} .author {}



Type selectors

Avoid using class names or identifiers with element type (tag) selectors.

Except when it is not necessary (for example, with helper classes), do not use element names with class names or identifiers.

This boosts Productivity .

Not recommended:
  /*   */ ul#example {} div.error {}

Recommended:
  /*  */ #example {} .error {}



Abbreviated forms for writing properties

Use abbreviated forms for writing properties where possible.

CSS offers many different abbreviated (English) forms of writing (for example, font ) that are recommended to be used wherever possible, even if only one of the values ​​is specified.

Using abbreviated properties is useful for greater efficiency and better understanding of the code.

Not recommended:
  /*   */ border-top-style: none; font-family: palatino, georgia, serif; font-size: 100%; line-height: 1.6; padding-bottom: 2em; padding-left: 1em; padding-right: 1em; padding-top: 0;

Recommended:
  /*  */ border-top: 0; font: 100%/1.6 palatino, georgia, serif; padding: 0 1em 2em;



0 and units

Do not specify units for null values

Do not specify units for zero values ​​unless there is a reason for it.

Recommended:
  margin: 0; padding: 0;



0 in the whole part of the fraction

Do not put “0” in the integer part of fractional numbers.

Do not put 0 in the integer part in values ​​between -1 and 1.

Recommended:
  font-size: .8em;



Quotes in links

Do not use quotes in links

Do not use quotes ( "" , "' ) with url () .

Recommended:
  @import url(//www.google.com/css/go.css);



Hexadecimal color names

Use three character hexadecimal notation where possible.

The three character hexadecimal notation for flowers is shorter and takes up less space.

Not recommended:
  /*   */ color: #eebbcc;

Recommended:
  /*  */ color: #ebc;



Prefixes

Prefetch selectors with prefixes unique to the current application. (not necessary)

In large projects, as well as in the code that will be used for other projects or in other sites, use prefixes (as namespaces) for identifiers and class names. Use short unique names followed by a hyphen.

Using namespaces helps prevent name conflicts and can facilitate site maintenance. For example, when searching and replacing.

Recommended:
  .adw-help {} /* AdWords */ #maia-note {} /* Maia */



Separators in classes and identifiers

Separate words into identifiers and class names with a hyphen.

Do not use anything other than a hyphen to connect words and abbreviations in selectors to improve readability and ease of code understanding.

Not recommended:
  /*  :  “demo”  “image”   */ .demoimage {} /*  :     */ .error_status {}

Recommended:
  /*  */ #video-id {} .ads-sample {}



Khaki

Avoid using browser versioning information, or CSS hacks — try other methods first.

It seems tempting to deal with differences in the work of different browsers using CSS filters, hacks or other workarounds. All these approaches can only be considered as a last resort if you want an efficient and easily maintained code base. Simply put, allowing hacks and defining a browser will damage a project in the long run, as this means that the project follows the path of least resistance. That facilitates the use of hacks and allows you to use them more and more often, resulting in too frequent use of them.




CSS Formatting Rules


Organize ads

Sort ads alphabetically.

Set ads in alphabetical order to get a consistent code that is easy to work with.

When sorting, ignore browser prefixes. At the same time, if several browser prefixes are used for one property, they should also be sorted (for example, -moz should be before --webkit )

Recommended:
  background: fuchsia; border: 1px solid; -moz-border-radius: 4px; -webkit-border-radius: 4px; border-radius: 4px; color: black; text-align: center; text-indent: 2em;



Indents in blocks.

Always indent the contents of the blocks.

Always indent any block content (English) . For example, for rules within rules or declarations, to display a hierarchy and make it easier to understand the code.

Recommended:
  @media screen, projection { html { background: #fff; color: #444; } }



After announcements

Put a semicolon after each declaration.

After each declaration, put a semicolon to match the code and make it easier to add new properties.

Not recommended:
  .test { display: block; height: 100px }

Recommended:
  .test { display: block; height: 100px; }



After property names

Use spaces after colons in declarations.

Always use one space after the colon (but not before) in the declarations, for order in the code.

Not recommended:
  h3 { font-weight:bold; }

Recommended:
  h3 { font-weight: bold; }



Branch selector and announcements

Separate selectors and declarations by hyphenating.

Start each selector or declaration with a new line.

Not recommended:
  a:focus, a:active { position: relative; top: 1px; }

Recommended:
  h1, h2, h3 { font-weight: normal; line-height: 1.2; }



Separation of rules

Separate rules by line breaks.

Always put a line break between the rules.

Recommended:
  html { background: #fff; } body { margin: auto; width: 50%; }



CSS meta rules


Rule grouping

Group rules and label groups with comments. (not necessary)

If possible, combine the rules into groups. Mark the groups with comments and share the line breaks.

Recommended:
  /* Header */ #adw-header {} /* Footer */ #adw-footer {} /* Gallery */ .adw-gallery {}



Conclusion


Be consistent

If you're editing code, take a few minutes to figure out how to write it. If the mathematical operators are separated by spaces, do the same. If comments are surrounded by parentheses or dashes, do the same with your comments.

The idea behind this tutorial is to create a common vocabulary that would allow developers to concentrate on what they want to express, not how .

We offer uniform design rules that allow you to write code in the same style, but the style of code already used in the project is also important.

If your code is very different from the existing one, it can knock the reader off the rhythm and make reading difficult. Try to avoid this.


Note from the translator


I would also like to note that Google focuses primarily on large high-load projects, where every byte is expensive, so you should bear in mind that if they recommend starting each selector with a new line, or use spaces instead of tabs, this first of all implies that the code will be necessarily minified and compressed before use on the site.

Thanks to everyone who read to this place.

Source: https://habr.com/ru/post/143452/

More articles:


All Articles