Стандарты кодирования для HTML, CSS и JavaScript’a

Уже давненько я поднимал вопрос о стандартах кодирования в PHP, и вот решился описать правила хорошего тона для HTML, CSS и JavaScript’a.

Тут дела обстоят немного сложнее – ибо вменяемых стандартов я так и не обнаружил, следовательно мы пойдем своим путем. Для начала нам необходимо выделить несколько правил дабы улучшить читаемость кода – одно из них – “разделяй и властвуй” – ибо есть что:

HTML – markup layer – верстка
CSS – presentation layer – представление
JavaScript – behavioural layer – поведение

Но давайте по порядку…

Strict DOCTYPE

Не будем вступать в дискуссию, какой стандарт лучше HTML 4.0 иль XHTML 1.0 – оба они хороши и вполне подходят в качестве стандарта, но я придерживаюсь XHTML’a ;). А вот насчет DOCTYPE – то пора уже взрослеть и переходить на strict… ~~если конечно у Вас не табличная верстка, иначе прийдется остаться на transitional~~…

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">

Ссылки:

Данная статья написана в далёком 2008-м году, а сейчас HTML5 там правит бал, а всё что выше – уж давно кануло в Лету

Кодировка и спец-символы

Кодировка UTF-8 и точка. Не надо разводить холивар, принимаем сие как стандарт.

Далее нам надо бы сию кодировочку прописать в нашем HTML’е – для этого необходимо поместить соответствующий тег внутрь тэга , но есть небольшой подводный камень – есть большой соблазн запихнуть <title> до объявления кодировки – не ведитесь – иначе браузер может заняться произволом и попытается определить кодировку самостоятельно по тексту в <title>, и обычно не очень удачно.

<head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
    <title>Anton Shevchuk's Home</title>
</head>

Насчет символов аля &, <, > – если вы хотите соответствовать стандартам – то заменяем сие неподобство на соответствующую последовательность &, <, >

Валидация

Зеленый текст W3C validator’а – это наша цель, так что не забывайте закрывать теги, да прописывать обязательные параметры…

<!-- найди ошибки - получи пирожок -->
<p>Lorem ipsum dolor sit amet, consectetuer adipiscing elit. 
Nunc urna metus, ultricies eu, congue vel, laoreet id, justo.
Aliquam fermentum adipiscing pede. Suspendisse dapibus ornare
quam. Lorem ipsum dolor sit amet, consectetuer adipiscing elit.<p>
<a href="/index.php?mod=default&act=image"><img src="/img001.jpg"></a>
<!-- подсказка - их тут пять (XHTML 1.0 Strict)-->

Ссылки:

The W3C Markup Validation Service
XHTML-CSS Validator

Форматирование отступами

Отступы – невидимые в браузере, но такие незаменимые для верстки (X)HTML’а – они в разы повышают читаемость кода.
И их использование – просто песня – начинаешь новый вложенный тег – сделай отступ, закрываешь – убери.
В качестве отступа принято использовать символ табуляции (tab) либо несколько пробелов (обычно 4).

Сравните код:

    <ul class="bigBarNavigation"><li>
<a href="/">Home</a></li><li>
<a href="/about.html">About Us</a></li><li>
<a href="/contact.html">Contact Us</a><div class="subMenu"><!-- Example --></div></li></ul>

И код с отступами:

<ul class="bigBarNavigation">
    <li><a href="/">Home</a></li>
    <li><a href="/about.html">About Us</a></li>
    <li>
        <a href="/contact.html">Contact Us</a>
        <div class="subMenu"><!-- Example --></div>
    </li>
</ul>

Точно так же можете применять отступы в вашем CSS файле:

#header  { .. }
    #header h1 { .. }
    #header h2 { .. }

#content { .. }
    #content .title { .. }
    #content .post  { .. }

P.S. Когда займетесь блошиной оптимизацией вашего сайта, то решите, что 4 пробела – это в 4-ре раза больше трафика чем один символ табуляции :)

