Pull to refresh

Comments 115

В своё время наткнулся на сайт одной веб-студии, у которой таблицы стилей были написаны изумительно. Сейчас уже адрес не назову, но возможно, кто-то тоже впечатлился. С тех пор стараюсь оформлять большие цсс именно в таком стиле. Вот для примера начало одной из таблиц:
/* Общая таблица стилей для всех страниц сайта.

********************************************************************************
Содержание:
   0 Общий внешний вид
      0.1 Оформление текста
   1 Заголовок и главное навигационное меню
      1.1 Заголовок
      1.2 Главное навигационное меню
   2 Основной контент
      2.1 Обрамление
      2.2 Рекламный заголовок
      2.3 Меню навигации кабинета
      2.4 Текстовой блок
         2.4.1 Текстовой блок для авторизированного пользователя
         2.4.2 Текстовой блок для авторизированного пользователя
         2.4.3 Таблицы, содержащие интерфейсы управления
   3 Футер
      3.1 Левый футер
      3.2 Правый футер
*******************************************************************************/




/* 0 Общий внешний вид
------------------------------------------------------------------------------*/
#wrapper{
   min-height: 100%;
   min-width: 980px;
   height:auto !important;
   height:100%
}
body{
   font-family: Helvetica, Tahoma, Arial, serif;
   font-size: 14px;
   height: 100%;
   line-height: 14px;
   margin: 0;
   padding: 0;
}
html{
   height: 100%;
}
table{
   width: 90%;
}
table tr.odd{
   background: #FAFAFA;
}



   /* 0.1 Оформление текста
   ---------------------------------------------------------------------------*/
   acronym, abbr{
      border-bottom: 1px dashed;
   	cursor: help;
   }
   a{
      color: #fe5800; /*orange*/
   }
   a:hover{
      text-decoration: none;
   }
   a.ext{
      background: url(../img/external_link.gif) no-repeat right top;
      padding-right: 16px;
   }
   img.fileIcon{
      height: 16px;
      vertical-align: -3px;
      width: 16px;
   }
   .attention{
      color: #fe5800; /*orange*/
      font-weight: bold;
   }
   .newMaterial{
      font-weight: bolder;
   }
   .nohypen{
      white-space: nowrap;
   }




/* 1 Заголовок и главное навигационное меню                                   */
   /* 1.1 Заголовок
   ---------------------------------------------------------------------------*/
   #header{
      background: url(../img/header_bckg.gif) repeat-x;
      height: 120px;
      line-height: 16px;
   }


Это пока рабочий вариант, но суть, я думаю понятна.
Очень необычное решение. Надо попробовать.
… главное побольше комментариев на «русском»
Я думаю, комментарии всегда следует оставлять на языке/сленге, который максимально понятен и однозначен для читающих. Конкретно этот код (как и весь проект) сейчас веду я и мой «помощник». Очень маловероятно, но, возможно, лет через *дцать кто-то решит всё переписать и полезет в код. Но не более.

Вообще я склоняюсь к использованию чистого английского для хоть сколько-нибудь значимого проекта, так как любой адекватный программист поймёт эти комменты. Пусть даже со словарём, но поймёт. К этому я пришёл после того, как-то однажды долго вникал в паскалёвый код менюшки с комментариями на финском, а в следующий раз разбирался в реализации какого-то математического алгоритма с комментами на итальянском )
Комменты на русском очень опасно оставлять, ещё свежи воспоминания, как IE6 и Safari перестают читать файл с кириллического символа…
Это же для разработки. А на сервере рабочий css в любом случае стоит ужимать. С отбрасыванием всех комментариев, естесственно.
А во время разработки тестировать в IE тоже приходится. И пока врубишься, что это из-за кириллицы… В общем, потенциальная проблема.
ну, я программирую, мне не сложно написать скритик, создающий рабочую версию css… для себя или верстальщика.
Вадим, это проблема кодировки.
utf-8 и можно смело использовать русский.
Гм, ну — безусловно. Но с проблемой смешивания кодировок сталкиваюсь на каждом шагу. Поэтому лучше быть осторожнее — я вообще не особо люблю общирную документацию в CSS, а короткие вещи можно писать латиницей.
Удобнее, ИМХО, во всех проектах использовать юникод. Во всяком случае проблемы это решает и новых не вызывает.
/**/ после каждого комментария решает проблему в MSIE. Ну и @charset, если очень хочется.

