Спорные правила простой верстки

Эта статья, является в первую очередь ответом на недавно вышедшую статью: «Простые правила простой вёрстки».
Автор пригласил написать ответ, высказать свой взгляд на эти примеры и рекомендации, этим приглашением ниже я и намерен воспользоваться. (Читать оригинальную статью перед тем, как зайти под кат — обязательно!)

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

Ну и без лишнего промедления сразу приступим:

Вещи очевидные, но статьи, собирающей их воедино я не нашел.

Немой вопрос застыл на кончике пера: А искал ли автор? Уверен нет, тем более большинство техник, рекомендуемых в статье очень спорны, и не раз вызывали массу дискуссий, уже поэтому они не имеют право называться «исправлениями ошибок».

Что же касается самих рекомендаций:

<!-- news -->
<div class="news">
    <div class="item">
        <span class="date">16.07.12</span>
        <a href="#" title="" class="title"><strong>Создание продающих сайтов</strong></a>

        <p>Текст новости</p>
    </div>

    <div class="item">
        <span class="date">16.07.12</span>
        <a href="#" title="" class="title">Создание продающих сайтов</a>

        <p>Текст новости</p>
    </div>

    <div class="item">
        <span class="date">16.07.12</span>
        <a href="#" title="" class="title">Создание продающих сайтов</a>

        <p>Текст новости</p>
    </div>

Блок новостей, не знаю, как вы, но я не вижу здесь ничего… стандартная разметка страницы… от какого излишества автор пытался уйти, я так и не понял, похоже к этому примеру в стиле «После» очень не хватает примера «До».
Но, есть тут и плохой стиль:

Обратите внимание на универсальный класс item. Каждый волен обзывать его по разному, скажем box, это не принципиально, мне item кажется абсолютно нейтральным и понятным по смыслу всем, кому предстоит работать с кодом в дальнейшем — это просто блок из списка других таких же, как он.

Подобная универсальность очень плохая рекомендация, именно потому, что этот класс ничего не говорит о том, что же он за сущность, для чего используется, и как результат, в итоговом проекте может появиться намного больше одного таких item-ов, что очень усложнит сопровождение проекта, я уже не говорю, о том, что будет, если несколько таких, ничем не связанных классов, встретятся в одном пространстве имен.
Рекомендация:Прочтите книгу Стива МакКоннелла «Идеальный Код», там кроме этого совета вы найдете еще массу интересных наблюдений, идей, удачных практик и т.п.

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

Тут очень посредственно, я бы не назвал это вообще советом, техникой и чем либо другим, на мой личный взгляд, это действительно, именно «избыточно», возможно гораздо выгодней сразу после закрывающего блока оставить комментарий, с информацией о том, какой именно блок мы только что закрыли, не более:

</div><!-- /news -->

… проставляйте табиндексы и нумеруйте или давайте понятные имена элементам формы.

Не нумеруйте, давайте понятные имена, об этом я уже писал.

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

Хорошим тоном? Вот честно, ничего подобного не слышал, если я не прав, исправьте, но мы ведь имеем дело со стандартизированным языком? И как по мне нет ничего плохого в том, чтобы придерживаться стандарта и все каскадные таблицы и подключаемые скрипты описывать в шапке документа, в специально отведенном для этого селектора «head», или новые стандарты уже предусматривают селектор «footer»?

Логика кода — общие рекомендации

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

• Имена основных папок корня проекта и названий страниц должны быть стандартизированы.

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

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

Немного о CSS

Не мне учить кого-либо, как ему оформлять таблицу стилей, я лишь покажу известный способ, который относительно редко используется, зато повышает читаемость CSS до запредельных высок и избавляет от необходимости использования заклинания Ctrl+F.

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

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

Но лично я не вижу сложностей в Ctrl+F по имени класса(идентификатора), по крайней мере это проще чем искать в строке по имени свойства, или тем более по значению.

Автор: DWSVad