Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 168
Полезно, спасибо.
Дочитать не получилось, но такой статье самое место в избранном, однозначно.
Дочитать не получилось, но такой статье самое место в избранном, однозначно.
Интересная статья, но вот с пунктом «Атрибут 'type'» не совсем согласен, наш сайт весьма глючил в старых браузерах, когда у
Важно понимать, что это именно советы от Гугла, т. е. они заточены под то, что а) над кодом может работать куча людей, б) дорог каждый байт.
Именно поэтому появляются советы делать вот так (omg!):
Хотя большая часть советов универсальна, бездумно их применять всё-таки не стоит.
Именно поэтому появляются советы делать вот так (omg!):
<!DOCTYPE html>
<title>Байты-деньги!</title>
<p>Так-то
Хотя большая часть советов универсальна, бездумно их применять всё-таки не стоит.
Вот это и интересно в данном случае.
Мне кажется, что дело не в попытке сократить место, потому что сейчас любой код перед использованием проходит пре-обработку, во время которой можно легко вырезать все необязательные теги.
Возможно просто попытка сэкономить время разработчиков?
Мне кажется, что дело не в попытке сократить место, потому что сейчас любой код перед использованием проходит пре-обработку, во время которой можно легко вырезать все необязательные теги.
Возможно просто попытка сэкономить время разработчиков?
Не встречал пока что преобработки html-кода. Максимум что делают — сливают все css, js в один файл, убирают все пробелы. У html-кода тоже убирают все пробелы. Но вырезать теги, нет, я бы не позволил, можно и все порушить.
В данном случае это действительно делается для маниакальной задачи уменьшения веса страниц. С точки зрения разработки такой код читать гораздо сложнее.
Ну а уж время разработчиков это вовсе не экономит. Если вы ведете разработку в профессиональном IDE, то там для вас будут все инструменты для быстрой вставки кода, начиная с автокомплита и заканчивая сниппетами. Либо вообще многие могут использовать zen-coding для сверх быстрого набора кода.
В данном случае это действительно делается для маниакальной задачи уменьшения веса страниц. С точки зрения разработки такой код читать гораздо сложнее.
Ну а уж время разработчиков это вовсе не экономит. Если вы ведете разработку в профессиональном IDE, то там для вас будут все инструменты для быстрой вставки кода, начиная с автокомплита и заканчивая сниппетами. Либо вообще многие могут использовать zen-coding для сверх быстрого набора кода.
Вот хорошая статья Kangax'a на эту тему, к сожалению сайт лежит, так что пока версия из кеша:
webcache.googleusercontent.com/search?q=cache:http://perfectionkills.com/experimenting-with-html-minifier/
Штука пре-обратывает html включая вырезание необязательных тегов.
Думаю, что сейчас это не очень популярно, потому что неплохо загружает сервер, но в ближайшем будущем думаю ситуация поменяется.
Вот еще пара линков на программки, слышал о них, но не работал:
code.google.com/p/htmlcompressor/#How_it_Works
code.google.com/p/page-speed/wiki/MinifyHtml
Насчет автокомплита и zen-coding — абсолютно согласен, но быстрее — не написать тег вообще, чем на писать его быстро.
webcache.googleusercontent.com/search?q=cache:http://perfectionkills.com/experimenting-with-html-minifier/
Штука пре-обратывает html включая вырезание необязательных тегов.
Думаю, что сейчас это не очень популярно, потому что неплохо загружает сервер, но в ближайшем будущем думаю ситуация поменяется.
Вот еще пара линков на программки, слышал о них, но не работал:
code.google.com/p/htmlcompressor/#How_it_Works
code.google.com/p/page-speed/wiki/MinifyHtml
Насчет автокомплита и zen-coding — абсолютно согласен, но быстрее — не написать тег вообще, чем на писать его быстро.
В том то и дело, что обычно автокомплит ставит закрывающие теги автоматически, так же как и zen-coding. Так что разницы по времени нет.
Для тех, кто не любит писать лишние символы, есть Haml, на нём и пишется быстрее и читается он гораздо лучше, чем HTML без закрывающих тегов.
А для тех, кто ещё больше не любит лишние символы, есть Slim :)
Хотя у них обоих проблем хватает
Хотя у них обоих проблем хватает
и в чём же у них проблемы для верстальщика? если заказчик требует HTML, то сгенерировать их из Haml-файлов дело пары секунд.
Вот тут обуждали: juick.com/Mendor/1876034#7
В кратце: inline-оформление и javascript
В кратце: inline-оформление и javascript
А почему бы и нет, мне идея понравилась. я даже как то не задумывался об этом и по правде говоря не знал о необязательных тегах в html5.
Спасибо за перевод! Прочитал с удовольствием.
Однозначно — полезное. И в одном месте. В избранное без раздумий. Спасибо
Хороший перевод нужной статьи. Бездумно применять, как писалось выше — не рекомендуется, но в целом очень полезно!
Этакий Сode Сonvention, его действительно не хватало по html и css, c еще большим интересом ознакомился бы с аналогичным по js.
Есть и для Javascript, не переведенный правда:
google-styleguide.googlecode.com/svn/trunk/javascriptguide.xml
Вообще гугл все свои руководства по оформлению складывает в одном месте:
code.google.com/p/google-styleguide/
google-styleguide.googlecode.com/svn/trunk/javascriptguide.xml
Вообще гугл все свои руководства по оформлению складывает в одном месте:
code.google.com/p/google-styleguide/
Необязательные теги
Не используйте необязательные теги. (не обязательно)
Взорвало мозг сначала :)
Не используйте необязательные теги. (не обязательно)
Взорвало мозг сначала :)
А можно разве так?
Пять
Погулять
т.е. не закрывая тэги? еще в примерах там есть с td и th
Пять
Погулять
т.е. не закрывая тэги? еще в примерах там есть с td и th
Рекомендует гугл у которого упор на скорость сайтов, а по их правилам пробелы будут весить больше правил
Рекомендует гугл у которого вместо инпутов/текстзон стоят дивы с контентедит
Рекомендует гугл у которого ни одного валидного сайта
Рекомендует гугл у которого куча сайта сверстанных на тейблах
зы: правила ок, только многие это просто ИМХО, мне удобнее табы, мне нравится писать тип цсс и джс и т.д.
Рекомендует гугл у которого вместо инпутов/текстзон стоят дивы с контентедит
Рекомендует гугл у которого ни одного валидного сайта
Рекомендует гугл у которого куча сайта сверстанных на тейблах
зы: правила ок, только многие это просто ИМХО, мне удобнее табы, мне нравится писать тип цсс и джс и т.д.
Тот самый гугл, который зарабатывает больше тех у кого сайты валидны :)
Ну как-то так, да.
Меня ещё удивило, что в примере ниже (который рекомендуется как валидный HTML) есть пробелы в конце строк, хотя чуть выше рекомендуется так не делать.
<!DOCTYPE html>
<meta charset="utf-8">
<title>Проверка</title>
<article>Просто проверка.</article>
Но, впрочем, я проверил в оригинале — там пробелов не было.
Но главное не в этом, а в том, что действительно type=«text/css» и type=«text/javascript» выглядят, как мне кажется, неплохо, и убирать их особого смысла нет (или, например, убирать type из ).
Да и опускать тэги html, head и body — тоже как-то не очень приятно. Можно, но я бы не сказал, что эта экономия нескольких байт так уж хороша. Я помню, некоторое время назад любители CP1251 и KOI8-R «козыряли» тем, что кириллические символы на их страницах занимают вдвое меньше места, и это очень ценно.
Помню недавно работал с верстальщиками, и написал им длинные guidelines, где довольно чётко было прописано, как именно требуется сделать. Они не выполнили, по-моему, и половину оттуда. Пытались сначала вообще невалидно сверстать (ссылаясь на какую-то статью на Хабре), потом сверстали валидно, но почему-то с XHTML 1.0 (26 января 2000), и не указав alt (хотя бы "") ни у одной картинки — поэтому получилась куча ошибок валидации. Потом я им указал на это, и они поставили alt (но абсолютно везде alt="", даже там, где имеет смысл написать что-то конкретное). Ещё у них там были прямо в HTML указаны JS-события для инпутов, для того, чтобы туда подставлялись placeholder'ы (хотя, казалось бы, можно просто добавить атрибут placeholder, а для старых браузеров подключить jquery.placeholder). Когда я им об этом написал, и указал, как лучше сделать, они поставили там нужные атрибуты, но так и не поменяли doctype на HTML5 (то есть снова ошибки валидации).
Ещё у них там зачем-то было такое:
<meta http-equiv="X-UA-Compatible" content="e;IE=EmulateIE7" />
<meta http-equiv="X-UA-Compatible" content="e;IE=7" />
Наверно, это для того, чтобы если более новые и адекватные версии IE уже могли нормально поддерживать какие-либо современные тэги, атрибуты и свойства, то они этого не делали.
В общем, многие люди делают много очень странных вещей. Аналогично, я не понимаю, когда люди указывают у каких-либо элементов (например, у текстовых полей) только цвет фона или только цвет текста. Потому что на практике это означает, что у любого пользователя, у которого цвет фона по умолчанию не белый и цвет текста по умолчанию не чёрный (а для этого достаточно сменить тему) будет наблюдать, например, очень тёмный текст на очень тёмном фоне (автор-то думал, что цвет фона у всех будет белый, у него-то белый отображается). Или если, например, задан светлый цвет текста, а сзади загружается тёмная картинка. Но тёмный цвет фона не задан. Поэтому если картинка по какой-то причине не загрузится, то текст будет невозможно прочитать.
Ещё очень часто у картинок не заданы width и height, и это приводит к тому, что содержимое вокруг картинки «скачет» в разные стороны, пока картинки загружаются.
Но лидирует в направлении «Самая странная вёрстка» пока что всё же белорусский сайт beltechnolift.com (на Хабре про него было). Вот это я понимаю — тут не то, что ни о каких гайдлайнах речи не идёт, а тут у авторов вообще совершенно альтернативное понимание всего. :)
В общем, это всё к чему. Советы от Google неплохи (да и, что уж там — эта компания как правило понимает, о чём говорит), но ни в коем случае не нужно руководствоваться их советами в том случае, если это противоречит здравому смыслу. При разработке разных сайтов задачи совершенно разные, и в каких-то случаях бывает так, что об оптимизации размера содержимого, выдаваемого пользователям, думают в последнюю очередь (бывает так, что оно должно быть наоборот как можно более читаемое для людей, и так далее).
Поэтому тут надо делать не по принципу «сделаю так, потому что знающий человек так сказал», а по принципу «сделаю так, потому что есть такие-то причины для того, чтобы это решение работало лучше, чем все остальные возможные».
Меня ещё удивило, что в примере ниже (который рекомендуется как валидный HTML) есть пробелы в конце строк, хотя чуть выше рекомендуется так не делать.
<!DOCTYPE html>
<meta charset="utf-8">
<title>Проверка</title>
<article>Просто проверка.</article>
Но, впрочем, я проверил в оригинале — там пробелов не было.
Но главное не в этом, а в том, что действительно type=«text/css» и type=«text/javascript» выглядят, как мне кажется, неплохо, и убирать их особого смысла нет (или, например, убирать type из ).
Да и опускать тэги html, head и body — тоже как-то не очень приятно. Можно, но я бы не сказал, что эта экономия нескольких байт так уж хороша. Я помню, некоторое время назад любители CP1251 и KOI8-R «козыряли» тем, что кириллические символы на их страницах занимают вдвое меньше места, и это очень ценно.
Помню недавно работал с верстальщиками, и написал им длинные guidelines, где довольно чётко было прописано, как именно требуется сделать. Они не выполнили, по-моему, и половину оттуда. Пытались сначала вообще невалидно сверстать (ссылаясь на какую-то статью на Хабре), потом сверстали валидно, но почему-то с XHTML 1.0 (26 января 2000), и не указав alt (хотя бы "") ни у одной картинки — поэтому получилась куча ошибок валидации. Потом я им указал на это, и они поставили alt (но абсолютно везде alt="", даже там, где имеет смысл написать что-то конкретное). Ещё у них там были прямо в HTML указаны JS-события для инпутов, для того, чтобы туда подставлялись placeholder'ы (хотя, казалось бы, можно просто добавить атрибут placeholder, а для старых браузеров подключить jquery.placeholder). Когда я им об этом написал, и указал, как лучше сделать, они поставили там нужные атрибуты, но так и не поменяли doctype на HTML5 (то есть снова ошибки валидации).
Ещё у них там зачем-то было такое:
<meta http-equiv="X-UA-Compatible" content="e;IE=EmulateIE7" />
<meta http-equiv="X-UA-Compatible" content="e;IE=7" />
Наверно, это для того, чтобы если более новые и адекватные версии IE уже могли нормально поддерживать какие-либо современные тэги, атрибуты и свойства, то они этого не делали.
В общем, многие люди делают много очень странных вещей. Аналогично, я не понимаю, когда люди указывают у каких-либо элементов (например, у текстовых полей) только цвет фона или только цвет текста. Потому что на практике это означает, что у любого пользователя, у которого цвет фона по умолчанию не белый и цвет текста по умолчанию не чёрный (а для этого достаточно сменить тему) будет наблюдать, например, очень тёмный текст на очень тёмном фоне (автор-то думал, что цвет фона у всех будет белый, у него-то белый отображается). Или если, например, задан светлый цвет текста, а сзади загружается тёмная картинка. Но тёмный цвет фона не задан. Поэтому если картинка по какой-то причине не загрузится, то текст будет невозможно прочитать.
Ещё очень часто у картинок не заданы width и height, и это приводит к тому, что содержимое вокруг картинки «скачет» в разные стороны, пока картинки загружаются.
Но лидирует в направлении «Самая странная вёрстка» пока что всё же белорусский сайт beltechnolift.com (на Хабре про него было). Вот это я понимаю — тут не то, что ни о каких гайдлайнах речи не идёт, а тут у авторов вообще совершенно альтернативное понимание всего. :)
В общем, это всё к чему. Советы от Google неплохи (да и, что уж там — эта компания как правило понимает, о чём говорит), но ни в коем случае не нужно руководствоваться их советами в том случае, если это противоречит здравому смыслу. При разработке разных сайтов задачи совершенно разные, и в каких-то случаях бывает так, что об оптимизации размера содержимого, выдаваемого пользователям, думают в последнюю очередь (бывает так, что оно должно быть наоборот как можно более читаемое для людей, и так далее).
Поэтому тут надо делать не по принципу «сделаю так, потому что знающий человек так сказал», а по принципу «сделаю так, потому что есть такие-то причины для того, чтобы это решение работало лучше, чем все остальные возможные».
Вернее так:
Странно, кстати, что на Хабре нельзя отключить автоматическую замену «"» на кавычки-ёлочки. Потому что если я имею в виду кавычки-ёлочки, то я нажимаю на Compose key и ввожу два раза << или >>. А если ввожу «"», то и имею в виду «"». А так приходится писать ".
Да, кстати, вспомнилось — ещё часто забывают «&» в ссылках заменить на &. Браузер эту ошибку умеет обрабатывать, но валидность от этого уже теряется. Так что лучше заменять, чтобы было по стандартам.
Но главное не в этом, а в том, что действительно type="text/css" и type="text/javascript" выглядят, как мне кажется, неплохо, и убирать их особого смысла нет (или, например, убирать type из <link rel="icon" type="image/png" href="/favicon.png">).
Странно, кстати, что на Хабре нельзя отключить автоматическую замену «"» на кавычки-ёлочки. Потому что если я имею в виду кавычки-ёлочки, то я нажимаю на Compose key и ввожу два раза << или >>. А если ввожу «"», то и имею в виду «"». А так приходится писать ".
Да, кстати, вспомнилось — ещё часто забывают «&» в ссылках заменить на &. Браузер эту ошибку умеет обрабатывать, но валидность от этого уже теряется. Так что лучше заменять, чтобы было по стандартам.
Прошу прощения за пробелы в примерах — боролся с парсером.
<!doctype html>
<!--[if lt IE 7]>
<html class="no-js lt-ie9 lt-ie8 lt-ie7" lang="en"> <![endif]-->
<!--[if IE 7]>
<html class="no-js lt-ie9 lt-ie8" lang="en"> <![endif]-->
<!--[if IE 8]>
<html class="no-js lt-ie9" lang="en"> <![endif]-->
<!--[if gt IE 8]><!-->
<html class="no-js" lang="en"> <!--<![endif]-->
<head>
<meta charset="utf-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1">
Пример из Boilerplate
Рекомендует гугл у которого вместо инпутов/текстзон стоят дивы с контентедит
В инпутах и textarea невозможно форматировать вводимый текст.
Гитхабовские соглашения по написанию кода для javascript и css
ну раз пошла такая пьянка - codex.wordpres / CSS_Coding_Standards
Добавлю по Twitter. Собственно их Bootstrap сам по себе несёт стандарты, косвенно в коде и напрямую в документе js philosophy, а для поддержания css-кода есть ещё неплохой проект Twitter Recess
А я всё равно tab люблю.
Меня заботит одно — никто в таких сборниках правил не пишет почему так нужно делать, почему пришли к тому или иному решению. Только несколько пунктов имеют причину.
Относительно мнемоник не совсем корректный пример, т.к. знак евро отсутствует в стандартной раскладке, а кавычки и так все пишут без мнемоник.
Просто какой-то поток незамутнённого здравого смысла :) Отличные правила!
Единственное правило, с которым я не согласен — сортировка правил css по алфавиту. Мне кажется, это ничего не даёт с точки зрения поддерживаемости и читабельности.
Я, например, сортирую правила по степени важности, причём, в начале идут правила расположения (position, float, top, и т.д.), а потом уже правила отображения (font, color, background-image, и т.п.).
Единственное правило, с которым я не согласен — сортировка правил css по алфавиту. Мне кажется, это ничего не даёт с точки зрения поддерживаемости и читабельности.
Я, например, сортирую правила по степени важности, причём, в начале идут правила расположения (position, float, top, и т.д.), а потом уже правила отображения (font, color, background-image, и т.п.).
Сортировка упрощает жизнь разработчикам. Вот в твой такой код залезешь и будешь думать как там расставить правила, чтобы они по важности были, чтобы ты потом не ругался. Можно, конечно, и такой порядок в документ описать, но получится слишком сложно, не все запомнят, и соблюдаться такое вряд ли будет.
Сортировка упрощает жизнь только если какой-то стиль содержит несколько десятков строк — тогда в них проще ориентироваться, если они отсортированы. Но с другой стороны, если в стиле несколько десятков строк, то это явный признак того, что его можно отрефакорить — разделить правила на несколько семантически осмысленных селекторов.
И, по-моему, правило «сначала структурно-позиционные правила, а затем влияющие на внутреннее отображение» не сильно сложнее правила «сортировать по алфавиту, но вставлять правила с префиксами после одноимённых безпрефиксных правил».
И, по-моему, правило «сначала структурно-позиционные правила, а затем влияющие на внутреннее отображение» не сильно сложнее правила «сортировать по алфавиту, но вставлять правила с префиксами после одноимённых безпрефиксных правил».
Сортировка (в любом детерминированном порядке) — это необходимое условие осмысленного функционирования differencing/merging tools.
Это как в Java-проектах правила сортировки-группировки импортов. Или они есть и общие для команды, или кому-то придется вручную вправлять кишки при каждом мерже — что портит жизнь при стратегии merge often не хуже, чем частые светофоры на хайвее.
Это как в Java-проектах правила сортировки-группировки импортов. Или они есть и общие для команды, или кому-то придется вручную вправлять кишки при каждом мерже — что портит жизнь при стратегии merge often не хуже, чем частые светофоры на хайвее.
С некоторыми пунктами можно поспорить, но в целом полезно. Хотя и местами по-кэпски.
Насчет валидности и CSS-хаков. Я двумя руками за валидность кода настолько, насколько это возможно. Но бессмысленно превращать её в самоцель. Я через это проходил. Но сейчас уже пришел к выводу, что при разумном использовании хаки зачастую более удобный и надежный инструмент, чем фанатичная борьба за абсолютную валидность.
Насчет валидности и CSS-хаков. Я двумя руками за валидность кода настолько, насколько это возможно. Но бессмысленно превращать её в самоцель. Я через это проходил. Но сейчас уже пришел к выводу, что при разумном использовании хаки зачастую более удобный и надежный инструмент, чем фанатичная борьба за абсолютную валидность.
А интересно, гугл использует вещи типа HAML, SASS, CoffeeScript? Используя это сложнее нарушать проловина правил из списка.
Прочитал статью, глянул на главную страницу google.com.ua и сразу в глаза по первой рекомендации нарушение —
не говоря уже о таких записях
<script type="https://..."не говоря уже о таких записях
<body bgcolor="#fff"
И кстати,
<!doctype html> (как на главной гугла и по правилу «писать всё в нижнем регистре» или <!DOCTYPE html> (как в примерах в статье)?
В HTML регистр DOCTYPE не имеет значения, но в XML-нотации ключевое слово пишется в верхнем регистре, поэтому и в HTML-нотации имеет смысл делать так же.
Откуда у всех такая любовь к отступам из пробелов? Чем народу табы не угодили?
Согласен! и с параноидальной точки зрения экономии трафика табы эффективнее. Не понятно.
Если мой, например, нетбинс настроен на tab = 4 «отступа», а чей-то еще нетбинс настроен на tab=2 «отступа», и у меня в коде намешаны табы и пробелы, то у второго весь код полезет.
Длина одного таба зависит от текстового редактора в котором просматривается данный файл. Пробелы это более универсальное решение.
да, зависит, в этом и смысл, что каждый может настроить отображение отступов так, как ему нравится
Это в теории, которая очень редко соотносится с реальностью. Реальность — это код вроде этого:
Единственный способ сделать отображение такого кода корректным — это очень аккуратно смешать табы и пробелы. Это совершенно непрактично, никто этим заниматься не будет. Отказываться от переносов строк — это тоже не вариант.
class Foo
{
void Bar (int a,
int b, int c)
{
int x = 1,
y = 2;
}
}
Единственный способ сделать отображение такого кода корректным — это очень аккуратно смешать табы и пробелы. Это совершенно непрактично, никто этим заниматься не будет. Отказываться от переносов строк — это тоже не вариант.
Да, это точно. Я бы даже сформулировал так:
При использовании пробелов табы не нужны. А вот при использовании табов иногда приходится примешивать пробелы, что плохо.
При использовании пробелов табы не нужны. А вот при использовании табов иногда приходится примешивать пробелы, что плохо.
Какие у вас интересные конструкции в CSS :)
По поводу обычного кода понятно, что ничего не понятно. На Хабре одно время был холивар из пяти, что ли, топиков. Но тут же речь о CSS, в котором только один (изредка — два) уровень вложенности. Почему бы не пользоваться табами?
По поводу обычного кода понятно, что ничего не понятно. На Хабре одно время был холивар из пяти, что ли, топиков. Но тут же речь о CSS, в котором только один (изредка — два) уровень вложенности. Почему бы не пользоваться табами?
В рекомендациях речь идёт и про HTML, и про CSS. В HTML случается, что у элемента атрибутов или много, или они длинные, поэтому переносить придётся. Или вы предлагаете использовать в проекте 4 и больше языка, а CSS объявить особенным и форматировать только его на табах? :)
И вообще, в современном CSS без переносов строк тоже не обойтись…
Источник: lea.verou.me/css3patterns/#hearts (там ещё много таких градиентов в стиле «как такое вообще возможно»)
И вообще, в современном CSS без переносов строк тоже не обойтись…
background:
radial-gradient(60% 43%, closest-side circle, #b03 26%, rgba(187,0,51,0) 27%),
radial-gradient(40% 43%, closest-side circle, #b03 26%, rgba(187,0,51,0) 27%),
radial-gradient(40% 22%, closest-side circle, #d35 45%, rgba(221,51,85,0) 46%),
radial-gradient(60% 22%, closest-side circle, #d35 45%, rgba(221,51,85,0) 46%),
radial-gradient(50% 35%, closest-side circle, #d35 30%, rgba(221,51,85,0) 31%),
radial-gradient(60% 43%, closest-side circle, #b03 26%, rgba(187,0,51,0) 27%) 50px 50px,
radial-gradient(40% 43%, closest-side circle, #b03 26%, rgba(187,0,51,0) 27%) 50px 50px,
radial-gradient(40% 22%, closest-side circle, #d35 45%, rgba(221,51,85,0) 46%) 50px 50px,
radial-gradient(60% 22%, closest-side circle, #d35 45%, rgba(221,51,85,0) 46%) 50px 50px,
radial-gradient(50% 35%, closest-side circle, #d35 30%, rgba(221,51,85,0) 31%) 50px 50px;
background-color:#b03;
background-size:100px 100px;
Источник: lea.verou.me/css3patterns/#hearts (там ещё много таких градиентов в стиле «как такое вообще возможно»)
Всегда интересовало, почему аттрибут alt рекомендуют проставлять даже когда он пустой?
А если я привык делать отступ в 4 пробела? Это очень плохо?
Да, в гугл не возьмут…
Cкорее всего это правило ввели изза обилия вложенных элементов в html. И читабельность кода где нибудь на 15 уровне вложенности где код начинается с позиции 50 очень низка — вот они решили сократить вместо привычных 4 до 2. Таким образом код не так быстро уезжает от левого края
Сейчас меня, конечно, забросают помидорами, но эта статья — куча противоречивых и непоследовательных, а местами просто вредных советов. То он предлагает экономить один байтик в HTML, то вдруг вспоминает про читаемость и советует в CSS после двоеточия ставить пробел. То W3C валидатор используйте, то незакрытый тег center вне body. Если для проекта актуально экономить на байтах, можно наладить автоматическую обфускацию/минификацию кода перед деплойментом. Потому что вот это:
<!DOCTYPE html>
<title>Байты-деньги!</title>
<p>Так-то
Просто безобразие.
<!DOCTYPE html>
<title>Байты-деньги!</title>
<p>Так-то
Просто безобразие.
Иногда их полезно не закрывать. Например, для решения проблемы лишних отступов меджу inline-элементами (см. заголовок «Skip the closing tag»). На Хабре по этому поводу тоже была большая статья, но сейчас не могу найти.
В PHP, например, тоже считается хорошим тоном не писать закрывающий тег "
Вообще говоря, html — не xml. Закрытие тегов во многих случаях является просто делом привычки.
В PHP, например, тоже считается хорошим тоном не писать закрывающий тег "
?>".Вообще говоря, html — не xml. Закрытие тегов во многих случаях является просто делом привычки.
В PHP закрывающий тег не рекомендуют по причине того, что любой пробел после него попадает в output и если вы не заворачиваете output в буфер, то у вас потенциально может быть ситуация, когда контент — пробелы — уже отправился, а заголовки — ещё нет. Как это соотносится с HTML — непонятно.
Мало как соотносится, это был пример «по аналогии». Хотя по ссылке о лишних отступами между li, которую я привёл чуть выше, наблюдается точно та же проблема — whitespace'ы между несколькими элементами li попадают в документ. Если не писать закрывающий тег, этого не происходит. Так что аналогия не такая уж и далёкая.
>> Иногда их полезно не закрывать.
Прошу прощения, случайно отправилось недописанное.
>> Иногда их полезно не закрывать.
Таких случаев нет. Незакрытые теги порождают неопределённое поведение и ломают работу в IDE. Проблема с inline-block лечится нулевым размером шрифта либо комментированием строки.
>> Вообще говоря, html — не xml. Закрытие тегов во многих случаях является просто делом привычки.
А в JS можно не ставить точку с запятой в конце строки. Ничего хорошего в подобной практике нет.
>> Иногда их полезно не закрывать.
Таких случаев нет. Незакрытые теги порождают неопределённое поведение и ломают работу в IDE. Проблема с inline-block лечится нулевым размером шрифта либо комментированием строки.
>> Вообще говоря, html — не xml. Закрытие тегов во многих случаях является просто делом привычки.
А в JS можно не ставить точку с запятой в конце строки. Ничего хорошего в подобной практике нет.
Незакрытые теги порождают неопределённое поведение и ломают работу в IDE.
Незакрытые теги полностью соответствуют стандартам, поведение определено чётко. Они работают во всех браузерах. Если какая-то среда разработки некорректно с ними работает, то это баг.
>> Если какая-то среда разработки некорректно с ними работает, то это баг.
Незакрытый <p> покалечит folding и автотабуляцию в NetBeans, Komodo, WebStorm/PhpStorm.
>> Незакрытые теги полностью соответствуют стандартам, поведение определено чётко.
habrahabr.ru/post/143452/#comment_4809102 — здесь человек описал, как неоднозначно это будет выглядеть в шаблонах.
Незакрытый <p> покалечит folding и автотабуляцию в NetBeans, Komodo, WebStorm/PhpStorm.
>> Незакрытые теги полностью соответствуют стандартам, поведение определено чётко.
habrahabr.ru/post/143452/#comment_4809102 — здесь человек описал, как неоднозначно это будет выглядеть в шаблонах.
Стоп, Илья! Я не понял этой чехарды с незакрытыми тэгами.
В частности с <p> и <li>.
Если я буду размещать вложенные абзацы и списки не закрывая тэги — как браузеры это отрендерят?
И пофиг что абзац в абзаце это несемантично. Если html5 такой умный, что не разделяет элементы на блочные и инлайновые — то пусть и абзацы по умолчанию воспринимает как инлайновые.
В частности с <p> и <li>.
Если я буду размещать вложенные абзацы и списки не закрывая тэги — как браузеры это отрендерят?
И пофиг что абзац в абзаце это несемантично. Если html5 такой умный, что не разделяет элементы на блочные и инлайновые — то пусть и абзацы по умолчанию воспринимает как инлайновые.
Это я и написал. :)
Проверил в PhpStorm 4 код с тремя tr в table. До сих пор не починили. :( А вот с p всё в порядке, сворачивание работает.
Проверил в PhpStorm 4 код с тремя tr в table. До сих пор не починили. :( А вот с p всё в порядке, сворачивание работает.
Незакрытые теги порождают неопределённое поведениеНеправда. Поведение чётко описано в стандарте HTML. Обычно оно сводится к тому, что тег закрывается в тот момент, когда начинается другой, одноимённый, или же оканчивается родительский тег.
Между прочим, закрытие тегов не всегда помогает «определить» поведение. Например:
<p>Текст1 <p>Текст2</p> Текст3</p>
Этот пример будет воспринят парсером вот так:
<p>Текст1 </p><p>Текст2</p> Текст3
А всё потому, что, по стандарту, тег p не может содержать в себе блочных элементов.
ломают работу в IDEДумаю, в этом случае проблемным местом является IDE, которая не поддерживает стандарт HTML.
Посмотрите и с другой стороны на теги, которые явно не закрыты. Следующая разметка:
<ul>
<li>Текст 1
<li>Текст 2
</ul>
Отрендерится так:
- Текст 1
- Текст 2
Одной точке соответствует один элемент li :) Как по мне, логично.
То же самое с параграфами. Обычный человек задумывается о том, что нужно перевести строку, только в начале параграфа, но не в конце.
Проблемы с таким подходом возникают только в одном случае: если пытаться вопринимать HTML как подмножество XML. Как на уровне кода, так и на уровне собственного понимания.
>> Между прочим, закрытие тегов не всегда помогает «определить» поведение. Посмотрите и с другой стороны на теги, которые явно не закрыты.
Начнётся чехарда — <a> закрываем, <p> не закрываем, <div> закрываем, <li> не закрываем. Оно вам надо? В вёрстке и так головной боли хватает с браузероспецифичными хаками.
>> Проблемы с таким подходом возникают только в одном случае: если пытаться вопринимать HTML как подмножество XML. Как на уровне кода, так и на уровне собственного понимания.
Если хочется визуальной простоты, можно использовать HAML — он сделает за вас всю грязную работу по преобразованию в HTML.
Начнётся чехарда — <a> закрываем, <p> не закрываем, <div> закрываем, <li> не закрываем. Оно вам надо? В вёрстке и так головной боли хватает с браузероспецифичными хаками.
>> Проблемы с таким подходом возникают только в одном случае: если пытаться вопринимать HTML как подмножество XML. Как на уровне кода, так и на уровне собственного понимания.
Если хочется визуальной простоты, можно использовать HAML — он сделает за вас всю грязную работу по преобразованию в HTML.
>> Начнем с того, что есть теги, которые закрывать нельзя: <img>, <input>, <meta>, <hr>, <br>.
<br />
>> Так что отмахнуться от того, что «теги» (точнее, элементы) разные (по предназначению, типичной роли, модели содержимого, DOM-интерфейсу и т.п.), попросту не получится.
Назначение тега никак не должно пересекаться с синтаксисом. Точно так же. как в языках программирования у классов разное предназначение, но синтаксис создания объектов одинаковый:
var a = new Database();
var b = new URLRequest();
var c = new DateTime();
>> Это не «чехарда», это документированная специфика технологии.
В спецификации HTML ещё сказано, что можно значение атрибутов без кавычек писать в некоторых случаях. W3C предпочли не бороться с бардаком, а узаконить его.
>> И кто не может ее осилить (хотя не так уж она сложна, особенно если абстрагироваться от «тегов» и начать мыслить структурой страницы, как ее видит и показывает браузер) — надо ли лезть в эту воду? ;)
Кажется мы подошли к моменту, когда начинаются завуалированные упрёки в профнепригодности. На эту тему я говорить, пожалуй, не хочу.
<br />
>> Так что отмахнуться от того, что «теги» (точнее, элементы) разные (по предназначению, типичной роли, модели содержимого, DOM-интерфейсу и т.п.), попросту не получится.
Назначение тега никак не должно пересекаться с синтаксисом. Точно так же. как в языках программирования у классов разное предназначение, но синтаксис создания объектов одинаковый:
var a = new Database();
var b = new URLRequest();
var c = new DateTime();
>> Это не «чехарда», это документированная специфика технологии.
В спецификации HTML ещё сказано, что можно значение атрибутов без кавычек писать в некоторых случаях. W3C предпочли не бороться с бардаком, а узаконить его.
>> И кто не может ее осилить (хотя не так уж она сложна, особенно если абстрагироваться от «тегов» и начать мыслить структурой страницы, как ее видит и показывает браузер) — надо ли лезть в эту воду? ;)
Кажется мы подошли к моменту, когда начинаются завуалированные упрёки в профнепригодности. На эту тему я говорить, пожалуй, не хочу.
>> Виноват, приношу извинения! Действительно, получилось похоже на личный выпад, хотя, честное слово, и в мыслях не было, я имел в виду исключительно «порог вхождения» для новичков (который часто считают «неприлично низким»).
Окей, без проблем :) Что касается порога входа, так он ведь действительно низкий.
>> Но тем не менее пересекается — это факт (разница между пустыми и непустыми элементами в т.ч. синтаксическая). В ЯП тоже бывает разный синтаксис для создания разных объектов, и в этом нет никакой трагедии.
Трагедии, безусловно, нет. Однако все потребности HTML вполне покрываются стандартным XML-синтаксисом.
>> Узаконить бардак (точнее, исторически сложившуюся объективную реальность) решили производители браузеров, по очевидным прагматическим соображениям (совместимость с существующим контентом). «Бороться» с этим можно примерно с тем же успехом, как законодательно отменять иррациональность числа «пи» (как в каком-то американском штате:).
Бороться с бардаком можно и нужно. То, что поддерживается исключительно ради обратной совместимости, объявлять в спецификациях новых версий HTML и CSS как obsolete. Публиковать не только спецификации, но и гайдлайны по грамотному использованию возможностей языка. Прислушиваться к тому, что говорят девелоперы, а не отклонять просьбу о введении background-position-x/-y, потому что мудрецы из комитета не видят теоретической необходимости. Перестать сношать вола на темы типа «color или colour?». Но от W3C не дождёшься :(
Окей, без проблем :) Что касается порога входа, так он ведь действительно низкий.
>> Но тем не менее пересекается — это факт (разница между пустыми и непустыми элементами в т.ч. синтаксическая). В ЯП тоже бывает разный синтаксис для создания разных объектов, и в этом нет никакой трагедии.
Трагедии, безусловно, нет. Однако все потребности HTML вполне покрываются стандартным XML-синтаксисом.
>> Узаконить бардак (точнее, исторически сложившуюся объективную реальность) решили производители браузеров, по очевидным прагматическим соображениям (совместимость с существующим контентом). «Бороться» с этим можно примерно с тем же успехом, как законодательно отменять иррациональность числа «пи» (как в каком-то американском штате:).
Бороться с бардаком можно и нужно. То, что поддерживается исключительно ради обратной совместимости, объявлять в спецификациях новых версий HTML и CSS как obsolete. Публиковать не только спецификации, но и гайдлайны по грамотному использованию возможностей языка. Прислушиваться к тому, что говорят девелоперы, а не отклонять просьбу о введении background-position-x/-y, потому что мудрецы из комитета не видят теоретической необходимости. Перестать сношать вола на темы типа «color или colour?». Но от W3C не дождёшься :(
CSS-ки минифицируются перед выходом в продакшен.
А на мой взгляд отсутствие хеда и боди есть гуд
1. этот вариант (мне) читается легче — содержимое хеда и боди абсолютно разные и не пересекаются, плюс они почти всегда пустые, без атрибутов
2. текста меньше и отступы слева не нужны
в итоге кол-во «кпд» информации выше
байты — деньги, но вот тут они ни при чём
1. этот вариант (мне) читается легче — содержимое хеда и боди абсолютно разные и не пересекаются, плюс они почти всегда пустые, без атрибутов
2. текста меньше и отступы слева не нужны
в итоге кол-во «кпд» информации выше
байты — деньги, но вот тут они ни при чём
Вобщем-то гугл делает также как и я на протяжении многих лет, единственный момент — я не заморачиваюсь по поводу пробелов и табов.
Посмотрел исходник gmail-вской страничке, и там сразу:
:)
Если серьезно, то гугл — умничка, что популяризирует стандартизацию вот таких вещей для программистов. К примеру, мы пишем на С++, и для проверки стиля кода мы взяли их валидатор и немного подпилили. Работать стало очень удобно. Так что, валидацию — в массы!
<!DOCTYPE html> <html lang="ru"> <head> <meta content="text/html; charset=utf-8" http-equiv="Content-Type"> <title>Gmail</title>
:)
Если серьезно, то гугл — умничка, что популяризирует стандартизацию вот таких вещей для программистов. К примеру, мы пишем на С++, и для проверки стиля кода мы взяли их валидатор и немного подпилили. Работать стало очень удобно. Так что, валидацию — в массы!
А на сколько эти методы близки к яндекс роботу?
И есть ли какой-нибудь софт, правящий табуляцию и пробелы в коде — а то больно много строк, руками править устану. Помню как-то в VS делал давным давно — но там ведь под HTML и CSS не заточено, верно?
И есть ли какой-нибудь софт, правящий табуляцию и пробелы в коде — а то больно много строк, руками править устану. Помню как-то в VS делал давным давно — но там ведь под HTML и CSS не заточено, верно?
Теперь я понял, что личные законы нужно вычеркивать и полагаться на советы большого гиганта. Ему же индексировать, в первую очередь :D
Как бы все было бы хорошо, если бы не одно «но».
Собственно, оно заключается в том, что Корпорация Добра не слишком ли много одеяла начала на себя тянуть?
Правила для оформления и форматирования должны быть, да, но поисковому гиганту нужно заниматься своим делом, то есть поиском, а с правилами уж как-нить без них разберутся.
С таким успехом следующим шагом будут рекомендации от Гугла как правильно писать письма, чтобы они быстрее доходили и не попадали в спам, а также в какой цвет красить крыши домов и как равнять рельеф, чтобы на Мапсах изображение было более качественным.
Собственно, оно заключается в том, что Корпорация Добра не слишком ли много одеяла начала на себя тянуть?
Правила для оформления и форматирования должны быть, да, но поисковому гиганту нужно заниматься своим делом, то есть поиском, а с правилами уж как-нить без них разберутся.
С таким успехом следующим шагом будут рекомендации от Гугла как правильно писать письма, чтобы они быстрее доходили и не попадали в спам, а также в какой цвет красить крыши домов и как равнять рельеф, чтобы на Мапсах изображение было более качественным.
Для уменьшения размера файлов и лучшей читаемости кода можно опускать необязательные теги.
Ага. Опустишь. А потом выяснится, что в их же гугловском Webmaster Tools нужно что-то поместить именно в head, который внезапно становится обязательным. В целом, смысла опускать html, head, body не вижу.
Плюс немало HTML-редакторов клинит при незакрытых тегах. Автоматически переформатируешь таблицу с незакрытыми тегами в PhpStorm — от увиденной лесенки волосы дыбом встанут. Иногда незакрытые теги в принципе мешают корректно отформатировать код, например, как правильно?
<p>text
<? include(...) ?>
<p>text
<? include(...) ?>
Зависит от того, что внутри включаемого файла — блок или инлайн. Если же тег <p> закрыть, неоднозначность пропадает.
Я, конечно, за минимализм, но он далеко не всегда уместен.
Я бы еще добавил — в css удобнее сначала указывать свойства, влияющие на положение элемента (display,width,height,float,clear,margin), а затем свойства, описывающие его внешний вид. Таким образом за длинным описанием бэграунда и шрифта не потеряется какой-нибудь clear:right.
читаю как верстальщик и просто голова кипит :) как с такими согласится… просто многие вещи то не поддерживаются еще :)) это больше мечтание на будущее чем рекомендация у использованию
хотя конечно многие предметы конечно использую
PS но вот два пробела вместо табуляции :)) как религия не позволяет делать
хотя конечно многие предметы конечно использую
PS но вот два пробела вместо табуляции :)) как религия не позволяет делать
>Опускайте кодировку для сss-файлов
Поскольку css линкуется с текущей страницей через link тег, то кодировка должна указывается в charset атрибуте.
В случае же единого проекта (в смысле, что разработчик имеет доступ и к коду и к конфигурации сервера) наиболее разумно использовать абсолютно везде utf-8 и отдавать этот тип кодировки в HTTP заголовке.
Поскольку css линкуется с текущей страницей через link тег, то кодировка должна указывается в charset атрибуте.
В случае же единого проекта (в смысле, что разработчик имеет доступ и к коду и к конфигурации сервера) наиболее разумно использовать абсолютно везде utf-8 и отдавать этот тип кодировки в HTTP заголовке.
>Отмечайте задачи для списка дел с помощью TODO
Я бы рекомендовал немного другой формат. По коду должно быть сразу видно, когда был оставлен этот комментарий без необходимости подъема истории в репозитории. А формат такой:
[примечание] YYYY-MM-DD никнейм_автора: комментарий,
где примечание — тип комметария (TODO, FIXME, NOTE);
YYYY-MM-DD — дата с заполнителем 0;
никнейм_автора — ник автора камента, все ники в рамках проекта на протяжении все его истории должны быть уникальны.
Пример:
Я бы рекомендовал немного другой формат. По коду должно быть сразу видно, когда был оставлен этот комментарий без необходимости подъема истории в репозитории. А формат такой:
[примечание] YYYY-MM-DD никнейм_автора: комментарий,
где примечание — тип комметария (TODO, FIXME, NOTE);
YYYY-MM-DD — дата с заполнителем 0;
никнейм_автора — ник автора камента, все ники в рамках проекта на протяжении все его истории должны быть уникальны.
Пример:
// [TODO] 2012-05-08 alekciy: Съешь ещё этих мягких французских булок.
Интересное руководство, но думаю не стоит принимать все буквально. Некоторые вещи, можно взять на вооружение. Но избавляться от,, и т.д… не буду. Это все равно что фалангу пальца отрезать
А зачем указывать
? Я это делаю в заголовке: Content-Type: text/html; charset=UTF-8Имел ввиду meta тег с content-type
Незакрытые теги li и tr режут глаз, но выглядят довольно интересно.
Ирония в том, что не хватило сил соблюсти свои же правила в руководстве по стилю:
<STYLEPOINT title="Section comments">
<SUMMARY>
Group sections by a section comment (optional).
</SUMMARY>
<BODY>
Не закрывать теги? Убило мозг.
Этот документ наводит на ряд размышлений:
1. Либо квалификация специалистов в google, как и в любой другой организации, неоднородная, либо это открытый саботаж браузеров от сторонних производителей.
2. Это не конвенции. Конвенции должны учитывать многие варианты и плясать от существующего положения вещей, тут же свод советов от чего нужно отказываться, в своем роде видение компанией будущих стандартов.
3. Незакрытые теги, как самый спорный момент, неприемлемы несколько по иной причине нежели «ой как непривычно». Многие языки разметки вполне неплохо живут без явных открытий и закрытий форматирования. НО.
Какой тег сможет автоматически закрыться каким не прописано в стандарте html и вообще нигде, движки могут понимать это очень по-разному. Требовать этого от верстальщика, не предлагая ни ему ни разработчикам браузеров никакого стандарта нельзя. Так что скорее я все-таки склоняюсь к мысли о саботаже.
Про экономию байтов. Да не смешите мои тапочки. Содержимое html кода это не то, на чем имеет смысл экономить, так как это одна из худших форм оптимизации. Если они так этого хотят от индексируемых сайтов пусть первые подадут пример, вместо того ужаса, который представляет из себя верстка их сервисов. (С переходом на новые интерфейсы еще и очень глючного ужаса)
1. Либо квалификация специалистов в google, как и в любой другой организации, неоднородная, либо это открытый саботаж браузеров от сторонних производителей.
2. Это не конвенции. Конвенции должны учитывать многие варианты и плясать от существующего положения вещей, тут же свод советов от чего нужно отказываться, в своем роде видение компанией будущих стандартов.
3. Незакрытые теги, как самый спорный момент, неприемлемы несколько по иной причине нежели «ой как непривычно». Многие языки разметки вполне неплохо живут без явных открытий и закрытий форматирования. НО.
Какой тег сможет автоматически закрыться каким не прописано в стандарте html и вообще нигде, движки могут понимать это очень по-разному. Требовать этого от верстальщика, не предлагая ни ему ни разработчикам браузеров никакого стандарта нельзя. Так что скорее я все-таки склоняюсь к мысли о саботаже.
Про экономию байтов. Да не смешите мои тапочки. Содержимое html кода это не то, на чем имеет смысл экономить, так как это одна из худших форм оптимизации. Если они так этого хотят от индексируемых сайтов пусть первые подадут пример, вместо того ужаса, который представляет из себя верстка их сервисов. (С переходом на новые интерфейсы еще и очень глючного ужаса)
Текучие стандарты палка о многих концах, особенно whatwg, например в соответствии с ним вообще нет никакого html5. Это все драфты с часто непонятным статусом реализации, включать их в рекомендации и конвенции мягко говоря преждевременно, тестирование на валидное создание дерева тоже нет.
И в целом это не очень здоровая практика, так как изменение содержимого тега может повлечь за собой изменение его статуса как закрытого или открытого, что, в свою очередь, приведет к увеличению количества ошибок.
И в целом это не очень здоровая практика, так как изменение содержимого тега может повлечь за собой изменение его статуса как закрытого или открытого, что, в свою очередь, приведет к увеличению количества ошибок.
изменение содержимого тега может повлечь за собой изменение его статуса как закрытого или открытогоЯ выше уже приводил пример, из которого видно, что изменение содержимого может форсировать «досрочное» закрытие тега вне зависимости от того, был ли он явно закрыт разработчиком:
<p>Текст1 <p>Текст2</p> Текст3</p>
Этот пример будет воспринят парсером вот так:
<p>Текст1 </p><p>Текст2</p> Текст3
А всё потому, что, по стандарту, тег p не может содержать в себе блочных элементов.
Да, то есть преобразование в DOM идет по неочевидному правило, в коде присутствует вложенность, в DOM линейка с последний выпавшим элементом. Мне вообще кажется что html сильно страдает от подобной двойственности. Руки чешутся делать нечто вроде Текст1 Текст2 Текст3 но это некорректно с точки зрения индексации, как и, например, таблицы div-ами :(
Это правило неочевидно только в том случае, если вы воспринимаете HTML как XML. В XML'е вложенность и сохранение изначальной структуры — это святое. В HTML же есть много нюансов.
Дело в том, что и HTML, и XML были основаны на SGML, отсюда и теговый синтакс. Но SGML не определял, является ли логическая вложенность следствием структурной вложенности. XML в некоторой степени более жёсток в этом отношении, но не HTML.
Дело в том, что и HTML, и XML были основаны на SGML, отсюда и теговый синтакс. Но SGML не определял, является ли логическая вложенность следствием структурной вложенности. XML в некоторой степени более жёсток в этом отношении, но не HTML.
Ну, я как раз имел в виду, что парсеры HTML в браузерах очень «мягки» — что бы разработчик ни написал, парсер попытается угадать семантику и построит DOM хотя бы в каком-то виде.
В XML же, per se, вообще нет семантики. Семантика задаётся структурой конкретного XML-based формата, и там уже, обычно, ни от семантики, ни от структуры, нельзя отойти ни на шаг (хотя, конечно, тоже depends).
В общем, мы с вами говорим об одном и том же, но разными словами :)
В XML же, per se, вообще нет семантики. Семантика задаётся структурой конкретного XML-based формата, и там уже, обычно, ни от семантики, ни от структуры, нельзя отойти ни на шаг (хотя, конечно, тоже depends).
В общем, мы с вами говорим об одном и том же, но разными словами :)
Я бы ещё добавил «используйте HTML5, но пишите так, чтобы он был валидным XML» (закрывайте теги, б-ть!). Увы, некоторые примеры в статье демонстрируют обратное, и это огорчает.
На самом деле не совсем понятно кому адресованы эти рекомендации, но использовать XML-сериализацю (XHTML5) в HTML5 можно:
PS:
— первая строка обязательна только для документов имеющих кодировку отличную от UTF-8.
— вторая строка опциональна.
— третья обязательна
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title> Title </title>
<meta charset="UTF-8" />
</head>
<body>
<input type="text" placeholder="input text" />
</body>
</html>
PS:
— первая строка обязательна только для документов имеющих кодировку отличную от UTF-8.
— вторая строка опциональна.
— третья обязательна
Замечательное руководство. Только не совсем понятно, что будет тем, кто ему будут следовать?
Улучшение видимости сайта в Гугле? — Сомнительно.
Большая производительность Хрома на сайте? — Да он и так неплохо работает.
Гугл решил взять на себя руководство над верстальщиками и вебмастерами? — Фигу ему с маслом.
Зачем же нужно это руководство?
Улучшение видимости сайта в Гугле? — Сомнительно.
Большая производительность Хрома на сайте? — Да он и так неплохо работает.
Гугл решил взять на себя руководство над верстальщиками и вебмастерами? — Фигу ему с маслом.
Зачем же нужно это руководство?
Не указывайте протокол при включении ресурсов на страницу.Недавно, изучая статистику посещений сайта, обнаружил, что некоторые браузеры ссылку вида //host.name/path воспринимают всё-таки как путь от корня текущего сайта, а не как текущий_протокол://host.name/path и в результате шлют запросы не к тому серверу, куда задумано, а к текущему, то есть на текущий_протокол://текущий_сайт//host.name/path.
Получается, что надо либо в ссылках указывать протокол явно (тратить на это аж целых пять байт, а то и шесть!), либо настраивать перенаправление на своём сайте (в апаче — mod_alias или mod_rewrite).
Ух ё. Был в шоке от
<li>Маша
честно. Не знал, что так можно. И с аналогично.
И ещё я был сильно удивлён когда проверил bootstrap.css в jigsaw.w3.org/css-validator/
К сожалению, мы обнаружили следующие ошибки (835)
<li>Маша
честно. Не знал, что так можно. И с аналогично.
И ещё я был сильно удивлён когда проверил bootstrap.css в jigsaw.w3.org/css-validator/
К сожалению, мы обнаружили следующие ошибки (835)
Согласен со всем, кроме использования пробелов вместо табуляции :P
lea.verou.me/2012/01/why-tabs-are-clearly-superior/
lea.verou.me/2012/01/why-tabs-are-clearly-superior/
Насчет мнемоников спорно, т.к. в редакторе не всегда можно замыленным глазом отличить
—, –, -
> background: url(//www.google.com/images/example);
выглядит бредовато…
про мнемоники — спорно, про неиспользование необязательных тегов (html, head, body) — тоже.
выглядит бредовато…
про мнемоники — спорно, про неиспользование необязательных тегов (html, head, body) — тоже.
> HTML5 (HTML синтаксис) рекомендуется для всех html-документов: <!DOCTYPE html>.
Тогда уж так:
<!doctype html>
как это на (http://www.google.ru/). Или на //www.google.ru/…? :)
Тогда уж так:
<!doctype html>
как это на (http://www.google.ru/). Или на //www.google.ru/…? :)
Отступы
Всегда используйте для отступа два пробела.
Не используйте табуляцию и не смешивайте табуляцию с пробелами.
то есть 2 пробела = 2 байта — круче чем 1 табуляция = 1 байт?
меня просто бесит когда я вижу в качестве отступов пробелы. это конечно сугубо мои проблемы, но начать педалить дальше пока не приведу код к нормальному виду с отступами в виде табуляций и т.п. просто не получается
Сделал исследование маленькое — главную страницу сохранил заменил пробелы на табуляцию — получил — 25kb веса страницы. убрал пустые линии, пробелы и отступы не значащие при сохранении отступов в коде для «читабельности» — еще минус 10kb
все я вам пожаловался :(
Shift + Tab лучше чем 2 backspace
java-криптопроцессор, используется в Symantec Network Security для ЭЦП логов.
/* Не рекомендуется: используется подчеркивание вместо дефиса */
.error_status {}Не согласен. Два раза клацнул и выделил, а так нужно мышкой проводить, экономит время.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Руководство по оформлению HTML/CSS кода от Google