Теги любят порядок

Очень часто в шапке нашего сайта мы пишем тег <h1> с названием нашего сайта, да еще и оформляем его ссылкой на главную страницу сайта, и для этого обрамляем наш тег <h1> в <a>. Большинство браузеров адекватно отобразит нам сие творение, но с технической точки зрения это не верно, т.к. тег <a> отображается как inline, а <h1> как block, а block элементы не должны располагаться в inline элементах (это bad practices).

Плохо:

<a href="/index.html"><h1>Мой сайт</h1></a>

Хорошо:

<h1><a href="/index.html">Мой сайт</a></h1>

Ссылки:

Свойства CSS – display

“Дивная” верстка

В английском языке есть термин “divits” – сим термином награждают HTML разметку с чрезмерным использованием div’ов без потребности, я же обзываю такие творения “дивными”. Обычно таким грешат новички, которые для применения стилей CSS оборачивают элементы в div’ы, что и приводит к их размножению без нужды.

<div class="topNav">
    <ul class="bigBarNavigation">
        <li><a href="/">Home</a></li>
        <li><a href="/about.html">About Us</a></li>
        <li>
            <a href="/contact.html">Contact Us</a>
            <div class="subMenu"><!-- Example --></div>
        </li>
    </ul>
</div>

В данном примере, div (с классом “topNav”), оборачивает ul (с классом “bigBarNavigation”). Оба, div и ul, являются блочными элементами, так что нам нет необходимости заворачивать <ul> в <div>; все, что мы можем сделать с <div> мы можем проделать и с <ul>.

Выбираем правильные имена

Самое время обсудить правила именования id и class’ов. Возьмем пример из предыдущего абзаца – у нас использовался неупорядоченные список с идентификатором “bigBarNavigation.” “Navigation” – эта часть имени несет смысловую нагрузку о содержимом списка, но “big” и “Bar” относится лишь к внешнему представлению, актуальному на данный момент, но если мы изменим дизайн сайта (и, скажем, навигация у нас будет выпадающим меню), то данный ID будет неактуальным и добавит лишь путаницы.

<h1>Мой сайт о <span class="blue italic">ёжиках</span></h1>
<!-- Сегодня blue и italic, а завтра red и bold? -->

Приведу примеры “правильных” id и class’ов: “mainNav”, “subNav”, “sidebar”, “footer”, “metaData”, а так же “неправильные” имена (которые описывают дизайн): “bigBoldHeader”, “leftSidebar”, “roundedBox”.

CSS’у CSS’ное

Очень часто, в меню сайтов, используют написание текста в верхнем регистре. Конечно это легко сделать используя клавишу Shift на клавиатуре, но мы то не просто так CSS изучали, так что сей функционал стоит перенести в CSS, для это цели стоит воспользоваться {text-transform: uppercase}. Теперь, если вы вдруг передумаете, Вы сможете с легкостью изменить вид вашего меню изменив лишь одну строчку в CSS.

HTML практически без изменений:

<ul>
    <li><a href="/index.html">Home</a></li>
    <!-- ... -->
</ul>

И совсем чуть-чуть изменений в CSS:

ul li a {text-transform: uppercase}

Ссылки:

Class/id для <body>

Зачем? Объясню на примере – представьте – у Вас есть страница сайта на которой расположение элементов иное нежели на всех остальных, дабы сие сотворить Вам необходимо внести изменения в существующий стиль для div’a с id=”mainContent”, для этого создаете новый id=”mainContent-500″, создаете и вносите изменения, и так для каждого элемента в нашем шаблоне, а если у нас таких страниц несколько?, а потом сие еще внедрять разработчику сайта…

Если же у body был класс, то мы бы добавили к нему еще один (<body class="blogLayout width-500">) и уже в CSS прописывали изменения для всех дочерних элементов (не зря ж это каскадная таблица стилей). Таким образом мы очень сильно упрощаем жизнь разработчикам, которые будут внедрять наш дизайн.

body.width-500 #mainContent {
   width:500px;
}

