від перекладача
Із задоволенням ознайомився з цими рекомендаціями і тепер пропоную вам переклад.
Це керівництво описує правила для оформлення та форматування HTML і CSS коду. Його мета - підвищити якість коду і полегшити спільну роботу і підтримку інфраструктури.
Це відноситься до робітників версіями файлів використовують HTML. CSS і GSS
Дозволяється використовувати будь-які інструменти для мініфікаціі компіляції або обфускаціі коду, за умови, що загальна якість коду буде збережено.
Загальні правила оформлення
Не вказуйте протокол при включенні ресурсів на сторінку.
Відсутність протоколу робить посилання відносної, що запобігає змішуванню ресурсів з різних протоколів і незначно зменшує розмір файлів.
Не рекомендується:
рекомендується:
Не рекомендується:
рекомендується:
Загальна форматування
Завжди використовуйте для відступу два пробілу.
Не використовуйте табуляцію і не змішуйте табуляцію з пробілами.
Завжди пишіть в нижньому регістрі.
Весь код повинен бути написаний в нижньому регістрі: Це відноситься до назв елементів, назвами атрибутів, значень атрибутів (крім тексту / CDATA), селекторам, властивостям і їх значенням (крім тексту).
Прогалини в кінці рядка
Прибирайте прогалини в кінці рядка.
Прогалини в кінці рядків не обов'язкові і ускладнюють використання diff.
Не рекомендується:
рекомендується:
Загальні мета правила
Використовуйте UTF-8 (без BOM).
Вказуйте кодування в HTML шаблонах і документах за допомогою . Опускайте кодування для сss-файлів: для них UTF-8 задана за замовчуванням.
(Ви можете дізнатися більше про кодування, і про те, як їх використовувати, за цим посиланням: Набори символів і кодування в XHTML, HTML CSS (англ.).)
По можливості пояснюйте свій код, де це необхідно.
Відзначайте завдання для списку справ за допомогою 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 для посилань і т.д.
Це полегшує читання, редагування і підтримку коду.
Не рекомендується:
рекомендується:
Альтернатива для мультимедіа
Завжди вказуйте альтернативне вміст для мультимедіа.
(Якщо для картинки alt надлишковий, або вона використовується тільки в декоративних цілях в місцях, де не можна використовувати CSS, використовуйте порожній альтернативний текст alt = "")
Не рекомендується:
рекомендується:
поділ відповідальності
Розділіть структуру, оформлення та поведінку.
Тримайте структуру (розмітка), оформлення (стилі) і поведінку (скрипти) окремо і постарайтеся звести взаємодія між ними до мінімуму.
Переконайтеся, що документи та шаблони містять тільки HTML, і що HTML служить тільки для завдання структури документа. Весь код, який відповідає за оформлення, перенесіть в файли стилів, а код відповідає за поведінку - в скрипти.
Намагайтеся скоротити їх перетину до мінімуму, включаючи в шаблони мінімальну кількість файлів стилів і скриптів.
Відділення структури від уявлення і поведінки допомагає полегшити підтримку коду. Зміна шаблонів і HTML-документів завжди займає більше часу ніж зміна файлів стилів або скриптів.
Не рекомендується:
рекомендується:
Посилання-мнемоніки
Не використовуйте посилання-мнемоніки.
Єдиний виняток з цього правила - службові символи HTML (наприклад <и & ) а так же вспомогательные и “невидимые” символы (например неразрывный пробел).
Не рекомендується:
рекомендується:
необов'язкові теги
Не використовуйте необов'язкові теги. (не обов'язково)
Для зменшення розміру файлів і кращої читання коду можна опускати необов'язкові теги. У специфікації HTML5 (англ.) Є список необов'язкових тегів.
(Може знадобитися деякий час для того, щоб цей підхід почав використовуватися повсюдно, тому що це сильно відрізняється від того, чого зазвичай вчать веб-розробників. З точки зору, узгодженості, і простоти коду найкраще опускати всі необов'язкові теги, а не деякі з них).
Не рекомендується:
рекомендується:
Атрибут 'type'
Не вказуйте атрибут type при підключенні стилів і скриптів в документ.
Не рекомендується:
рекомендується:
Не рекомендується:
рекомендується:
Правила форматування 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 орієнтується в першу чергу на великі високонавантажені проекти, де кожен байт доріг, тому варто враховувати, що якщо вони рекомендують починати кожен селектор з нового рядка, або використовувати прогалини замість табів, то це в першу чергу має на увазі, що код буде обов'язково мініфіцірован і стиснутий до використання на сайті.
Спасибі всім хто дочитав до цього місця.