Comments 203
В общем, это и так всё понятно.
Прммечания:
* Пункты 3 и 4 конфликтуют меду собой.
* Пункт 6 — короткий потому не пишут, что неизвестно, насколько длинным он станет. Правильнее было бы сказать: превратите записи в короткие в конце разарботки.
*… Что-то ничего не сказано про отношение к хакам.
Прммечания:
* Пункты 3 и 4 конфликтуют меду собой.
* Пункт 6 — короткий потому не пишут, что неизвестно, насколько длинным он станет. Правильнее было бы сказать: превратите записи в короткие в конце разарботки.
*… Что-то ничего не сказано про отношение к хакам.
* Пункты 3 и 4 не конфликтуют :) Логические блоки делаем для всего файла, а по алфавиту выравниваем только свойства. Глупо было бы выравнивать весь файл по алфавиту :)
* Обычно у меня сразу есть представление будет ли блок длинный. Ну можно и в конце приводить в порядок короткие блоки.
* Про хаки даже не знаю, что сказать… Хаки они такие хаки (:
* Обычно у меня сразу есть представление будет ли блок длинный. Ну можно и в конце приводить в порядок короткие блоки.
* Про хаки даже не знаю, что сказать… Хаки они такие хаки (:
Отношение к хакам описано в п.1 — с хаками ваш код никогда не будет абсолютно валидным. Видимо предлагается от них отказаться, основываясь на фразе в п.8 — «IE6 официально умер».
Для IE6 можно подключать отдельный файл, в котором переопределять стили, не используя хаки… Код будет валиден)
в каком это месте код для ие6 будет валиден? х)))
Я имел ввиду, что основной css файл будет валиден, т.к не будет содержать хаков…
Файл для ИЕ6 валиден не будет. К примеру, если хотя бы раз используется какой-либо фильтр, то вся валидность к чертям ))
Файл для ИЕ6 валиден не будет. К примеру, если хотя бы раз используется какой-либо фильтр, то вся валидность к чертям ))
ну и толку? х) какой прок от такой половинчатой валидности?
С одной стороны толка то нет, конечный файл для IE будет не валид, но…
Если отдать css-валидатору целую страницу c отдельными стилями для IE, подключенными через conditional comments, то валидатор такие файлы учитывать не станет и покажет (если в основном файле ошибок нет), что css валиден. Поэтому я считаю, что предпочтительней использовать такой вариант, чем хаки.
Если отдать css-валидатору целую страницу c отдельными стилями для IE, подключенными через conditional comments, то валидатор такие файлы учитывать не станет и покажет (если в основном файле ошибок нет), что css валиден. Поэтому я считаю, что предпочтительней использовать такой вариант, чем хаки.
а вы валидацию для чего используете? для успокоения совести только? х)
))) нет, конечно.
ну и для чего же ещё?
Для проверки ошибок, если такие есть
Для того, чтобы убедиться что css соответствует написанным требованиям w3c
Для того, чтобы убедиться что css соответствует написанным требованиям w3c
1. а ие можно и с ошибками скармливать? х)
2. и чо? вам шашечки или ехать?
2. и чо? вам шашечки или ехать?
)))) насчет 2 я если честно не понял вас)
насчет 1, я говорил выше что все чем файл ie_fix не валиден — это обычно фильтры. Для ИЕ это не ошибка, поэтому нельзя говорить о том, что мы скармливаем ИЕ ошибочный файл
А вы сами я так понимаю не сторонник валидности? То есть по вашему получается, что если в общем css файле встречается что типа
+html .foo{} или * html .foo{}
_свойство: значение или
//свойство: значение и т.д
то это вполне нормально и все зашибон?)))
насчет 1, я говорил выше что все чем файл ie_fix не валиден — это обычно фильтры. Для ИЕ это не ошибка, поэтому нельзя говорить о том, что мы скармливаем ИЕ ошибочный файл
А вы сами я так понимаю не сторонник валидности? То есть по вашему получается, что если в общем css файле встречается что типа
+html .foo{} или * html .foo{}
_свойство: значение или
//свойство: значение и т.д
то это вполне нормально и все зашибон?)))
2. валидность ради валидности — это как плацебо
1. точно также _свойство — тоже не ошибочно для ие
да, я не имею ничего против таких хаков в текущих условиях
1. точно также _свойство — тоже не ошибочно для ие
да, я не имею ничего против таких хаков в текущих условиях
не ошибочно для ие, зато для всех других браузеров это ошибка.
Вот поэтому и надо выносить такие вещи в отдельные файлы
Вот поэтому и надо выносить такие вещи в отдельные файлы
Любой код, не соответствующий спецификации (невалидный) потенциально может поломать парсер — и регулярно ломает, то Webkit, то IE…
Особенности потенциальных проблем состоят в том, что они случаются в самый неподходящий момент.
Можно конечно валидно фильтровать для IE, но держать стрёмный код во внешнем файле, а нестрёмный в основном — это писать хаки в двух разных местах.
Особенности потенциальных проблем состоят в том, что они случаются в самый неподходящий момент.
Можно конечно валидно фильтровать для IE, но держать стрёмный код во внешнем файле, а нестрёмный в основном — это писать хаки в двух разных местах.
UFO just landed and posted this here
Ошибки надо в редакторе проверять, а не в собранных файлах.
что значит «в конце»? 0_0" типа я сделал, а после меня хоть потоп? тада обфускатор ещё натравить не забудьте…
> *… Что-то ничего не сказано про отношение к хакам.
"… Я не видел толпы страшней,
Чем толпа цвета хаки.
был бы черным да пусть хоть самим чертом
но кто-то главный кто вечно рвет в атаку
приказал наступать на лето и втоптал меня в хаки..."
© Наутилус
"… Я не видел толпы страшней,
Чем толпа цвета хаки.
был бы черным да пусть хоть самим чертом
но кто-то главный кто вечно рвет в атаку
приказал наступать на лето и втоптал меня в хаки..."
© Наутилус
Многим из написанного пользуюсь, интересно было прочитать про Вашу иерархию (п. 5), я использую такую (отделяю строкой):
header {}
header h_left {}
header h_left a {}
header h_right {}
…
Пункт 4 тоже интересен… как-то не задумывался над этим, все время писал в порядке логики следования блоков.
Спасибо за советы
header {}
header h_left {}
header h_left a {}
header h_right {}
…
Пункт 4 тоже интересен… как-то не задумывался над этим, все время писал в порядке логики следования блоков.
Спасибо за советы
>Упростим как чтение, так и размер файла стилей.
Ну, чтение мне это не шибко (безумно?:) ) усложняет/упрощает. А вот размер файла стилей из-за отэнтровок и пробелов увеличится только для исходника. Но вы ведь не собираетесь его использовать вместо сжатого варианта?
Ну, чтение мне это не шибко (безумно?:) ) усложняет/упрощает. А вот размер файла стилей из-за отэнтровок и пробелов увеличится только для исходника. Но вы ведь не собираетесь его использовать вместо сжатого варианта?
используйте sass, и в конце получите няшный css.
Спасибо, но ручками оно как-то приятней сразу писать правильно :)
И там и там надо написать ручками, просто sass ускоряет написание. ну и на выходе красивый форматированный css получается, который так или иначе потом надо сжимать
или lesscss, тоже весьма удобно
Тут я полностью согласен. Теперь приложения на rails без haml+sass кажутся мне какими-то не современными что ли. Sass — это настоящий дзен.
Спасибо за карму, перенёс в соответствующий блог.
Ваша картинка противоречит вашим словам, а именно п.4.
Собственно, самая полезная ссылка оттуда:
vitaly.harisov.name/article/independent-blocks.html
vitaly.harisov.name/article/independent-blocks.html
статья кстати на 5+
Перестал пользоваться вложенностью типа:
.header h2 a
вместо нее всегда использую
.header_h2_a
пусть чуть длиннее но это делает CSS гибче многократно.
Главное что запомнил из статьи:
Не используем id в CSS, только class
Каждому элементу с измененными css свойствами свой класс. Это он сегодня в этом месте и один. А завтра может потребоваться перенести его в другое место и сделать их много
Перестал пользоваться вложенностью типа:
.header h2 a
вместо нее всегда использую
.header_h2_a
пусть чуть длиннее но это делает CSS гибче многократно.
Главное что запомнил из статьи:
Не используем id в CSS, только class
Каждому элементу с измененными css свойствами свой класс. Это он сегодня в этом месте и один. А завтра может потребоваться перенести его в другое место и сделать их много
Еще оттуда же — при необходимости код дублируруется, а не объединяется.
Развитие темы тут clubs.ya.ru/yacf/
Развитие темы тут clubs.ya.ru/yacf/
UFO just landed and posted this here
По пункту 4 более приемлемо выглядит сортировка не по алфавиту а по «близости» свойств.
Например:
1. Позиционирование (position, top, right, bottom, left);
2. Поведение (float, cleat ect.);
3. Размеры (width, height, padding, margin etc.);
4. Оформление (background etc.);
5. Свойства текста и шрифта;
6. z-index — меняется часто, в конце списка удобнее менять его.
Например:
1. Позиционирование (position, top, right, bottom, left);
2. Поведение (float, cleat ect.);
3. Размеры (width, height, padding, margin etc.);
4. Оформление (background etc.);
5. Свойства текста и шрифта;
6. z-index — меняется часто, в конце списка удобнее менять его.
UFO just landed and posted this here
О еще одном варианте сортировки свойств можно почитать у Виталия Харисова vitaly.harisov.name/css-code-style.html
Еще обычно всегда по порядку пишу сами свойства.
Начинаю всегда с ширины и высоты, потом фон, отступы, настройки шрифта, float, display. Примерно так.
Начинаю всегда с ширины и высоты, потом фон, отступы, настройки шрифта, float, display. Примерно так.
мне не нравится использовать _ в именах классов, приятнее смотрится -, т.е. h-block, вместо h_block
ребят =) пишите css так, как вам удобней, хоть под каждую страницу отдельный файл заводите. Просто на выходе, как вариант при экспорте на продакшен, напишите хук для SVN или чем вы поддерживаете код, который скомпилит все ваши бредни в один css, сожмёт его и закеширует. И будет счастье всем =)
Честно говоря, довольно опрометчиво называть довольно субъективные личные предпочтения правилами хорошего тона.
Вообще сложно давать универсальные советы CSS :). Например, у нас используется пакетирование CSS и JS и у меня кучу разных CSS-файлов вместо отделения пробелами и комментариями (все файлы потом объединяются в один и удаляются пробелы). Тем более мы используем SASS — очень удобно, особенно для CSS3-свойств.
Универсальный совет в том, что если вы начали придерживаться какого-то стиля кода, придерживайтесь его до конца. Процитирую уже упоминаемого Виталия Харисова «Код должен быть написан одинаково, даже если вы пишете его утром, вечером, сегодня или два месяца назад. На хорошем проекте, на плохом проекте, с больной головой или вообще без головы. С точностью до буквы, с точностью до пробела.»
я например пользую lesscss и css структурую по блокам
#sidebar{
.class{
.class{}
}
интересно было бы обсудить другой вопрос — разбиваете ли вы css на отдельные файлы как иногда советуют, типа form.css, typography.css и тд.? я нет
#sidebar{
.class{
.class{}
}
интересно было бы обсудить другой вопрос — разбиваете ли вы css на отдельные файлы как иногда советуют, типа form.css, typography.css и тд.? я нет
Я разбиваю для компонентов на отдельные файлы:
1. Быстрее искать нужный кусок
2. Иллюзия ускорения, если нет компонента на странице, то и CSS под него не грузится
Кстати, кто-нибудь использует JQueryдля CSS?
Ну например, хотите в таблице сделать четные строки другим стилем (предполагается, что таблица приходит без дополнительных классов в строках и ячейках).
Средствами CSS браузеры это не поддерживают. А вот JQuery — удобно.
Кто-то скажет, а у кого отключен Javascript? Ну и к черту его, получит менее красивую страницу, но информацию-то прочтет, а с дизайном он себя сам наказал. Вы же не застрахуетесь от тех, кто отключает картинки.
1. Быстрее искать нужный кусок
2. Иллюзия ускорения, если нет компонента на странице, то и CSS под него не грузится
Кстати, кто-нибудь использует JQueryдля CSS?
Ну например, хотите в таблице сделать четные строки другим стилем (предполагается, что таблица приходит без дополнительных классов в строках и ячейках).
Средствами CSS браузеры это не поддерживают. А вот JQuery — удобно.
Кто-то скажет, а у кого отключен Javascript? Ну и к черту его, получит менее красивую страницу, но информацию-то прочтет, а с дизайном он себя сам наказал. Вы же не застрахуетесь от тех, кто отключает картинки.
Lesscss ужасен тем, что конструкцию:
div, table {font-weight:bold;}
он любезно зачем-то распишет на две:
div {font-weight:bold;}
table {font-weight:bold;}
Если бы не эта «плюшка» я бы с удовольствием использовал его.
div, table {font-weight:bold;}
он любезно зачем-то распишет на две:
div {font-weight:bold;}
table {font-weight:bold;}
Если бы не эта «плюшка» я бы с удовольствием использовал его.
UFO just landed and posted this here
Размер здесь не важен: все равно пропускать через роботов, чтобы вырезали комментарии / сортировали свойства (и селекторы?) / жали код.
reset css тормозит рендеринг страницы, не надо его использовать. Об этом очень много уже было написано.
Если не трудно, дайте ссылку, пожалуйста.
а что вы предлагаете вместо этого использовать? под каждый браузер писать хаки?
я раньше был противником reset — мол смысл всё сбросить, если заново ставить потом? давайте уж сразу всё всё выставим просто и всё.
потом добавляя всё больше и больше элементов, начал выносить повторяющиеся свойства в отдельную первую строку…
и, да, вы поняли что это мне напомнило, reset.css, он самый, выходит это просто оптимизация чтобы не писать margin: 0; padding: 0; и т.п. в куче блоков объявлений.
разве задание для каждого элемента в отдельности будет быстрей?
потом добавляя всё больше и больше элементов, начал выносить повторяющиеся свойства в отдельную первую строку…
и, да, вы поняли что это мне напомнило, reset.css, он самый, выходит это просто оптимизация чтобы не писать margin: 0; padding: 0; и т.п. в куче блоков объявлений.
разве задание для каждого элемента в отдельности будет быстрей?
Посмотрите статьи на эту тему, к чему пересказывать?
Говоря «а», говорите и «б». Если уж Вы заявляете во всеуслышание, что есть варианты лучше, потрудитесь привести примеры, чем посылать половину населения хабра в гугл за поиском того, чего возможно и нет.
бегло глянул, нашёл пост от Харисова.
но 5-7%, это миллисекунды, даже такой поборник скорости как Мациевский не считает это поводом отказываться от reset.
но 5-7%, это миллисекунды, даже такой поборник скорости как Мациевский не считает это поводом отказываться от reset.
habrahabr.ru/blogs/css/86770/?reply_to=2618008#comment_2618156
Все активно возмущаются, что браузеры жрут память и тормозят. Думаю, что не последнюю роль тут играет, как мы пишем страницы.
Все активно возмущаются, что браузеры жрут память и тормозят. Думаю, что не последнюю роль тут играет, как мы пишем страницы.
Что-то я не осилил найти где Коля не считает это поводом. Можно ссылку или какие-то ключевые слова?
не так уж и тормозит, чтобы от него отказываться.
5-7%. Мне этого достаточно.
в _абсолютных_ единицах это фигня
Смотря на каких страницах и на каких девайсах.
конечно, теоретически на каком-то тормозном девайсе, кому-то приспичит посмотреть тяжеленную страницу и он ну никак не потерпит лишних миллисекунд… а практически? яваскрипты тормозят куда больше рендеринга… например try-catch каждую миллисекунду в процессе загрузки страницы.
это в jquery…
В динамических web-приложениях рендеринг тормозит куда больше, чем скрипт. Скорость перерисовки страницы напрямую зависит от того, как написан CSS.
ну приведи примеры чтоли.
вот я.карты у меня жудко тормозят при изменении зума. скажешь из-за стилей?
вот я.карты у меня жудко тормозят при изменении зума. скажешь из-за стилей?
Моё исследование оптимизации CSS началось с того, что страница списка писем Нео Я.Почты рисовалась в MSIE6 около 2 секунд. После переписывания селекторов и отказа от фоновых картинок получили 200 ms (разница на прядок). В остальных браузерах время уменьшилось в 2-5 раз.
есть замеры сколько дала каждая оптимизация по отдельности?
Нет, я не делал. Больше всего выигрыш в MSIE дал отказ от фоновых картинок и использование img вместо них. Но это в MSIE. В остальных браузерах background не тормозит и там своё дали селекторы.
чтд. оптимизировать надо то что тормозит, а то что и так летает — оптимизировать бесполезно.
Никаких чтд тут нет. Надо искать оптимальные способы вёрстки и применять их.
reset не входит в хорошие техники, польза при вёрстке от него сильно преувеличена, нет никаких проблем верстать с локальным ресетом, к тому же, достаточно часто после ресета элементу задаётся обратно margin/padding.
Применять разные метоы вёрстки для «простых» страниц и для «сложных» чревато тем, что когда простая страница вырастает в сложную (или весь проект вырастает) делать рефакторинг по переписыванию бывает очень и очень дорого. Мы, конечно, Почту переписали, но это не один месяц.
reset не входит в хорошие техники, польза при вёрстке от него сильно преувеличена, нет никаких проблем верстать с локальным ресетом, к тому же, достаточно часто после ресета элементу задаётся обратно margin/padding.
Применять разные метоы вёрстки для «простых» страниц и для «сложных» чревато тем, что когда простая страница вырастает в сложную (или весь проект вырастает) делать рефакторинг по переписыванию бывает очень и очень дорого. Мы, конечно, Почту переписали, но это не один месяц.
оптимальные — не значит, что нужно жертвовать удобством разработки ради микрооптимизаций.
да-да, только вот этот локальный ресет нужно безконца копипастить, вместо того, чтобы написать один глобальный и не заморачиваться более.
даже на «больших» проектах экономия на спичках — безтолковое занятие. а на почте лучше бы поиск ускорили… или хотябы сделали его гетом…
да-да, только вот этот локальный ресет нужно безконца копипастить, вместо того, чтобы написать один глобальный и не заморачиваться более.
даже на «больших» проектах экономия на спичках — безтолковое занятие. а на почте лучше бы поиск ускорили… или хотябы сделали его гетом…
1. А при верстке вы не разделяете блоки на типы (слой, независимый, глобальный)?
2. Используете заготовки вида «mar10px20px {margin: 10px 20px;}» ??
3. У вас один css на весть сайт или подключается кусками когда нужно? Как?
4. Используете оптимизацию, сжатие? Что именно?
2. Используете заготовки вида «mar10px20px {margin: 10px 20px;}» ??
3. У вас один css на весть сайт или подключается кусками когда нужно? Как?
4. Используете оптимизацию, сжатие? Что именно?
а главное не забудте все это дело обработать обфускатором — чтобы совсем хорошо было )))
дроблю CSS на блоки таким образом
вначале идут общие свойства для всех элементов,
*,body,html… {}
a{}
p{}
span{}…
потом начиная с шапки сайта группирую по корневым элементам, отделяя их между собой пробелами
все свойства пишутся в строчку, между собой разделены табуляцией и выровнены в столбик.
так же стараюсь писать свойства в одном и том же порядке следования для каждого элемента.
допустим если в .content font-style был первым, то и в .content h1 он тоже будет первым
пример
.content {}
.header{}
.header h1 {}
.header p {}
.bodys {}
.bodys #left{}
.bodys #left h1 {}
…
По началу тоже писал свойства длинным написанием. таблицы стали разрастаться до невероятных размеров.
по мне так гораздо проще найти 1 свойство на 1 странице но в строчку, чем искать его на 3, но в столбик.
вначале идут общие свойства для всех элементов,
*,body,html… {}
a{}
p{}
span{}…
потом начиная с шапки сайта группирую по корневым элементам, отделяя их между собой пробелами
все свойства пишутся в строчку, между собой разделены табуляцией и выровнены в столбик.
так же стараюсь писать свойства в одном и том же порядке следования для каждого элемента.
допустим если в .content font-style был первым, то и в .content h1 он тоже будет первым
пример
.content {}
.header{}
.header h1 {}
.header p {}
.bodys {}
.bodys #left{}
.bodys #left h1 {}
…
По началу тоже писал свойства длинным написанием. таблицы стали разрастаться до невероятных размеров.
по мне так гораздо проще найти 1 свойство на 1 странице но в строчку, чем искать его на 3, но в столбик.
тут приходит оптимизатор и лишние килобайты красоты уходят в небытие
Из серии: почему мне нравятся блондинки ;)
Лет 8 назад попику цены не было бы…
Лет 8 назад попику цены не было бы…
много спорного, часть правил противоречит друг другу)) выше уже хорошо откомментили,
и мало полезной инфы, чтоб тянуть на громкое название топика.
вот только валидатор неидеален.
какие будут предложения по поводу исправления ошибок такого типа?
не использовать эти свойства, несмотря на то что стандарт как раз одобряет?
и мало полезной инфы, чтоб тянуть на громкое название топика.
1. Всё должно быть абсолютно валидным. Я стараюсь избежать даже warning’ов.
вот только валидатор неидеален.
какие будут предложения по поводу исправления ошибок такого типа?
Value Error : display -moz-inline-box is not a display value : -moz-inline-box -moz-inline-box Property -moz-opacity doesn't exist : 0.5 0.5 Property -ms-filter doesn't exist : "progid:DXImageTransform.Microsoft.Alpha(opacity=50)" "progid:DXImageTransform.Microsoft.Alpha(opacity=50)" Property -webkit-border-bottom-right-radius doesn't exist : 12px 12px Sorry, the at-rule @-moz-document is not implemented. ...
не использовать эти свойства, несмотря на то что стандарт как раз одобряет?
А я использовал border-radius. FireFox наругался на запись для реального CSS3, а свою и вебкитовскую разрешил…
Mozilla используют 0,1—0,15 % пользователей. С учётом того, что процент почему-то начал расти только в последние пару лет (хотя и с чего бы, скорее другие браузеры некорректно идентифицируются), у всех новых пользователей вряд ли версия ниже 1.7. Соответственно, пользователей с версией 1.6 и ниже, по самым оптимистичным оценкам, 0,05 % (5 из 10 000), хотя лично мне кажется, что существенно меньше.
У меня только один вопрос — зачем вам -moz-opacity?
У меня только один вопрос — зачем вам -moz-opacity?
это свойства для Firefox
-moz-opacity — это прозрачность.
— Кэп
-moz-opacity — это прозрачность.
— Кэп
они нужны для древних версий мозиллы, которыми уже никто не пользуется…
Ок, предположим, что я идиот, раз мой комментарий минусуют, а ответы на него подписывают как «Кэп».
Тогда ответьте на вопрос идиота: Mozilla 1.7b+ и Firefox 0.9+ поддерживают opacity без префикса. Я полагаю, что вы верстаете кроссбраузерно, а значит opacity не можете не использовать (для тех же WebKit и Presto). А раз уже указано свойство opacity, то Mozilla 1.7+ и Firefox его поймут.
Зачем вы используете -moz-opacity, если не для Mozilla версии ниже 1.7?
Тогда ответьте на вопрос идиота: Mozilla 1.7b+ и Firefox 0.9+ поддерживают opacity без префикса. Я полагаю, что вы верстаете кроссбраузерно, а значит opacity не можете не использовать (для тех же WebKit и Presto). А раз уже указано свойство opacity, то Mozilla 1.7+ и Firefox его поймут.
Зачем вы используете -moz-opacity, если не для Mozilla версии ниже 1.7?
Шапка, подвал. Почему браузер мы называем этим словом (хотя он обозреватель по сути), но никак не можем отбросить эти дуратские шапка и подвал, заменив их на хидер и футер. Для своих же коммен6тарии пишем, а не для нубов.
Сортитровать ксс по алфовиту. Не думаю, что это самая лучшая мысль. имхо, лучше группировать однотипные свойтва рядом. Например font-family рядом с text-align. Можно дажы типы свойств отделять абзацем:
font-size: 12px;
text-shadow: 1px 0 #000;
margin: 10px 5px 5px 8px;
padding-left:30px;
background:#orange;
ИЕ6 официально умер. Аха, скажите это заказчикам, у которых на компьютере он стоит.
В остальном согласен, годные советы.
Сортитровать ксс по алфовиту. Не думаю, что это самая лучшая мысль. имхо, лучше группировать однотипные свойтва рядом. Например font-family рядом с text-align. Можно дажы типы свойств отделять абзацем:
font-size: 12px;
text-shadow: 1px 0 #000;
margin: 10px 5px 5px 8px;
padding-left:30px;
background:#orange;
ИЕ6 официально умер. Аха, скажите это заказчикам, у которых на компьютере он стоит.
В остальном согласен, годные советы.
head [hed] не [hid]
конечно же, в нашем русском наречии мы округляем непонятные звуки до набиолее близких, иначе б говорили не браузер, а что то в районе «Брузэ»
то есть «Браузэ».
На как как вы предлагаете хидер звать? Хедером?) Или две «и» писать в слове?
На как как вы предлагаете хидер звать? Хедером?) Или две «и» писать в слове?
Неверно. Вы же не скажите про зайца (hear), что он — хир!
И да, браузер (browser) звучит именно как браузер</>
И да, браузер (browser) звучит именно как браузер</>
ежедневные 15-30 минут аудирования в течение пары-тройки месяцев могут помочь избавиться от «хидеров», «алчеми», «брузэ» и т.д.
2. Старайтесь комментировать как можно больше.
я даже создал сниппет для textmate, что-то вроде:
<div${1: ${2:class}="${3:name}"}>
$0
${4: }
Пишем div, нажимаем tab, получаем заготовку вида:
При этом слово class выделено. Можно сразу написать id, если есть такая необходимость, либо сразу нажать tab еще раз. Выделенным станет name, и по мере его редактирования будет автоматически редактироваться name в комментарии в конце. После этого опять tab, и выделяется целиком комментарий в конце. В этот момент его можно удалить одним нажатием на del, либо еще раз tab и оказаться внутри блока.
В итоге имеем:
в 14 нажатий клавиш, вместо ~60 =) Да еще и с гламурным комментом в конце, с которым обращаться при большой вложенности наамного проще.
Пункт 8: IE6 ещё жив)
+ автору
+ автору
Спасибо автору за полезный труд. Несогласен только в нескольких пунктах:
1. Всё должно быть абсолютно валидным.
Должно быть нормальным и читаемым, а не подстроенное под идиотские правила. Достаточно проверить сайт w3.org на валидность кода, чтобы понять что это чушь.
И потом валидность кода не спасает от плохой верстки.
2. Старайтесь комментировать как можно больше.
Комментируйте при необходимости, т.к. это не код на языке ассемблера и вполне читаем.
Да и Reset не нужен. Reset — зло!
1. Всё должно быть абсолютно валидным.
Должно быть нормальным и читаемым, а не подстроенное под идиотские правила. Достаточно проверить сайт w3.org на валидность кода, чтобы понять что это чушь.
И потом валидность кода не спасает от плохой верстки.
2. Старайтесь комментировать как можно больше.
Комментируйте при необходимости, т.к. это не код на языке ассемблера и вполне читаем.
Да и Reset не нужен. Reset — зло!
IE6 официально умер.
Это что за ересь? Его используют примерно 10-15% от числа
пользователей интернета, а значит IE6 живее всех живых.
Уважайте не только своё мастерство писать валидный код без костылей,
но и Ваших потенциальных посетителей.
В метро или в церковь в купальниках не пускают — а казалось бы, чем не потенциальные клиенты?..
Казалось бы аналогия, я на деле Вы и сами прекрасно понимаете: единственное, что объединяет Ваш комментарий с моим — слово «потенциальные».
Я бы предпочел настойчиво порекомендовать таким клиентам какой-нибудь человеческий браузер. И им доброе дело сделаю, и свои нервы поберегу.
Согласен с Вами. Но вот только будут ли клиенты ваших клиентов скачивать новый браузер, ради того чтобы посмотреть разъехавшийся в ie сайт и приобрести продукт/заказать услугу, вместо того чтобы просто уйти к конкурентам.
В вопросе борьбы с ie не существует универсальных рецептов. И не всегда можно его игнорировать.
В вопросе борьбы с ie не существует универсальных рецептов. И не всегда можно его игнорировать.
И для чего его поддерживать, когда кругом от него отказываются и он приносит столько проблем?
Нужно помогать людям отказываться от ie6, а не активно поддерживать его и переживать по поводу верстки для ie6.
Нужно помогать людям отказываться от ie6, а не активно поддерживать его и переживать по поводу верстки для ie6.
>Например, перед блоком header я пишу /* Шапка */, перед footer /* Подвал */
несколько раз сталкивался с тем, что «не латиница» в комментариях приводила к некорректной обработке CSS. Правда было это довольно давно, но с тех пор никогда не использую кирилицу в CSS. не зависимо от кодировки.
несколько раз сталкивался с тем, что «не латиница» в комментариях приводила к некорректной обработке CSS. Правда было это довольно давно, но с тех пор никогда не использую кирилицу в CSS. не зависимо от кодировки.
1. Всё должно быть абсолютно валидным. Я стараюсь избежать даже warning’ов.
Что делать если я хочу написать element::-moz-focus-inner { border: none; padding: 0; }?
Правило это должно звучать так: придерживайтесь стандартов, если есть возможность. Валидность ради валидности — бред
2. Старайтесь комментировать как можно больше.
Зачем комментировать тривиальные вещи, записались в КО? Для всего остального есть CSSDoc
3. Разбивайте файл на логические блоки.
Опять же CSSDoc + разбивайте всё на файлы, а не просто блоки, тогда не нужно скроллиться вверх-вниз на сотни/тысячи строк
6. Используйте 2 стиля написания, короткий и длинный
Вредное правило. Пишите как вам удобно, а потом в любом случае склеивайте все файлы в один и жмите!
Кстати на разнице написания вы экономите сущие копейки: если \t выглядит большим, это не значит, что он много весит : D
IE6 официально умер. Большую часть всего можно верстать валидно используя CSS Reset
IE6 будет жив ещё минимум год. И чем ему мешает reset? Почему reset «невалиден»?
И да, на счёт комментариев. Инлайн комментарии в IE6 ломают парсер: )))
Например: правила после /** Тест */ не будут работать, зато после /** Тест **/ или тем же самым в несколько строк, будут
Например: правила после /** Тест */ не будут работать, зато после /** Тест **/ или тем же самым в несколько строк, будут
> Ставить заплатки(костыли) под разные браузеры уже не модно.
С каких пор? Во всех школах, универах и компаниях стоит пиратская винда, и ни чего там естественно не обновляется. А если ЦУ сидит под убийством как шестой ИЕ, то хочешь — не хочешь, без костылей никак.
> 6. Используйте 2 стиля написания, короткий и длинный:
Если у нас CSS в 2000 строк, то удаление всех пробелов и переносов сократит файл на жалкие 3-5 КБ.
Если это так важно, ничто не мешает сжимать CSS простым скриптом.
С каких пор? Во всех школах, универах и компаниях стоит пиратская винда, и ни чего там естественно не обновляется. А если ЦУ сидит под убийством как шестой ИЕ, то хочешь — не хочешь, без костылей никак.
> 6. Используйте 2 стиля написания, короткий и длинный:
Если у нас CSS в 2000 строк, то удаление всех пробелов и переносов сократит файл на жалкие 3-5 КБ.
Если это так важно, ничто не мешает сжимать CSS простым скриптом.
И мне нравится использовать id для тех элементов, которые на странице в единственном экземпляре, т.к. в css к ним упрощается доступ.
Например:
div#top-menu div.item {...};
а не
div.main div.header div.top-menu div.item {...};
Еще Вы забыли указать хорошую вещь для CSS — important
например
div#top-menu div.item a{color:#000000};
Например:
div#top-menu div.item {...};
а не
div.main div.header div.top-menu div.item {...};
Еще Вы забыли указать хорошую вещь для CSS — important
например
div#top-menu div.item a{color:#000000};
блин, не дописал:
например
div#top-menu div.item a{color:#000000};
div#top-menu div.active a{color:#dcdcdc!important};
потом в коде удобно (для абстрактного языка программирования)
...div class=«item (if(...){active})»…
или же jQuery Вы делаете addClass('active'), здесь такой CSS тоже удобен
например
div#top-menu div.item a{color:#000000};
div#top-menu div.active a{color:#dcdcdc!important};
потом в коде удобно (для абстрактного языка программирования)
...div class=«item (if(...){active})»…
или же jQuery Вы делаете addClass('active'), здесь такой CSS тоже удобен
#top-menu — не очень разумно выглядит, лучше так: #header .menu
Соответственно, если потребуется меню внизу, то можно наследовать.
Мне тоже кажется удобным структурным элементам на странице id давать (container, header, body, footer). А потом с помощью mootools люблю брать элементы так: $('container').getElement('.menu')
=)
Соответственно, если потребуется меню внизу, то можно наследовать.
Мне тоже кажется удобным структурным элементам на странице id давать (container, header, body, footer). А потом с помощью mootools люблю брать элементы так: $('container').getElement('.menu')
=)
Ставить заплатки(костыли) под разные браузеры уже не модно
Можно примеры заплаток? У меня как-то выходит все без них.
Например 3px gap раньше заплаткой заделывал, а теперь просто не использую margin в таких блоках и все отлично.
А на что еще люди заплатки ставят?))
Можно примеры заплаток? У меня как-то выходит все без них.
Например 3px gap раньше заплаткой заделывал, а теперь просто не использую margin в таких блоках и все отлично.
А на что еще люди заплатки ставят?))
Еще про именование классов добавил бы пункт. Нередко можно увидеть нечто такое:
.block-top-right {}
Это полный крандец. Нужно именовать не по расположению или как сказал всевышний, а по тому, что в нем будет.
Например:
.user {}
.search {}
.add {}
.content { /* общий блок для контента, его все наследуют */ }
.content-news {}
и т.д. в таком духе
.block-top-right {}
Это полный крандец. Нужно именовать не по расположению или как сказал всевышний, а по тому, что в нем будет.
Например:
.user {}
.search {}
.add {}
.content { /* общий блок для контента, его все наследуют */ }
.content-news {}
и т.д. в таком духе
По мне, лучше когда:
#content — т.к. он один на странице чаще всего
в нем .news-list, в нем .item
итого:
div#content div.news-list div.item
без лишних слов в html'e
иначе, когда у Вас 20 новостей, 20 раз:
div class=«content-news-list-item» (и выглядит страшнее)
Вспомните ООП, вы же не делаете в классе у методов и свойств прибавку имени родительского класса в имени.
#content — т.к. он один на странице чаще всего
в нем .news-list, в нем .item
итого:
div#content div.news-list div.item
без лишних слов в html'e
иначе, когда у Вас 20 новостей, 20 раз:
div class=«content-news-list-item» (и выглядит страшнее)
Вспомните ООП, вы же не делаете в классе у методов и свойств прибавку имени родительского класса в имени.
Я про другое:
В ООП как раз таки прибавка и делается, в самом начале. :)
В ООП как раз таки прибавка и делается, в самом начале. :)
тьфу, забыл, что обрезалка работает)
<div class=«content content-news»>
<div class=«item»></div>
<div class=«item»></div>
<div class=«item»></div>
</div>
<div class=«content content-news»>
<div class=«item»></div>
<div class=«item»></div>
<div class=«item»></div>
</div>
div class=«content content-news» мне мозг рушит, да и чревато это
Лучше:
content в нем news а в нем item, тогда это унификация, иначе:
content в нем content-news а в нем content-news-item, но это некрасиво в коде html
хотя, это личное дело каждого, оптимизировать html в ущерб css или же css в ущерб html
Лучше:
content в нем news а в нем item, тогда это унификация, иначе:
content в нем content-news а в нем content-news-item, но это некрасиво в коде html
хотя, это личное дело каждого, оптимизировать html в ущерб css или же css в ущерб html
Да :) Если иметь в виду типы, но у меня ассоциации больше с непосредственными методами и свойствами )))
.block-top-right — для визуального блока вполне нормально название
Посмотрите SASS. Эта штука избавит вас от необходимости придумывать подобные стандарты кодирования, сильно упростив ваш код.
Синтаксис очень похож на sandbox.pocoo.org/clevercss, если не использовать самые особенные особенности (sic!) можно компилировать одно другим :)
Я давно привык оформлять свой код как-то вот так:
Про пользователей тоже не забываем webo.in/articles/habrahabr/14-minifing-css/ 
0. не надо выдавать своё мнение за единственно верное, тем более что это не так :-Р
1. геморрой не стоит свеч.
2. масло масленное.
3. не надо все яйца (логические блоки) совать в одну корзину (файл).
4. это годилось бы лишь для логически однородных свойств. не стоит ломать естественные кластеры.
5. её крайне неудобно поддерживать.
6. ну да, а при изменении количества свойств, менять один стиль на другой. очень весело.
7. единственный дельный совет.
8. при чём тут ие6? остальные всё делают одинаково? ха! три раза
1. геморрой не стоит свеч.
2. масло масленное.
3. не надо все яйца (логические блоки) совать в одну корзину (файл).
4. это годилось бы лишь для логически однородных свойств. не стоит ломать естественные кластеры.
5. её крайне неудобно поддерживать.
6. ну да, а при изменении количества свойств, менять один стиль на другой. очень весело.
7. единственный дельный совет.
8. при чём тут ие6? остальные всё делают одинаково? ха! три раза
1. Всё должно быть абсолютно валидным. Я стараюсь избежать даже warning’ов.
Лучше всех высказался на эту тему С. Чикуенок. Что-то вроде — «Я никогда не получал задания написать красивый код..» А насчет эффективности, тестировали мы тут с коллегами… 0.5 секунды теряет браузер при рендере страницы на ошибках… если ошибок 10 000.
4. Сортируйте свойства CSS по алфавиту.
Может и удобно. Есть еще такой подход, сортировать свойства группами или по частоте применения, например:
первыми описываются основные свойства (display, позиционирование, плавающая модель), затем размеры и отступы, далее свойства текста и шрифта, цвет, бордер, фон.
Кстати, этот мой подход повторил в своем докладе практически один в один В. Макеев aka pepelsbey на первом РИТе. Если это пришло в голову в одинаковом виде нескольким людям, возможно в этом что-то все таки есть =)
8. Обязательно используйте CSS Reset.
Про «обязательно» Вам тут уже много сказали, я могу только присоединиться =)
А про ластик… ну если кому-то с ним проще, так и пожалуйста, но надо учитывать область применения. Если на сайте-визитке или промо главное точное отображение, то на высоконагруженных проектах где борются за каждые 0.1 с. ластик может выйти боком.
Лучше всех высказался на эту тему С. Чикуенок. Что-то вроде — «Я никогда не получал задания написать красивый код..» А насчет эффективности, тестировали мы тут с коллегами… 0.5 секунды теряет браузер при рендере страницы на ошибках… если ошибок 10 000.
4. Сортируйте свойства CSS по алфавиту.
Может и удобно. Есть еще такой подход, сортировать свойства группами или по частоте применения, например:
.box {
display: block;
position: absolute; left: 10px; top: 3px;
width: 100px; height: 50px;
margin: 12px; paddong: 0;
text-decoration: none;
font: bold 1.2em/1.3 Tahoma;
color: #fff;
border: 1px solid red;
background: none;
cursor: pointer;
}
первыми описываются основные свойства (display, позиционирование, плавающая модель), затем размеры и отступы, далее свойства текста и шрифта, цвет, бордер, фон.
Кстати, этот мой подход повторил в своем докладе практически один в один В. Макеев aka pepelsbey на первом РИТе. Если это пришло в голову в одинаковом виде нескольким людям, возможно в этом что-то все таки есть =)
8. Обязательно используйте CSS Reset.
Про «обязательно» Вам тут уже много сказали, я могу только присоединиться =)
А про ластик… ну если кому-то с ним проще, так и пожалуйста, но надо учитывать область применения. Если на сайте-визитке или промо главное точное отображение, то на высоконагруженных проектах где борются за каждые 0.1 с. ластик может выйти боком.
UFO just landed and posted this here
Обязательно используйте CSS ResetОчень вредный совет. Global reset просаживает скорость рендеринга на 5-7% примерно,
pastebin.com/uKHRGRDu — разница не обнаружена
точнее pastebin.com/2Ute4HUi
Ты замечательно ресетишь одни элементы, а потом используешь span'ы. Я давал ссылку на клуб где есть тесты by banzalik.
я тестировал вообще со звёздочкой :-Р
pastebin.com/bWPGtnLH — ничего не поменялось
pastebin.com/bWPGtnLH — ничего не поменялось
а тест банзалика не содержит обнуления отступов в каждом правиле в случае отсутствия ресета.
впрочем, по его же тестам в ие ресет на 20-25% быстрее
впрочем, по его же тестам в ие ресет на 20-25% быстрее
4. Сортируйте свойства CSS по алфавиту.
Крайне неэффективно. Смотрите сами:
bottom:0; font:sans-serif; letter-spacing:-1px; position:absolute;
Т.е. pos:abs и bottom:0 лежат в коде отдельно, хотя работают в связке и сильно зависят друг от друга.
Я сортирую по функциональным группам:
1. Позиционирование
2. Поведение и свойства блока
3. Размерность блока
4. Цветовое оформление
5. Специальные типы содержимого
6. Текст
7. Визуальные свойства
8. Печать
Здесь подробнее: code.google.com/p/zen-coding/wiki/ZenCSSPropertiesRu
Первая рекомендация сомнительна.
Есть куча хаков для ie (и других), они не валидны.
Подключение отдельных css через условные комментарии — слишком «дорого»
Есть куча хаков для ie (и других), они не валидны.
Подключение отдельных css через условные комментарии — слишком «дорого»
> 4. Сортируйте свойства CSS по алфавиту.
С этим я бы поспорил. Если стиль должен перекрывать другой, то записывать его нужно ниже.
С этим я бы поспорил. Если стиль должен перекрывать другой, то записывать его нужно ниже.
Предпочитаю групировать исходя из назначения:
Шаблон для групировки тегов (групы обиваются пустой строкой):
div, span { }
h1, h2, h3, h4, h5, h6 { }
address, blockquote, p, pre { }
dl, dt, dd, ol, ul, li { }
table, caption, thead, tbody, tfoot, tr, th, td { }
img, object { }
form, fieldset, legend, label, input, select, optgroup, option, textarea, button, a { }
Шаблон для групировки свойств (каждая группа на отдельной строке в блоке):
1. Цвет и фон:
color; background-color; background-image; background-attachment; background-position; background-repeat; border-color;
2. Текст:
font-style; font-variant; font-weight; font-family; font-size; line-height; vertical-align; text-align; text-indent; text-transform; text-decoration; letter-spacing; word-spacing; white-space;
3. Блок:
border-style; border-width; padding; width; max-width; min-width; height; max-height; min-height; overflow;
4. Позиционирование:
display; margin; float; clear; position; left; top; right; bottom; clip; z-index;
5. Прочее:
list-style; border-collapse; border-spacing; caption-side; empty-cells; visibility; opacity; cursor; outline; content; quotes;
Применение на примере класса горизонтального меню:
.inline {
word-spacing: 1em;
padding: 0; overflow: hidden;
margin: 0;
list-style: none;
}
.inline li {
white-space: nowrap;
padding: 0;
display: inline; margin: 0;
}
.inline a { word-spacing: normal; }
.inline a:hover { text-decoration: none; }
.inline .this a { font-weight: bold; text-decoration: none; }
HTML код:
<ul class="inline">
<li class="this"><a href="#">Пункт меню 1</a></li>
<li><a href="#">Пункт меню 2</a></li>
<li><a href="#">Пункт меню 3</a></li>
<li><a href="#">Пункт меню 4</a></li>
<li><a href="#">Пункт меню 5</a></li>
<li><a href="#">Пункт меню 6</a></li>
<li><a href="#">Пункт меню 7</a></li>
<li><a href="#">Пункт меню 8</a></li>
<li><a href="#">Пункт меню 9</a></li>
</ul><!-- .inline -->
UFO just landed and posted this here
Sign up to leave a comment.
Правила хорошего CSS