Логический порядок

Если это вообще возможно, старайтесь придерживаться строго порядка при расположении элементов, приведу пример:

<body class="body">
    <div id="header"></div>
    <div id="wrapper">
        <div id="content"></div>
    </div>
    <div id="sidebar"></div>
    <div id="footer"></div>
</body>

CSS во внешних файлах

Вы можете добавить описание стилей CSS в самом теле HTML, используя соответствующий тег <style type="text/css" media="screen">...</style>, но только за такое творчество хочется дать по рукам, ведь такой стиль будет применяться только для определенной страницы (хотя иногда в этом есть необходимость), гораздо удобней вынести сие во внешний файл CSS.

Вроде смотрится неплохо:

<style type="text/css" media="screen">
    body { background:pink }
    /* etc */    
</style>

Но таки так лучше:

<link rel="stylesheet" href="/css/style.css" type="text/css" media="screen" charset="utf-8" />

То же самое касается и JavaScript’a, но о нем чуть позже.

Стандарты кодирования CSS

К сожалению я не нашел стандартов для написания файлов стилей, лишь пожелания:

Комментарии к элементам
Форматирование отступам – от этого не все в восторге
Правильные имена селекторов – уже обсуждалось выше

Ссылки:

Отделяем Javascript от HTML

Нам следует отделить всю функциональность JavaScript’а от HTML’а и запихнуть её в отдельный файл. Для этой цели лучше всего нам подойдет jQuery фреймверк, ибо удобно, быстро, и красиво (да и взгляните на график)

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

Плохо:

<a onClick="doSomething()" href="#">Click!</a>

Хорошо:
Все обработчики событий помещаем во внешний файл, который подключим в начале страницы используя тег <script>. Соответственно немного переделаем предыдущий код:

<a href="backuplink.html" class="doSomething">Click!</a>

В JavaScript файле будет что-то типа:

...  
$('a.doSomething').click(function(){  
    // Do something here!  
    alert('You did something, woo hoo!');  
});  
...

Семантическая верстка

Возвращаясь к теме верстки стоит упомянуть – дабы писать красивый JavaScript код с использованием jQuery нам необходима максимально прозрачная структура документа.

Очень Плохо:

<table>  
    <tr>  
        <td onclick="doSomething();">First Option</td>  
        <td>First option description</td>  
    </tr>  
    <tr>  
        <td onclick="doSomething();">Second Option</td>  
        <td>Second option description</td>  
    </tr>  
</table>

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

<dl>  
    <dt onclick="doSomething();">First Option</dt>  
    <dd>First option description</dd>  
    <dt onclick="doSomething();">Second Option</dt>  
    <dd>Second option description</dd>  
</dl>

Хорошо:
Мы убрали все лишние, и добавили id к элементу dl – дабы в JavaScript’е мы смогли добавить обработчики событий для элементов dt:

<dl id="OptionList">  
    <dt>First Option</dt>  
    <dd>First option description</dd>  
    <dt>Second Option</dt>  
    <dd>Second option description</dd>  
</dl>

К примеру вот так будет выглядеть обработчик событий:

$('#OptionList dt').click(function(){
    /* do something */
});

Лечим JavaScript зависимость

При разработке web-приложений стоит избегать JavaScript зависимости, т.е. наш сайт должен работать и при отключенном JavaScript’e, конечно, каких-то красивостей не будет, но сайт должен работать.

Плохо:

Приведу простейший пример, в данном случае, в зависимости от времени в браузере появится надпись “Доброе утро!” либо “Добрый день!”, но стоит нам отключить JavaScript, и пользователь не увидит ни то, ни другое приветствие.

var now = new Date();  
if(now.getHours() < 12)  
    document.write('Доброе утро!');  
else  
    document.write('Добрый день!');

;

Хорошо:

Приветствие размещается в теле странички:

<p title="Good Day Message">Доброе утро!</p>

И заменяется другим приветствием в зависимости от времени суток:

var now = new Date();  
if(now.getHours() >= 12)  
{  
    var goodDay = $('p[title="Good Day Message"]');  
    goodDay.text('Добрый день!');  
}

Да при отключенном JavaScript’е пользователю будет показано неверное приветствие, но это все же лучше чем ничего, да и пример этот взят с потолка – но ведь нам главное понять суть проблемы.

Теперь приведу более сложный пример, реализация которого невозможна без изменений серверной части нашего приложения. Давайте сделаем загрузка контента страницы посредством AJAX’а, но при этом оставим поддержку браузеров с отключенным JavaScripti’om, возьмем уже знакомый нам пример с меню сайта:

<ul class="Navigation">
    <li><a href="/">Home</a></li>
    <li><a href="/about.html">About Us</a></li>
    <li><a href="/contact.html">Contact Us</a></li>
</ul>
<div id="MainContent"><!-- Content --></div>

Данный пример работает у нас без JavaScript’a, все страницы в нашем меню используют один и тот же шаблон для вывода информации, и по факту у нас изменяется лишь содержимое div’a с id=”MainContent”. Естественно можно улучшить данный функционал используя для загрузки контента AJAX – для этого добавим следующий код:

$(document).ready(function()  
{
    // вешаем обработчик на все ссылки в нашем меню Navigation
    $("ul.Navigation a").click(function(){
        var url = $(this).attr("href"); // возьмем ссылку
            url =+ "?ajax=true";        // добавим к ней параметр ajax=true
        $("#MainContent").load(url);    // загружаем обновленное содержимое
        return false;                   // возвращаем false - дабы не сработал переход по ссылке
    });
});

В данном примере мы предполагаем, что сервер видя параметр ajax=true вернет нам не полностью всю страницу, а лишь обновление для div’a с id=”MainContent” (конечно сервер может быть умнее и не требовать явного указания на использования AJAX’а, а вполне удовлетвориться словив header X_REQUESTED_WITH со значением XMLHttpRequest)

Событие onload

Обычно все Javascript события вешались на “onload” тега <body> – это позволяло нам выполнять их по завершению загрузки страницы. Забудьте это.
jQuery предоставляет нам специальный метод, называемый “ready”, именно он, позволит нам выполнять код после полной загрузки DOM. Именно благодаря ему, мы можем внедрять ненавязчивые скрипты, при этом полностью отделив Javascript от разметки. Используя $(document).ready(), мы можем поставить в очередь целый ряд событий и все они будут выполнены после загрузки страницы.

~~Слайды, слайды~~…

Плохо
Приведу пример кода для отображения alert-сообщения с текстом “Hello World”, без использования jQuery и события onload:

alert('Hello World');

Хорошо
Old-school style – хорошо, коли у Вас нет необходимости во фреймворках:

  window.onload = (function(){
    alert('Hello World');
  });

А теперь с использованием jQuery напишем следующий скрипт:

$(document).ready(function()  
{  
    alert('Hello World');  
});

Как видите – действительно просто.

Стандарты кодирования JavaScript

Хорошо, что мы определились с тем, что JavaScript у нас лежит у нас в отдельном файле, но надо бы его привести в божеский вид, т.е. нам нужны стандарты кодирования:

Написание комментариев, так же является хорошим тоном, но если они еще и будут помогать в генерации документации – будет лучше:

Так же правилом хорошего тона является сжатия исходных кодов JavaScript’а для уменьшения времени загрузки (для live-сервера):

Сравнение средств компрессия для JavaScript’ов

P.S.

Если с jQuery у Вас возникли трудности, то советую почитать следующие статьи:

А ещё лучше – скачайте и изучите учебник jQuery для начинающих

Данная статья подготовлена по материалам:

73 thoughts on “Стандарты кодирования для HTML, CSS и JavaScript’a”

Dmitry A. Soshnikov says:

2008-11-20 at 14:35

@Zeroglif

… не обязательно и непосредственно от js далеко.