У нас в коде все комменты на русском.
Ага. То винда, то UTF… и у меня уже отрубались фрагменты кода в Safari, даже с /**/ после комментариев (
Если я правильно помню там было дело при чтении файла с диска и Сафари не мог понять в какой кодировке файл.
В любом случае — приятного мало.
В сюбом случае это не повод не использовать русские комментарии.
Если есть поля, где потенциально могут быть закопаны мины, такими полями лучше не ходить. Документация в файлах — вообще сомнительное дело, я кажется тут где-то уже говорил. А если нет документации, то пространные высказывания по-русски особо и не нужны.
После чтения маловразумительного кода с комментариями на голландском языке я принял для себя простое правило:
Комментарии должны быть только на английском.
да, классно, так и буду делать в новом проекте
Тоже использую схожий вариант, очень удобно когда понадобится через месяц чтото исправить, и желательно быстро.
И избыточность (как по размеру CSS, так и в логике) порядка 10%. Скажем, пояснять значения слов header, footer, sidebar — нет смысла, т.к. это повсеместное использование. Остальным элементам лучше давать говорящие, осмысленные названия. Ресеты всегда стоят вверху, дополнительные пользовательские стили — внизу. Плюс если использовать такую микроразметку, как hAtom или hReview не надо придумывать дополнительных названий — всегда есть стандартные.

CSS не настолько сложен, чтобы перегружать его комментариями наподобие талмудов прошлого века. Больше логики, больше семантики.
Практически полностью с вами согласен, но очень часто в больших (именно в больших) таблицах стилей можно легко потеряться. Содержание позволяет разбить таблицу на логические блоки, не разбивая её на десяток файлов.

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

Впрочем, универсального решения всё равно не существует, каждый волен выбирать наиболее удобное для него решение.
мне, например, будет одинаково сложно искать название класса и комментарий типа /* заголовок второго уровня для левой колонки */ в большом, но хорошо прокомментированном css-е. есть же firebug, который показывает, на какой строчке начинается определённое правило, да ещё и всю иерархию наследования через все css-файлы. уже кучу раз разбирался с чужимим стилями без проблем.
Проблема в больших таблицах не в том, чтобы понять, у какого элемента какое свойство во что установлена, а в том, чтобы было удобно найти его и исправить. Можно, конечно, применить «прогрессивное улучшение» и разбить одну большую таблицу на 2-3 поменьше, но дальше дробить уже не всегда разумно. А в неоформленную таблицу стилей порою бывает трудно «въехать». Натравите фаербаг вот на этот CSS, например, сильно ли он вам поможет её эффективно редактировать? )
а не надо натравливать на css. надо натравливать на страничку, где этот css используется. зашёл на lenta.ru — в фаербаге всё понятно.

я не против комментирования css-ов. я просто говорю, что лично мне эти комментарии не сильно помогут.
Я бы лучше сделал побольше комментариев, которые удалятся в рабочей версии, чем семантично называл все стили. И css, и html будут меньшего объема, и назначение стилей будет сохранено для будущей разработки
Семантичные названия стилей — не для красоты. И не всегда для экономии.

Это как «экономить» на названии по стандартам функций в Java, заодно снабжая все джавадоками и обильными комментариями. (пример не отражает, конечно, полезности нормальных названий классов и идентификаторов)
>Семантичные названия стилей — не для красоты. И не всегда для экономии.
как раз не для экономии =)

Вообще, семантичное название стилей хорошо только до определенной степени, согласитесь. Если названия «vote_plus», «vote_minus» — хороши, то названия «button_vote_for_comment» и «button_vote_againt_comment» — это уже перебор.

