Сокращенный способ задания свойств html

	The 1-value syntax: border-width: 1em — The unique value represents all edges
	The 2-value syntax: border-width: 1em 2em — The first value represents the vertical, that is top and bottom, edges, the second the horizontal ones, that is the left and right ones.
	The 3-value syntax: border-width: 1em 2em 3em — The first value represents the top edge, the second, the horizontal, that is left and right, ones, and the third value the bottom edge
	The 4-value syntax: border-width: 1em 2em 3em 4em — The four values represent the top, right, bottom and left edges respectively, always in that order, that is clock-wise starting at the top (The initial letter of Top-Right-Bottom-Left matches the order of the consonant of the word trouble: TRBL)

Similarly, shorthands handling properties related to corners of a box, like border-radius , always use a consistent 1-to-4-value syntax representing those corners:

The 4-value syntax: border-radius: 1em 2em 3em 4em — The four values represent the top left, top right, bottom right and bottom left corners respectively, always in that order, that is clock-wise starting at the top left.

Background properties

A background with the following properties .

. can be shortened to just one declaration:

(The shorthand form is actually the equivalent of the longhand properties above plus background-attachment: scroll and, in CSS3, some additional properties.)

Font properties

The following declarations .

. can be shortened to the following:

This shorthand declaration is actually equivalent to the longhand declarations above plus font-variant: normal and font-size-adjust: none (CSS2.0 / CSS3), font-stretch: normal (CSS3).

Border properties

With borders, the width, color, and style can be simplified into one declaration. For example, the following CSS .

. can be simplified as:

Margin and padding properties

Shorthand versions of margin and padding values work the same way. The following CSS declarations .

. are the same as the following declaration. Note that the values are in clockwise order, beginning at the top: top, right, bottom, then left (TRBL, the consonants in «trouble»).

Источник

Руководство по оформлению HTML/CSS кода от Google

От переводчика

С удовольствием ознакомился с этими рекомендациями и теперь предлагаю вам перевод.

Введение

Это руководство описывает правила для оформления и форматирования HTML и CSS кода. Его цель — повысить качество кода и облегчить совместную работу и поддержку инфраструктуры.

Это относится к рабочим версиям файлов использующих HTML , CSS и GSS

Разрешается использовать любые инструменты для минификации компиляции или обфускации кода, при условии, что общее качество кода будет сохранено.

Общие правила оформления

Протокол

Не указывайте протокол при включении ресурсов на страницу.

Опускайте название протокола ( http: , https: ) в ссылках на картинки или другие медиа-ресурсы, файлы стилей или скрипты, конечно, если эти файлы доступны по обоим протоколам.

Отсутствие протокола делает ссылку относительной, что предотвращает смешивание ресурсов из разных протоколов и незначительно уменьшает размер файлов.

Не рекомендуется:
Рекомендуется:
Не рекомендуется:
Рекомендуется:

Общее форматирование

Отступы

Всегда используйте для отступа два пробела.

Не используйте табуляцию и не смешивайте табуляцию с пробелами.

Регистр

Всегда пишите в нижнем регистре.

Весь код должен быть написан в нижнем регистре: Это относится к названиям элементов, названиям атрибутов, значениям атрибутов (кроме текста/ CDATA ), селекторам, свойствам и их значениям (кроме текста).

Пробелы в конце строки

Убирайте пробелы в конце строки.

Пробелы в конце строк не обязательны и усложняют использование diff.

Не рекомендуется:
Рекомендуется:

Общие мета правила

Кодировка

Используйте UTF-8 (без BOM).

Убедитесь, что ваш редактор использует кодировку UTF-8 без метки порядка байтов (BOM).

Указывайте кодировку в HTML шаблонах и документах с помощью . Опускайте кодировку для сss-файлов: для них UTF-8 задана по умолчанию.

(Вы можете узнать больше о кодировках, и о том, как их использовать, по этой ссылке: Наборы символов и кодировки в XHTML, HTML CSS (англ.).)

Комментарии

По возможности поясняйте свой код, где это необходимо.

Используйте комментарии, чтобы пояснить свой код: что он делает, за что отвечает, и почему используется выбранное решение.

(Этот пункт не обязателен, потому что нет смысла ожидать, что код всегда будет хорошо задокументирован. Полезность комментирования зависит от сложности проекта и может различаться для HTML и CSS кода. )