да не суть, я этим и отметил, что в данном случае речь велась не о стандарте кодирования JS, а об этой тактике в плане “сайт без JS” =) просто слово такое подобрал – прием )
Alex says:

2008-11-20 at 17:28

Кроме того, я так понимаю, что сайты написанные с использованием JSF вообще не работают с отключённым JS, поэтому тут можно не заморачиваться относительно JS-зависимости.
Zeroglif says:

2008-11-20 at 18:27

@Dmitry A. Soshnikov

Интересный философский ;) пост, замечу только одно – им не пофигу абсолютно, как ты пишешь, они не просто берут ставку программиста на уровне абстракции, они заодно прихватывают ставку пиар-менеджера абстракции, ставку специалиста по сравнительному анализу абстракция vs. old-school (алерт или не-алерт) и т.д. В итоге – церковь. Самовозводящаяся. На чём? На невежестве, на лени, на нехватке времени, на впечатлении, на коммерческих интересах…
smart says:

2008-11-20 at 20:51

Да, соглашусь с вышеотписавшимися – слишком много про jQuery. Если статья о общих принципах – то стоит сразу всех задисклеймерить, что примеры на jQuery и те, кто все же любят prototype или Moo – могут написать свои примерыю За что им будет публичная благодарность, венки и регалии.

Не соглашусь по поводу “придирчивости” к ссылкам на внешний JS/CSS, вынесение туда кода и прочих элементах “хорошего” тона. Стандарты стандартами, тоны тонами, это все очень замечательно и требовать их соблюдение нужно в любом случае, но не забывайте, что вы делаете ваши проекты прежде всего для людей, а не для машин. И тут уже в конкретном случае исходя из обстановки лучше решать, что нужно – отдельный CSS-файл или CSS-раздел в теге head для исключения еще нескольких запросов на сторону сервера за файлами. Эта проблема частично решается проксирующими nginx/lighthttpd, но запрос всегда есть запрос, так что тут нужно думать “по обстоятельствам”.

ИМХО статьи, которые призваны научить “что такое хорошо, а что такое плохо” – всего лишь лишний повод для холивара. Бывалым они не нужны, т.к. те и сами про это знают, а новичкам – если они этого еще не знают и не нашли где-то в манах – то уже и не узнают, и даже не будут стремиться узнать V_v, пока не начнешь отправлять.
Dmitry Baranovskiy says:

2008-11-20 at 23:47

@Мудоид «Кстати, я склонен к тому, что навешивать события лучше и правильнее всего через addEventListener типа такого … правда кажется с этим в IE проблемы, лень искать.» Вот после этого высказывания весь ваш комментарий резко падает в цене.

Комментарии потихоньку начинают перевешивать саму статью. :) Всё-таки не соглашусь: JavaScript → jQuery (как пример библиотеки) ≠ ASM → C. Идея правильная, но аналогия грубовата. Все эти библиотеки не завоевали бы и сотой доли популярности если бы не «browsers’ incompatibilities». Переход ASM → C был обусловлен рядом дополнительных факторов.
Штудер says:

2008-11-21 at 07:51

Алекс, а ты насчет JSF ничего не путаешь?
Dmitry A. Soshnikov says:

2008-11-21 at 11:37
@Dmitry Baranovskiy:

JavaScript → jQuery (как пример библиотеки) ≠ ASM → C

Да при чем здесь это? Я когда провожу подобные аналогии, специально всегда помечаю, что примеры – утрированные и абстрактные. Здесь конкретика вообще не имеет значения, я могу этот пример и на кружочках с квадратиками описывать. Речь даже не о языках, а об абстракциях и об их усилении с каждой новой “версией”. Это более глобально, чем “JavaScript → jQuery”.

Переход ASM → C был обусловлен рядом дополнительных факторов.