Конечно, не нужно комментировать вроде этого:
/* Классы для голосования за комментарий */
.vote_plus {
...
}
.vote_minus {
}


Но закомментировать блок кода, описывающий все стили комментария, было бы полезно. И, используя рекоммендации из первого коммента, можно это сделать хотя бы так:
/* 5.3. Comments */
.comment {
...
}
.comment .hcard {
...
}
.comment .hcard .vote_plus {
...
}
...


Так и семантика сохраняется, и стили не выглядят громоздко, и структура будет у css, и объем у css и html оптимальный

зы. Ессно, все мое имхо
Почему у меня такое чувство, что меня обосрали? =)
Да нет, я и не думал с вами делать чего-то эдакого. Просто комментарии в комментариях в вашем посте («/* 5.3. Comments */») напомнили мне и про эту игру понятий )
А, понял =) Коммент про коммент, в котором коммент… Да, смешно вышло =))
Наверное, нет, просто не понял смысла Вашего коммента =)
CSS пишется для браузера, а не для того, чтобы люди глазели и удивлялись, какой клевый код и как хорошо написано. Поэтому в жопу комменты и лайнбрейки, а по названию #header итак понятно, что это заголовок.
А все нормальные цсс-редакторы вообще выносят все классы и айдишники отдельно и сортируют их по алфавиту так, что можно легко обратиться к любому из них.
Это решение — всего лишь бред перфекциониста из-за отсутствия нормального инструментария
Всех верстальщиков можно поделить на две группы:

1. Сторонники компактности кода;
2. Сторонники читабельности кода.

Лично я не использую громоздкие комментарии. Достаточно написать /* комментарий */ любой нормальный редактор подсветит эту строку и её не сложно будет найти. Кроме того, если большой кусок кода специфичен только для какой-то одной (двух) страницы, то уместно вычленить его в отдельный файл и подключать по мере необходимости.
Я использую большие комментарии + разбиваю css на много файлов по модулям, пишу не всё в одну строку. Но при выводе на сайте все файлы слепляются и проходят оптимизатор. Так что бывают сторонники обеих групп :-)
Безусловно! Любая классификация всегда условна. Чётких границ нет.
Кроме того, если большой кусок кода специфичен только для какой-то одной (двух) страницы, то уместно вычленить его в отдельный файл и подключать по мере необходимости.

Палка о двух концах, однако. При таком последовательном разбиении можно получить пару десятков CSS файлов, и на каждую страницу будет включаться штук по 10-15. А это «лишние» обращения к серверу, и, как результат, замедление времени загрузки страницы.
Тут стоит уповать только на сообразительность))
Всегда надо искать компромисс :)
Со вторым пунктом не согласен. Считаю, что сортировка «по логике» более-удобна. Т.е. сначала margin, padding, потом шрифт, потом бэкграунд, например
Удобнее то, что умеешь. Ну или к чему привык. В любом случае выбор сортировки выбор каждого. Я с непривычки одинаково быстро нашёл маргин и там и там.
Группирую по смысу. Если есть left и top, они обязательно должны быть за position: absolute. Если есть width и height, они обязательно должны быть после display: block. z-index всегда в конце, потому что его очень часто приходится тюнинговать при сложной верстке.
Просто логика у каждого своя. Я, например, тоже по логике сортирую, но я бы по другому расставил свойства, нежели вы, а если с кодом работают несколько человек? Тут уже по ситуации надо смотреть, единого для всех решения нет.
Искусственно навязать один стандарт.
Тоже хотел написать об этом. По логики, и внутренняя группировка margin+padding ect. куда удобней алфавитной последовательности. Еще наблюдал в некоторых проектах как стили для одиних id или class'ов разбивали по логическим группам последовательно: вначале указывали правила «отступов» для всех элементов потом правила для шрифтов всех элементов и так далее мне данный подход не показался удобным но возможно он подойдет если код будет генерироваться неким редактором…
UFO just landed and posted this here
UFO just landed and posted this here
> Обязательно используете сброс настроек
И ведь найдутся идиоты, которые будут тупо следовать этому бреду.
зачем так категорично?
если называете это бредом — обоснуйте.
а так вы подвергаете сомнению психическое состояние некоторых уважаемых в сообществе верстальщиков, которые используют сброс настроек
> если называете это бредом — обоснуйте.
Вы видимо никогда контент-менеджеру не объясняли, почему cellpadding и cellspaccing не работают, а вложенные ul не дают отступ.