Задачи

Отмечайте задачи для списка дел с помощью TODO .

Отмечайте задачи с помощью ключевого слова TODO . не используйте другие часто встречающиеся форматы, такие как @@ .

Заключайте контакты (имя пользователя или список адресатов) в круглые скобки: TODO(контакт) .

Описывайте задачу после двоеточия, например: TODO: Задача .

Правила оформления HTML

Тип документа

HTML5 (HTML синтаксис) рекомендуется для всех html-документов: .

(Рекомендуется использовать HTML с типом контента text/html . Не используйте XHTML, так как application/xhtml+xml (англ.), хуже поддерживается браузерами и ограничивает возможность оптимизации. )

Валидность HTML

По возможности используйте валидный HTML.

Используйте валидный HTML код, кроме случаев, когда использование не позволяет достичь размера файла, необходимого для нужного уровня производительности.

Используйте такие инструменты как W3C HTML validator (англ.) чтобы проверить валидность кода.

Валидность — это важное и при этом измеряемое качество кода. Написание валидного HTML способствует изучению технических требований и ограничений и обеспечивает правильное использование HTML.

Не рекомендуется:
Рекомендуется:

Семантика

Используйте HTML так, как это было задумано.

Используйте элементы (Иногда неверно называемые “тегами”) по назначению: заголовки для заголовков, p для абзацев, a для ссылок и т.д.

Это облегчает чтение, редактирование и поддержку кода.

Не рекомендуется:
Рекомендуется:

Альтернатива для мультимедиа

Всегда указывайте альтернативное содержимое для мультимедиа.

Постарайтесь указать альтернативное содержимое для мультимедиа: например для картинок, видео или анимаций, заданных с помощью canvas . Для картинок это осмысленный альтернативный текст ( alt ), а для видео и аудио расшифровки текста и подписи если это возможно.

Альтернативное содержимое может помочь людям с с ограниченными возможностями. Например человеку со слабым зрением сложно понять, что на картинке если для нее не задан @alt . Другим людям может быть тяжело понять о чем говорится в видео или аудио записи.

(Если для картинки alt избыточен, или она используется только в декоративных целях в местах, где нельзя использовать CSS, используйте пустой альтернативный текст alt=»» )

Не рекомендуется:
Рекомендуется:

Разделение ответственности

Разделяйте структуру, оформление и поведение.

Держите структуру (разметка), оформление (стили) и поведение (скрипты) раздельно и постарайтесь свести взаимодействие между ними к минимуму.

Убедитесь, что документы и шаблоны содержат только HTML, и что HTML служит только для задания структуры документа. Весь код, отвечающий за оформление, перенесите в файлы стилей, а код отвечающий за поведение — в скрипты.

Старайтесь сократить их пересечения к минимуму, включая в шаблоны минимальное количество файлов стилей и скриптов.

Отделение структуры от представления и поведения помогает облегчить поддержку кода. Изменение шаблонов и HTML-документов всегда занимает больше времени чем изменение файлов стилей или скриптов.

Не рекомендуется:
Рекомендуется:

Ссылки-мнемоники

Не используйте ссылки-мнемоники.

Нет смысла использовать ссылки-мнемоники, такие как — , ” , или ☺ , когда все команды в файлах, редакторах используют одну кодировку (UTF-8)

Единственное исключение из этого правила — служебные символы HTML (например и & ) а так же вспомогательные и “невидимые” символы (например неразрывный пробел).

Не рекомендуется:
Рекомендуется:

Необязательные теги

Не используйте необязательные теги. (не обязательно)

Для уменьшения размера файлов и лучшей читаемости кода можно опускать необязательные теги. В спецификации HTML5 (англ.) есть список необязательных тегов.

(Может потребоваться некоторое время для того, чтобы этот подход начал использоваться повсеместно, потому что это сильно отличается от того, чему обычно учат веб-разработчиков. С точки зрения, согласованности, и простоты кода лучше всего опускать все необязательные теги, а не некоторые из них).

Не рекомендуется:
Рекомендуется:

Атрибут ‘type’

Не указывайте атрибут type при подключении стилей и скриптов в документ.

Не используйте атрибут type при подключении стилей (кроме вариантов когда используется что-то кроме CSS) и скриптов (кроме вариантов когда это не JavaScript).