Кроме идей упрощения и абстрагирования от “сложных” (или монотонных, или утомительных) операций, все “дополнительные факторы” имеют второстепенное значение. С ASM’ом специально привел привел, чтобы показать – когда люди рассуждают об этом:
```
mov dx, offset someString
mov ax, 09h
int 21h
```
они не говорят – “давайте поместим в регистр dx смещение переменной someString, затем в регистр ax значение 09h и вызовим 21-е прерывание”. Вместо этого они говорят – “блин, что-то меня задрало это повторять каждый раз, давайте абстрагируемся от технической реализации (не суть важно для задачи, что будет происходить внутри относительно вывода на экран) и будем называть это просто – “напечатать”. Для этого напишем функцию print(…) которая будет внутри делать кучу дополнительных проверок (читайте аналогию – обеспечивать “кроссбраузерность”), – да-а, она будет тормозить, но что делать? – и таким образом, мы сможем сконцентрироваться на созидательных творческих задачах, нежели постоянно делать эти проверки вручную.

И вот это постоянное упрощение, вызывающее уменьшение производительности на старом железе, и сглаживающее (восстанавливающее или опережающее) производительность на новом железе – создает прогресс.

Я замечу, что приводя ASM – я пишу уже очень большую абстракцию. До ASM’a есть HEX- и BIN-коды, а до них еще и программирование проводками.

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

Я всего рассуждал, что профи в текущей абстракции, всегда будет видеть недочеты и в последующих. Например, @ferrari пишет:

Антон, вы навешиваете эвент JS-а используя селектор по классу, хотя по всем правилам логики class используется для элементов, когда их >1. И $(’EL.classA’).click(..)

это человек уже хорошо разбирается (ну, допустим ) на самом деле, я не знаю, на сколько хорошо) в jQuery, и он, скорей всего, будет сетовать на библиотеку superNewJQuery (которая будет весить 7Гб), написанную на jQuery, и говорить о ее недочетах.

При этом новых языков это касается меньше (возможно, это Вас смутило с примером asm -> c) – там сознательно создают новые (часто несовместимые, но так же – упрощающие) конструкции, которые уже вряд ли можно сравнивать.

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

@Zeroglif:

На невежестве, на лени, на нехватке времени, на впечатлении, на коммерческих интересах…

Да, на невежестве – уж точно. А вот нехватка времени (я имею в виду глобальную, а не “а, блин, времени JS учить нет!”) может тоже служить прогрессом. Определяется цель; определяется, что, если использовать текущие инструменты, то не хватит времени дойти до глобальной цели; принимается решение – написать новый язык, который позволит писать быстрее (а возможно, объект, который будет писать за нас).

Насчет коммерческих интересов – тут тоже – есть идеологи, есть прагматики. Вторые потребляют и созидателями являются реже. Первые “фанаты идей”, но без коммерческой поддержки тоже загаснут. Проблемы начинаются тогда, когда вторые вступают в ярый спор с первыми, доказывая все прелести продукта, который они потребляют (при этом не являясь создателем этого продукта), приводя аргументами сенсорное потребление (aka – “нахрен мне это знать – мне надо быстрей срубить бабла, да побольше проектов новых”). При этом винить их за это тоже никто не может – это их право, почему нет? В общем, в этой позиции должно быть сочетание, иначе система загнется.

.ps: все это отстраненная философия, и к данной статье имеет мало отношения.

.ps[2]: это лишь мое видение.
cheke says:

2008-11-22 at 12:29
Скажите пожалуйста,
записи:
```
<link rel="stylesheet" href="/css/style.css" type="text/css" media="screen" charset="utf-8" />
```
и в самом style.css:
```
@charset "utf-8";
```
идентичны или же указание кодировки в html-файле более приоритетное?
Pingback: Интересное за неделю: верстка, верстка, верстка… и WordPress | Вебмастеру посвящается...
Alex says:

2008-11-24 at 21:35

Штудер. подскажи как генерить JSF без яваскрипта
(сорри за офф)
Anton Shevchuk says:

2008-11-25 at 08:44

@cheke:
По приоритетам:
– поле charset в элементе
– кодировка указанная в самом документе
– элементы кодировки языка в документе
Pingback: Weekly linkdump #153 - max - блог разработчиков
Штудер says:

2008-11-28 at 18:41

Алекс, извиняй в заблуждение ввел.
Я сам больше со стратсом и так кое чем по мелочи работаю, а jsf тока краем уха касался. Сегодня товарисча на работе поспрашивал, действительно большинство компонентов без js работать не будут.
Денис says:

2008-12-22 at 18:33

Может кто-нибудь обьяснить почему все так хвалятся jquery. Я всегда использовал dojo и у меня ни разу не возникало желания переключаться на что-то другое.
И их стандарты кодирования достойны восхищения:
Anton Shevchuk says:

2008-12-22 at 19:01

@Денис:
Это не “хвалятся” – если бы Вы писали подобную статью, то Вы бы приводили примеры с использованием dojo, jquery – это моё личное предпочтение как автора блога и переводчика приведенных статей…
Leonid Evstigneev says:

2009-06-06 at 18:05
```
1.
2.  window.onload = (function(){
3.    alert('Hello World');
4.  });
5.
```
```
1.$(document).ready(function()
2.{
3.    alert('Hello World');
4.});
```
Объясните, а чем собственно это отличается?
Вы что второй пример вне тега писать будете?
Вот уж воистину пропаганда любимого фреймворка. :)
1. Anton Shevchuk says:
  
  2009-06-06 at 18:49
  
  Не вижу причин придираться, написано ясно – не используете фреймворк – пишите первый вариант, используете – пишите второй…
2. Денис Чистяков says:
  
  2009-06-06 at 18:56
  
  Отличается, как минимум тем что в современных браузерах поддерживающих DOMContentLoader событие будет использоваться его наступление, т.е. не загрузка всех элементов, всех скриптов и всей графики, а только загрузка DOM дерева, которая и нужна JS-скриптам.
  Это как минимум в FF, Opera, Safari и в IE, только в последнем через костыли MS’а, кстати jQuery первый JS фреймворк который реализовал такую обработку ;)
  
  P.S. Странно почему столько людей придирается к использованию фреймворковв этой статье, не понимаю )
all87 says:

2010-06-16 at 11:31

Уже не первый раз приплыл на Ваш сайт. Получает заслуженное место в закладках =)

Спасибо!
ShuM says:

2011-02-04 at 14:33
Спасибо за всё, ресурс просто изобилует наиполезнейшей информацией!
Кстати нашёл опечатку, перепутал ты в торопях местами + и = в примере
Вот это место.
Лечим JavaScript зависимость
Давайте сделаем загрузка контента страницы посредством AJAX’а, но при этом оставим поддержку браузеров с отключенным JavaScripti’om, возьмем уже знакомый нам пример с меню сайта:
```
$(document).ready(function()
{
    // вешаем обработчик на все ссылки в нашем меню Navigation
    $("ul.Navigation a").click(function(){
        var url = $(this).attr("href"); // возьмем ссылку
            url =+ "?ajax=true";        // добавим к ней параметр ajax=true
        $("#MainContent").load(url);    // загружаем обновленное содержимое
        return false;                   // возвращаем false - дабы не сработал переход по ссылке
    });
});
```
Надо так url += “?ajax=true

Ещё раз спасибо за всё!
Andrey says:

2012-01-12 at 20:24

Антон, спасибо за материалы.
ссылка “Свойства CSS – display” в рубрике “Теги любят порядок” – устаревшая.
guest says:

2012-07-03 at 15:24

цитата:
4 пробела – это в 4-ре раза больше трафика чем один символ табуляции :)

аналогично, если писать цифру “4” вместо “4-ре”, экономим 3 байта!
LEGION says:

2012-12-11 at 21:18

К сожалению я не нашел стандартов для написания файлов стилей, лишь пожелания:

Еще и от гугла “пожелания”:
http://habrahabr.ru/post/143452/
Кстати, некоторые пункты противоречат этот статье. Вот и думай как же теперь кодить. :(

Comments are closed.