Вообще на эту тему много холиваров, если интересны аргументы обоих сторон — поищите, сдесь незачем это дублировать.

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

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

а ресеты помогают сделать так, чтобы в разных броузерах одни и те же элементы выглядили одинаково, а не удивляли контент-менеджера разным повидением в IE и FF (<-утрировано)
> а ресеты помогают сделать так, чтобы в разных броузерах одни
> и те же элементы выглядили одинаково
На словах это так. На деле, все ресеты которые я видел уничтожают первоначальный смысл html. Скажите, зачем сбрасывать отступы сверху и снизу у hX и p? Зачем убивать отступы слева у ul и li?
Так как я эти вопросы задавал уже не одному человеку, я знаю что вы ответите: «Но ведь потом их можно задать такие, которые нужно», поэтому я сразу задам следующий вопрос: А что, без ресетов нельзя сразу задать параметры, которые нужно?

Уж извините за реплику от вашего лица.
можно, но это менее универсально (задавать для каждого отдельно взятого то, что можно задать один раз для всех)
также бывают моменты, когда текст выводится БЕЗ форматирования, например
но это уже чуть дальше чем обычный ресет
Вы не следите за дискуссией. Речь не о том, можно ли сбросить значения для каждого элемента вместо одного ресета, а о том, зачем нужен ресет если после него все равно придется для каждого элемента нужные параметры выставлять.
читайте внимательнее

придётся не для каждого, а для некоего x элементов, которое всегда меньше общего кол-ва элементов

логика понятна?
UFO just landed and posted this here
Reset делают из-за того, что в разных браузерах разные значения по умолчанию. Никто не запрещает после сброса установить вашим ul нужный отступ.
Браво! Я вот только что написал кооментарий чуть выше ;)
Если верстальщик нормальный он это предусмотрит.
Достатосно дабовить на тестовую страницу основные элементы текста таблицу и форму
Ну т.е. ресет — это такое еще одно препятствие в работе, которое следует предусмотреть при верстке? А положительные моменты есть?
Главный плюс в том что я знаю что у всех элументов и у всех браузерах отступы 0
Это так сказать для тех кто любит все контролировать

Хотя после статьй пересмотрел вариант сейчас буду использовать список тегов.
Ок. Смотрите, вы можете любить или не любить CSS-ресеты. Можете считать что язык HTML создан для верстки сложных макетов, а можете считать что для удобного представления данных. Можете считать что нужно плювать на труд тех, кто будет наполнять сайт после вас информацией, а можете сделать чтобы им было максимально комфотрно.

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