Указывать атрибут type в данном случае не обязательно потому что HTML5 использует text/css (англ.) и text/javascript (англ.) по умолчанию. Это будет работать даже в старых браузерах.

Не рекомендуется:
Рекомендуется:
Не рекомендуется:
Рекомендуется:

Правила форматирования HTML

Форматирование

Выделяйте новую строку для каждого блочного, табличного или списочного элемента и ставьте отступы для каждого дочернего элемента.

Независимо от стилей заданных для элемента (CSS позволяет изменить поведение элемента с помощью свойства display ), переносите каждый блочный или табличный элемент на новую строку.

Также ставьте отступы для всех элементов вложенных в блочный или табличный элемент.

(Если у вас возникнут сложности из-за пробельных символов между списочными элементами, допускается поместить все li элементы в одну строку. Линту [утилита для проверки качества кода прим. пер.] рекомендуется в данном случае выдавать предупреждение вместо ошибки.

Рекомендуется:
Рекомендуется:
Рекомендуется:

Правила оформления CSS

Валидность CSS

По возможности используйте валидный CSS-код.

Кроме случаев, где необходим браузеро-зависимый код, или ошибок валидатора, используйте валидный CSS код.

Используйте такие инструменты как W3C CSS Валидатор (англ.) для проверки своего кода.

Валидность — это важное и при этом измеряемое качество кода. Написание валидного CSS помогает избавиться от избыточного кода и обеспечивает правильное использование таблиц стилей…

Идентификаторы и названия классов

Используйте шаблонные или имеющие смысл имена классов и идентификаторы.

Вместо использования шифров, или описания внешнего вида элемента, попробуйте в имени класса или идентификатора выразить смысл его создания, или дайте ему шаблонное имя…

рекомендуется выбирать имена, отражающие сущность класса, потому что их проще понять и, скорее всего, не понадобится менять в будущем.

Шаблонные имена — это просто вариант названия для элементов, у которых нет специального предназначения или которые не отличаются от своих братьев и сестер. Обычно они необходимы в качестве “Помощников.”

Использование функциональных или шаблонных имен уменьшает необходимость ненужных изменений в документа или шаблонах.

Не рекомендуется:
Рекомендуется:

Названия идентификаторов и классов

Для идентификаторов и классов используйте настолько длинные имена, насколько нужно, но настолько короткие, насколько возможно.

Попробуйте сформулировать, что именно должен делать данный элемент, при этом будьте кратки насколько возможно.

Такое использование классов и идентификаторов вносит свой вклад в облегчение понимания и увеличение эффективности кода.

Не рекомендуется:
Рекомендуется:

Селекторы типа

Избегайте использование имен классов или идентификаторов с селекторами типа (тега) элемента.

Кроме случаев когда это не обходимо (например с классами-помощниками), не используйте названия элементов с именами классов или идентификаторами.

Не рекомендуется:
Рекомендуется:

Сокращенные формы записи свойств

Используйте сокращенные формы записи свойств, где возможно.

CSS предлагает множество различных сокращенных (англ.) форм записи (например font ), которые рекомендуется использовать везде где это возможно, даже если задается только одно из значений.

Использование сокращенной записи свойств полезно для большей эффективности и лучшего понимания кода.

Не рекомендуется:
Рекомендуется:

0 и единицы измерения

Не указывайте единицы измерения для нулевых значений

Не указывайте единицы измерения для нулевых значений если на это нет причины.

0 в целой части дроби

Не ставьте “0” в целой части дробных чисел.

Не ставьте 0 в целой части в значениях между -1 и 1.

Кавычки в ссылках

Не используйте кавычки в ссылках

Не используйте кавычки ( «» , » ) с url() .

Шестнадцатеричные названия цветов

Используйте трехсимвольную шестнадцатеричную запись где это возможно.

Трехсимвольная шестнадцатиричная запись для цветов короче и занимает меньше места.

Не рекомендуется:
Рекомендуется:

Префиксы

Предваряйте селекторы уникальными для текущего приложения префиксами. (не обязательно)

В больших проектах, а так же в коде, который будет использоваться для других проектов или в других сайтах, используйте префиксы (в качестве пространств имен) для идентификаторов и имен классов. Используйте короткие уникальные названия с последующим дефисом.

Использование пространств имен позволяет предотвратить конфликты имен и может облегчить обслуживание сайта. Например при поиске и замене.

Разделители в классах и идентификаторах

Разделяйте слова в идентификаторах и именах классов с помощью дефиса.

Не используйте ничего, кроме дефиса, для соединения слов и сокращений в селекторах, чтобы повысить удобство чтения и легкость понимания кода.

Не рекомендуется:
Рекомендуется:

Избегайте использования информации о версии браузеров, или CSS “хаков”— сперва попробуйте другие способы.

Кажется заманчивым бороться с различиями в работе разных браузеров с помощью CSS-фильтров, хаков или прочих обходных путей. Все эти подходы могут быть рассмотрены лишь в качестве последнего средства, если вы хотите получить эффективную и легко поддерживаемую кодовую базу. Проще говоря, допущение хаков и определения браузера повредит проекту в долгосрочной перспективе, так как это означает, что проект идет по пути наименьшего сопротивления. Что облегчает использование хаков и позволяет использовать их все чаще и чаще, что в результате приведет к слишком частому их использованию.

Правила форматирования CSS

Упорядочивание объявлений

Сортируйте объявления по алфавиту.

Задавайте объявления в алфавитном порядке, чтобы получить согласованный код, с которым легко работать.

При сортировке игнорируйте браузерные префиксы. При этом, если для одного свойства используются несколько браузерных префиксов, они также должны быть отсортированы (например -moz должен быть перед —webkit )

Отступы в блоках.

Всегда ставьте отступы для содержимого блоков.

Всегда ставьте отступы для любого блочного содержимого (англ.), Например для правил внутри правил или объявлений, чтобы отобразить иерархию и облегчить понимание кода.

После объявлений

Ставьте точку с запятой после каждого объявления.

После каждого объявления ставьте точку с запятой для согласованности кода и облегчения добавления новых свойств.

Не рекомендуется:
Рекомендуется:

После названий свойств

Используйте пробелы после двоеточий в объявлениях.

Всегда используйте один пробел после двоеточия (но не до) в объявлениях, для порядка в коде.

Не рекомендуется:
Рекомендуется:

Отделение селектора и объявления

Отделяйте селекторы и объявления переносом строки.

Начинайте каждый селектор или объявление с новой строки.

Не рекомендуется:
Рекомендуется:

Разделение правил

Разделяйте правила переносом строки.

Всегда ставьте перенос строки между правилами.

Мета правила CSS

Группировка правил

Группируйте правила и обозначайте группы комментарием. (не обязательно)

По возможности объединяйте правила в группы. Обозначайте группы комментариями и разделяйте переносом строки.

Заключение

Если вы редактируете код, потратьте несколько минут, чтобы разобраться в том, как он написан. Если математические операторы обособлены пробелами, делайте то же самое. Если комментарии окружены скобочками или черточками, сделайте то же со своими комментариями.

Идея этого руководства в том, чтобы создать общий словарь, который позволил бы разработчикам сконцентрироваться на том что они хотят выразить, а не на том, как.

Мы предлагаем единые правила оформления позволяющие писать код в одном стиле, но стиль кода, уже используемый в проекте, также важен.

Если ваш код будет сильно отличаться от существующего, это может сбить читающего с ритма и затруднить чтение. Постарайтесь этого избежать.

Примечание от переводчика

Хочется еще отметить, что Google ориентируется в первую очередь на большие высоконагруженные проекты, где каждый байт дорог, поэтому стоит учитывать, что если они рекомендуют начинать каждый селектор с новой строки, или использовать пробелы вместо табов, то это в первую очередь подразумевает, что код будет обязательно минифицирован и сжат до использования на сайте.

Источник

Вам также может понравиться

Ясень семена способ распространения

Ясень обыкновенный Fraxinus excelsior – так в ботанической

Ярлыки способы создания ярлыков ос windows

Создаем ярлыки на рабочем столе Windows Создаем ярлыки

Японское удобрение фуджима способ применения

Удобрения Фуджима Знаете потрясающее удобрение, палочка

Японский чай способ заварки

Технология заваривания японского чая Известно, что

	The 1-value syntax: border-radius: 1em — The unique value represents all corners
	The 2-value syntax: border-radius: 1em 2em — The first value represents the top left and bottom right corner, the second the top right and bottom left ones.
	The 3-value syntax: border-radius: 1em 2em 3em — The first value represents the top left corner, the second the top right and bottom left ones, and the third value the bottom right corner