после правильного наполнять информацией — одно удовольствие
Я вообще тогда — пример расточительности в написании кода :) Потому как часто предпочитаю вместо одного font использовать полный набор (font-size, font-weight), пишу каждый атрибут на новой строке, да еще и к тому же открывающую скобку { ставлю не сразу рядом с именем тэга или класса, а под ним. Плюс все отступами выровнять… И закомментировать… И тогда у меня получаются нечто вроде:

body
{
   font-family: Corbel, Arial, sans-serif;
   font-size: 1.2em;
   font-weight: normal;

   padding: 0;
   margin: 0;
}


Ну привык я так :) Вредная привычка, согласен. Но лично мне так почему-то удобнее… Можно потом оптимизатором прогнать и укукожить код, хотя толку от сэкономленных 5-6 килобайт?
ничего себе толку! для провинции со слабым ADSL на 6-килобайтном CSS, он грузится на десяток секунд позже, чем HTML (и не факт, что «один раз в первый раз» — если браузер взбрыкнет с кешем). Что уж говорить об экономии на нагрузках вообще.
Я в провинции со слабым ADSL. У меня всего-то 512 кбит. О мегабитах покуда мечтаю. Но никаких таких проблем не заметил. Все грузится абсолютно одинаково. Что с отступами и новыми строками, что без них. Может быть на обычных модемах каки-нибудь на скоростях 56 кбит и ниже и будет это заметно, но на ADSL точно нет разницы.
Подтверждаю: в провинции на 256 кбитах разметка и стили грузятся в целом столько же, сколько и в провинции на 3-4 метрах (проверяно на себе). На сегодняшний день стринички, большие 200 кб, утяжеляет уже мультимедиа-содержимое, нежели несколько дополнительных тегов или строк стилей (ссылку на статистику привести не смогу, но может быть вы помните этот топик примерно полугодичной давности).

Другое дело, что мобильный интернет в большенстве своём у нас далеко не 3G, а те же мобильные браузеры давятся большими страничками, не понимают многие теги XHTML, задумываются подольше над HTML, не обрабатывают некоторые селекторы CSS и правила (и тут Остапа понесло… :)

В общем я к тому, что ±5 кб сегодня актуально только для мобильных телефонов (не смартфонов).
про телефоны ничего сказать не могу — не пользуюсь. в редких случаях выхожу с айфона через EDGE, но там броузер Safari, он понимает все архичудесно. И страница грузится долго только из-за обилия картинок. Рендеринг HTML практически не зависит от количества пробелов, вставленных в CSS-разметку.
Про гласные и негласные косяки мобильных браузеров интересно и доходчиво рассказывала Наталия Макишвили (видео выступления). Если хотите, посмотрите, мне лично очень понравилось )
В Саратове Волга-Телеком дает лимит в 12Гб, после чего обрезает с 1024 до 64 — на этой скорости отдача большого CSS и HTML с не очень сильных серверов, заметна.

Распространенность широкополосного доступа — не может быть причиной для неразумности. Посмотрите как экономят гугл с яндексом — ну, при их нагрузке это понятно.

Еще доводы в пользу shorthands — сжатое и удобное представление CSS-атрибутов. Например, border:1px dashed #000; — куда удобней, чем три атрибута. А вот в случае, если надо переписать наследованное — то тогда можно использовать border-size. Аналогично и с пониманием margin:0 0 10px; и подобных — их, к тому же, удобнее изменять в процессе, меняя сразу значения атрибутов, а не дописывая-удаляя.

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

#head{
width:200px;
font-size:1.2em;
}
#head h1{font-size:140%}
Парсер скушал табуляцию. Перед #head h1{font-size:140%} быть должен отступ.
UFO just landed and posted this here
А ещё, чтобы CSS проходил валидацию, цвета надо назначать в отдельных правилах. Я так просто выношу в отдельный файл.
Не понятно, что вы имеете ввиду.
[полез проверять]

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

Ругается в том случае, если для элемента задать color, но не задать background-color (уровень предупреждений надо выставить по максимуму). Консорциум считает, что если мы предполагаем, что цвет фона наследуется от родительского элемента, надо так и написать: background-color: inherit.

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

h1
{
  color: red;
  background-color: inherit;
  font-weight: bold;
  font-size: 144%;
}

h2
{
  color: red;
  background-color: inherit;
  font-weight: bold;
  font-size: 120%;
}

h3
{
  color: red;
  background-color: inherit;
  font-weight: bold;
  font-size: 100%;
}


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

h1
{
  font-weight: bold;
  font-size: 144%;
}

h2
{
  font-weight: bold;
  font-size: 120%;
}

h3
{
  font-weight: bold;
  font-size: 100%;
}

h1,
h2,
h3
{
  color: red;
  background-color: inherit;
}


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

Но я уже привык. Да и так действительно удобнее вносить правки.
UFO just landed and posted this here
Я программист, я привык к другому — уровень предупреждений по максимуму и чтобы не было ни одного сообщения. Иначе чревато.
Этот ворнинг очень правильно на самом деле вылазит. Мы привыкли, что настройки у браузеров по дефолту одни и те же, но никто не мешает пользователю выставить, например, синий цвет фона для странички по умолчанию. Тогда заданный автором синий цвет текста будет смотреться не очень удачно. Однозначное же переопределение цвета текста и фона гарантирует, что подобного конфуза практически повториться не сможет. Если только пользователь не окажется совсем уж упёртым и не задаст !important.

Так что это полезный ворнинг, он не помогает не забывать о мелочах.
a,a:active,a:link,a:visited{color:#000;text-decoration:none}
a:hover{text-decoration:underline}
Заработался, окошком ошибся :)
Зачем же посещенную ссылку маскировать под не посещенную? ;-)
к примеру, дизайнерские заморочки
Ну обычно посещенная ссылка сильно не будет влиять на общий внешний вид, видимо, действительно заморочки =))
И пожалуйста не делайте следующего:

* { margin: 0; padding: 0; }

Этот прием увеличивает время загрузки страницы

Может быть все-таки не время загрузки, а время рендеринга?
Да, да — это классический материал
2. Алфавитный порядок

По-моему скромному мнению это ничего не улучшает.
Я считаю, что группировать надо по смыслу (семантике).
Это сложно описать словами, приведу пример (порядок строк имеет значение):

a:link,
a:visited	{ display: block; float: left; width: 100px;          // модель, флоаты, размеры
	 	  position: relative; top: 0; right: 12px;            // позиционирование
		  margin: 0; padding-right: 20px; border: none;       // отступы, бордеры
	 	  font: 1em/1.4em Arial, Helvetica, sans-serif;       // основной шортхенд для шрифта
		  text-transform: uppercase; color: #0cf;             // цвет и др.
	 	  background: url(../img/leave.gif) right no-repeat } // шортхенд для бекграунда


Теперь, если ваш редактор имеет вменяемую подсветку кода, найти любое свойство можно сходу.

4. Последовательность

Пример «каждое с новой строки», просто не имеет права на существование, слишком много придётся скролить, если проект сколько-нибудь большой. Пример «3 в ряд» — часто тоже (если у вас конечно не супер широкорматный монитор), часто будет перенос строки, что неэстетично и просто неудобно для сканирования текста.

Поэтому:

#list		{ margin: 0; padding: 0 40px 0 12px;
		  list-style-type: none; font-size: 1em }            // в последней строке можно группировать то, что насобиралось
#list li	{ margin: 0; padding: 6px 0;                         // пока правила помещаются в удобочитаемую по длине строку, никаких переносов не нужно
		  background: url(../img/dots.gif) repeat-x }        // а вот здесь уже без него никак
#list h4	{ margin: 0 }
Спасибо, хотел написать примерно тоже самое и привести пример:

position:absolute;
bottom:0;
top:0;
float:left;
border:none;


border:none;
bottom:0;
float:left;
position:absolute;
top:0;


…если я работаю со стилями, чаще всего я работаю не с одним правилом, а с несколькими, относящимися к одной смысловой группе. Т.е. если правлю позиционирование, мне важно, чтобы под рукой находились свойства top, right, bottom и left.

С этой точки зрения сортировка по алфавиту — это враг скорости.

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

приятно, что мне удалось в чём-то прийти к тому же, что и вы, Вадим :)
По-моему, это сродни спору «сколько кусочков сахара в чай класть». Кому как больше нравится, кто как привык, тот так и пишет.

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

Более того, когда разбираешься в забытом или незнакомом коде, как минимум пользуешься фаербагом, а он все стили представляет уже в едином формате, независимо от культуры написания.
вы не сможете из фаербага редактировать конечный css
а я хоть где-то сказал, что собираюсь это делать? разбор кода не подразумевает его редактирование, да и смысл моего высказывания вовсе не в этом.
UFO just landed and posted this here
— Например правило и тут же его хак для IE :)

хаки для ие выносим в файл для ие
Смотря куда нам CSS — в продакшн или людям на доработку. Соответственно в первом случае нужно сжимать(трафик нужно беречь, даже если он безлимитный, сэкономленные 3-4 килобайта умножаем на количество посетителей), во втором — желательно не скупиться на комментарии и группировать инструкции по функциям — сначала идёт общий сброс и шрифты, а потом по каждой области отдельно (хэдэр, контент, футер).
Я ещё предпочитаю чёткую структурированность селектора, навроде div#header div#logo img{...}, но это дело вкуса и мне видится как способ избежать неоднозначностей при случайном указании схожих ID или имен классов.
Вроде еще не от кого не прозвучало, но как по мне, так лучше всего сортировать по длине строк, то есть:
height: 18px;
width: 80px;
padding: 0 0 0 4px;
vertical-align: middle;
margin: 9px 10px 13px 0;
border: solid 1px #d4d0c8;
border-width: 0 1px 1px 0;
background: url(../img/bg-input.png) no-repeat 0 0;

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

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

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

И да, спешил набирал, и не правильно отсортировал первую строку.
UFO just landed and posted this here
Свои 5 копеек
CSS обычно пишу вот в таком стиле: pastie.org/400704, так в любом случае находить то что надо — легче. (позаимствовано из Sass)
Аттрибуты не сортирую, ибо смысла в этом довольно таки мало — больше времени на соритровку уходит, чем на поиск нужного свойства. Разве что basic elements и generic classes в алфавитном порядке выстраиваю, когда не лень.
Вы бы ещё нули писали без единиц измерения, ну и пробел после двоеточия — назвал бы братом по разуму )
Это dev-версия, тут всё время что-то меняется, потому и пишу 0px, а вот пробелы — да, грешен, часто так получается, когда спешишь. :)
Ничего не имею против '* { margin: 0; padding: 0; }' — задержка уверен абсолютно несущественная, а элементы форм всегда головная боль, так что всеравно придется мудохаться.

Второй пункт тоже спорный — тратить время на выстраивание строчек по алфавиту — по времени точно не окупится. Правил редко когда больше 10 и они зрительно отличаются, например описание background и margin трудно сразу не выцепить из общей кучи.

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

Четвертый не важен а вот 5 я не пробовал.

PS Конечно приятно смотреть на кодец который супер-пупер отформатирован но эти трудохатраты оправдываются далеко не всегда.
Ребят! Подскажите, а какой код нужен для списков ul li чтобы не стандартным маркером а маленькой картиночкой (квадратик красивый хочу) маркировался каждый пункт?
UFO just landed and posted this here
Мы в своё время где-то тоже вычитали и посчитали очень удобным делать так:

div.header {
    /* стили header'а */
    }
    div.header p {
    /* стили для p внутри header'а */
        }
    div.header ul {
        }
        div.header ul li {
            }

т.е отбивать вложенность пробелами на подобии языка yaml. Оказалось очень удобно!
Да, да! Статейка была на alistapart про 30 способов улучшить свой CSS, это и была одна из рекомендаций.
Очень удобно — сразу видно что/где и внутри чего.

p.s. дело вкуса, а я предпочитаю группировать так:

/* Header
----------------------------*/
#header {} /* даже если нет стилей, все равно указываю для соблюдения "каскадности"  */
  #header p {
  /* стили для p внутри header'а */
  }
    #header ul {
    }
      #header ul li {
      }

/* Content
----------------------------*/

div#content{
  /* стили content'а */
}
  div#content p {
    /* стили для p внутри header'а */
  }
  div#content ul {
  }
    div#content ul li {
    }

/* Typographic
----------------------------*/


Даже если определние блока пустое я все равно его пишу для «каскадности».
Про пустышки вы, кстати, правы, думаю тоже возьму на заметку!
Sign up to leave a comment.

Articles