Comments 103
Скорее все же «Шпаргалка по верстке для больших и маленьких»
Но в целом пост написан достаточно не скучно :)
Но в целом пост написан достаточно не скучно :)
> “?v=версия_файла”.
Вообще запросы с GET-параметрами порой не кешируются даже браузерами, не то что прокси-серверами. Взять ту же Оперу…
Вообще запросы с GET-параметрами порой не кешируются даже браузерами, не то что прокси-серверами. Взять ту же Оперу…
Возможно. Но для всяких айпадов эта штука очень полезна.
Поэтому можно делать ссылку просто вида /css/{версия}/css.css и в nginx рерайтить это в просто /css/css.css
Перезалил css, поменял версию, счастлив
Перезалил css, поменял версию, счастлив
Согласен. Можно и /css/style-{версия}.css, дело не поменяется. Ну а на стороне сервера отдавать это, конечно, из заблаговременного сделанного style.css.tgz, который, кстати собирается из всех таблиц стилей сайта.
Странно, что рецепт с ?version=… так живуч. Так же, как живучи привычка вешать в head загрузку 15-20 малюсеньких css-файликов (конечно, каждый со своим довеском ?version=...). Уж не знаю, какой браузер счастлив от этого :)
Странно, что рецепт с ?version=… так живуч. Так же, как живучи привычка вешать в head загрузку 15-20 малюсеньких css-файликов (конечно, каждый со своим довеском ?version=...). Уж не знаю, какой браузер счастлив от этого :)
/css/style-{версия}.css
Поменяется, в двух случаях:
1. если вы используете импорт стилей (например master.css с содержанием
@import url("reset.css");
@import url("tip.css");
@import url("css.css");Тогда вы кладете все стили в папку /css, и подключив /css/master-{версия} браузер ничего не перезагрузит, а /css/{версия}/master.css — перезагрузит все стили
2. Если вы используете структуру папок типа /assets/master.css, /assets/img/картинки, и в css используете относительные пути к картинкам — то когда вы используете способ /assets/{версия}/master.css — заодно у вас будут и картинки тоже перезагружаться (актуально, когда вы добавляете, например, новые иконки в спрайты)
заблаговременного сделанного style.css.tgz
мы один раз столкнулись на проекте с проблемой, что ie и вроде опера после какого то количества правил css в файле переставали воспринимать все последующие, поэтому стали разбивать на несколько файлов по смыслу
мы один раз столкнулись на проекте с проблемой, что ie и вроде опера после какого то количества правил css в файле переставали воспринимать все последующие, поэтому стали разбивать на несколько файлов по смыслу
На Хабре порой комментарии познавательнее статьи :)
Спасибо, приму к сведению!
Спасибо, приму к сведению!
31 файл css можно подключать на странице в ие, включая те, что в теге style. В каждом внешнем файле через import можно подключить ещё 31 файл стилей.
UFO just landed and posted this here
это понятно, я про количество самих селекторов.
Вот нашел запись:
www.thecssdiv.co.uk/2009/08/another-weird-ie6-bug/
IE6, 7 и 8 перестают воспринимать css селекторы после 4096-го.
Т.е. если у вас большой проект, упаковывать все файлы в один не стоит, если общее количество селекторов может превысить 4096.
Вот нашел запись:
www.thecssdiv.co.uk/2009/08/another-weird-ie6-bug/
IE6, 7 и 8 перестают воспринимать css селекторы после 4096-го.
Т.е. если у вас большой проект, упаковывать все файлы в один не стоит, если общее количество селекторов может превысить 4096.
для автоматического разбиения на несколько файлов есть вот такая штука blesscss.com/
UFO just landed and posted this here
Зачем столько лишних действий? Разве не проще в дописать 4 символа?)
Можно чуть подробнее? Только что проверил — всё прекрасно кешируется в опере. Проблема была в предыдущих версиях? Аналогичную ситуация наблюдаю за squid-ом.
Да, похоже в свежей Опере справились. Со сквидом все интереснее, его директива
refresh_pattern -i (/cgi-bin/|\?) 0 0% 0
как раз обещает обратное.
Но дело в том, как ваша сквида реагирует на запросы, а в том, что кеш — это экономия и трафика, и времени, и уменьшение нагрузки на сервер. Если сквида каждый раз делает запрос («0%» как раз об этом), то сервер рад не будет.
refresh_pattern -i (/cgi-bin/|\?) 0 0% 0
как раз обещает обратное.
Но дело в том, как ваша сквида реагирует на запросы, а в том, что кеш — это экономия и трафика, и времени, и уменьшение нагрузки на сервер. Если сквида каждый раз делает запрос («0%» как раз об этом), то сервер рад не будет.
Чтобы обойти кеширование и в то же время иметь версию в имени файла придумано достаточно изящное решение в .htaccess, которое в факультативном порядке можно доработать для Nginx:
# анти-прокси-кэширование стилей
# style.v123.css -> style.css
RewriteRule ^(.*)\.v[0-9]+\.css$ $1.css
RewriteRule ^(.*)\.v[0-9]+\.js$ $1.js
Опыт верстки весьма немаленький, но вот про хак для IE с createElement() не знал. Спасибо :)
div.class img {vertical-align: -50%;}
Мне кажется, или тут лучше использовать line-height?
Лучше использовать div.class img {vertical-align: middle;}
Ну да, а потом новички начнут задавать вопросы, почему не работает у них в блочном элементе. Да и не такая уж и середина это на самом деле.
Нет, middle не прокатит, если не задать, как минимум, высоту line-height. Поэтому с фиксировнным значением получается экономнее.
Можно и через line-height.
Но я предпочитаю помещать изображение прямо в тег a, тогда vertical-align незаменим.
Но, в любом случае, это только один из вариантов.
Но я предпочитаю помещать изображение прямо в тег a, тогда vertical-align незаменим.
Но, в любом случае, это только один из вариантов.
UFO just landed and posted this here
Оптимальным решением такой проблемы будет:
overflow: hidden
А как насчет блока с clear: both в конце контейнера? Так не будет побочного эффекта, как в примере, отчего считаю такой вариант более оптимальным.
Ну, это как посмотреть. 2 слова в css файле выглядят предпочтительнее, чем div, который может повторятся по нескольку раз на странице.
Поэтому, если известно, что никаких заходящих за границу примочек не предвидится, overflow: hidden — оптимальный вариант.
Поэтому, если известно, что никаких заходящих за границу примочек не предвидится, overflow: hidden — оптимальный вариант.
Тогда .clearfix — этот метод основан на clear: both, но без лишних элементов.
откройте для себя псевдоэлементы:
И никакой хак в виде oveflow:hidden не понадобится
div:after {
content: ".";
height: 0;
display: block;
clesr:both;
}
И никакой хак в виде oveflow:hidden не понадобится
Спасибо, давно открыл:)
Согласен, способ самый универсальный. Спасибо вам за него.
Но опять же, много текста. В 99% случаев можно обойтись 2-мя словами.
Согласен, способ самый универсальный. Спасибо вам за него.
Но опять же, много текста. В 99% случаев можно обойтись 2-мя словами.
На большом проекте, когда вокруг тебя несколько тысяч строк css-а в десятках файлов от разных разработчиков, лишний overflow:hidden, о котором ты не знаешь на уровне выше тебя может принести тонны головняка. Поэтому способ с псевдоэлементом намного предпочтительнее.
Согласен. Но вы сами сказали, что это для больших проектов.
Я думаю, что без необходимости код лучше не усложнять.
Я думаю, что без необходимости код лучше не усложнять.
Любой проект, даже самый малюсенький, даже сайт-визитку, надо воспринимать ка большой проект. Они имеют привычку разрастаться. И тогда вы погрязнете в куче кода типа «ну у меня же маленький проект, и так сойдёт».
Даже на маленьких проектах можно юзать для себя Less. и для каждого вашего проекта подготовить файлик со всевозможными миксинами, начиная от cleafix и заканчивая разными комбинациями бордеров, радиусов и т.д.
Это порядком сократит время разработки, и упростит последующую поддержку.
Это порядком сократит время разработки, и упростит последующую поддержку.
overflow:hidden — не хак, это поведение описано в спецификации. Такого же эффекта можно добиться если применить к элементу display: inline-block; или display: table; В общем все что меняет контекст форматирования.
Но вариант с псевдоэлементом, конечно, лучше все равно.
Но вариант с псевдоэлементом, конечно, лучше все равно.
Можно ткнуть в спецификацию?
UFO just landed and posted this here
Floats, absolutely positioned elements, block containers (such as inline-blocks, table-cells, and table-captions) that are not block boxes, and block boxes with 'overflow' other than 'visible' (except when that value has been propagated to the viewport) establish new block formatting contexts for their contents.
Cогласен. Проглядел.
UFO just landed and posted this here
UFO just landed and posted this here
Всегда шокировала такая запись:
Гораздо проще написать:
document.createElement('header');
document.createElement('section');
document.createElement('footer');
document.createElement('nav');
document.createElement('article');
document.createElement('aside');
Гораздо проще написать:
for(var i=0, el="header footer nav section article aside".split(" ");i<el.length;i++){
document.createElement(el[i])
}
Что проще написать — вопрос спорный. А вот то, что первый вариант читается и понимается намного легче и быстрее — это факт.
факт в том, что код вам надо поддерживать, а не только читать и понимать. второй вариант редактируется гораздо проще.
см. en.wikipedia.org/wiki/Don%27t_repeat_yourself
см. en.wikipedia.org/wiki/Don%27t_repeat_yourself
Чтение и понимание это важнейшая часть процесса поддержки кода.
Простота редактирования… ну, у меня есть ощущение, что количество кнопок, которое потребуется нажать в Vim будет примерно одинаковым в обоих случаях.
Что касается DRY — не стоит верить всем модным аббревиатурам, да и википедии тоже. Некоторые вещи действительно категорически нельзя дублировать. А в других случаях дублирование абсолютно уместно и даже необходимо. Нормализация данных в базе, goto, копипаст, Code Reuse, XML, ООПухоль мозга… много их было, объявленных вселенским злом и вселенским добром, а потом выяснялось, что и зло не такое ужасное а иногда так и вовсе жизненно необходимо, и добро иногда так доставляет, что зла на это добро не хватает. Конкретно в данном примере кода Ваш DRY идёт лесом, ибо он здесь нафиг никому не сдался.
Простота редактирования… ну, у меня есть ощущение, что количество кнопок, которое потребуется нажать в Vim будет примерно одинаковым в обоих случаях.
Что касается DRY — не стоит верить всем модным аббревиатурам, да и википедии тоже. Некоторые вещи действительно категорически нельзя дублировать. А в других случаях дублирование абсолютно уместно и даже необходимо. Нормализация данных в базе, goto, копипаст, Code Reuse, XML, ООПухоль мозга… много их было, объявленных вселенским злом и вселенским добром, а потом выяснялось, что и зло не такое ужасное а иногда так и вовсе жизненно необходимо, и добро иногда так доставляет, что зла на это добро не хватает. Конкретно в данном примере кода Ваш DRY идёт лесом, ибо он здесь нафиг никому не сдался.
Неужели вам этот вариант (ниже) не милее? К тому же он достаточно элементарен, чтобы на нём не спотыкался глаз.
Вариант powerman-а, конечно, перегиб.
var tags = [ 'header', 'footer', 'nav', 'section', 'article', 'aside' ];
for( var i = 0, n = tags.length; i < n; ++ i )
{
document.createElement( tags[ i ] );
}
Вариант powerman-а, конечно, перегиб.
Для меня DRY свят и непогрешим, но в вашем варианте, если сравнивать с исходным копипастом:
Я не говорю, что какой-то вариант хуже или лучше. Просто явного превосходства нет ни у одного из них.
- больше синтаксических конструкций
Массив, for, var, сравнение, инктемент, присвоение, обращение по индексу, вызов метода. Вместо одного только вызова метода (повторенного 6 раз). - 3 дополнительные переменные
- всего на 1 строку меньше (да, я посчитал скобочки)
- строковые литералы отдалены от места фактического использования двумя строками. В копипасте — использование на месте.
Я не говорю, что какой-то вариант хуже или лучше. Просто явного превосходства нет ни у одного из них.
Помимо прочего, я считаю, мой вариант более идеологически верный. Посудите сами — в чём заключается задача? В подключении тегов <header>, <footer>, <section>, <article>, <aside> к списку поддерживаемых тэгов, или всё таки подключения ряда тегов (в число которых входят: ...) к списку поддерживаемых тегов? В данной задаче есть какая-либо существенная разница между aside и section, чтобы был резон описывать подключение каждого тега в отдельно взятой строке?
Сейчас их 6, завтра 12. Добавим ещё 6 строк? :) А если будет удобно передавать список тегов извне в отдельном массиве? Ну и т.д… Я, конечно, несколько перегибаю палку, но ведь вопрос идеологический. На мой взгляд, единственное преимущество исходного варианта — в скорости клепания таких строк.
Сейчас их 6, завтра 12. Добавим ещё 6 строк? :) А если будет удобно передавать список тегов извне в отдельном массиве? Ну и т.д… Я, конечно, несколько перегибаю палку, но ведь вопрос идеологический. На мой взгляд, единственное преимущество исходного варианта — в скорости клепания таких строк.
Не столько в скорости клепания сколько в скорости чтения.
К сожалению самый идеологически верный способ довольно громоздок.
При поддержке ECMAScript5 вопросов бы не возникало:
К сожалению самый идеологически верный способ довольно громоздок.
При поддержке ECMAScript5 вопросов бы не возникало:
var tags = [ 'header', 'footer', 'nav', 'section', 'article', 'aside' ];
tags.forEach(function(entry) { //можно даже без дополнительной переменной обойтись
document.createElement(entry);
});
Такое ощущение, что про метапрограммирование автор и его приверженцы не слышали) DRY спасает от лишней головной боли.
Я Вам скажу, какой вариант мне милее. Вот такой:
document.createElements('header', 'footer', 'nav', 'section', 'article', 'aside');
Или вот такой, если js это поддерживает:
[ 'header', 'footer', 'nav', 'section', 'article', 'aside' ].forEach(document.createElement);
Первый вариант — признак непрофессионализма
Э-э-э…
['header', 'footer', 'nav', 'section', 'article', 'aside'].map( function(el) { document.createElement(el); })
Копипаста в умеренных дозах нередко выразительнее смотрится и лучше читается.
Хотя лично мне в общем идеологически противна.
Хотя лично мне в общем идеологически противна.
1) Нулевая высота блока с плавающими элементами.
Самый лучший способ решить эту проблему это всевдо элемент ::after
2) HTML5 — описанный вами способ это примитивно. Этот способ не решает целой группы проблем при работе с DOM в старых браузерах. Намного лучше воспользоваться HTML5Shiv и подобными штуками а не изобретать свое колесо.
В общем и сложном — все это банально.
Самый лучший способ решить эту проблему это всевдо элемент ::after
2) HTML5 — описанный вами способ это примитивно. Этот способ не решает целой группы проблем при работе с DOM в старых браузерах. Намного лучше воспользоваться HTML5Shiv и подобными штуками а не изобретать свое колесо.
В общем и сложном — все это банально.
UFO just landed and posted this here
Сколько верстаю… пользуюсь clearfix'ом и не наблюдал проблем указанных в примере… я к тому, что все зависит от того «чем и как» верстается… Хотя новая фича понравилась)
UFO just landed and posted this here
Не забываем про обновление того варианта!
Строки:
/* Лекарство бага с отступом в Opera */
font-size: 0.05em;
line-height: 0.05em;
Заменены на:
т.к. с выходом Opera 12.10 оно поломалось, плюс sans-serif решает проблему в случае если к этому же элементу будет применяться сторонний шрифт.
Строки:
/* Лекарство бага с отступом в Opera */
font-size: 0.05em;
line-height: 0.05em;
Заменены на:
font: .13em/0 sans-serif;
т.к. с выходом Opera 12.10 оно поломалось, плюс sans-serif решает проблему в случае если к этому же элементу будет применяться сторонний шрифт.
Ну методов с клерфиксами на самом деле много. Метод по ссылке интересен, но я пока не сталкивался с макетами где .clearfix делал что-то не так. Хотя возьму на заметку.
А вот по поводу того, что эти элементы могут убрать из спецификации, тут хотелось бы больше подробностей. Ибо я пока видел только драфты расширяющие их.
По поводу HTML5Shiv и т.д. — помимо просто стилизации частенько встречаются задачи по работе с этими элементами из JavaScript и приведенный метод не сработает в случае вставки тегов через innerHtml. По крайней мере случаются баги. В целом же только для стилизации да, сойдет.
А вот по поводу того, что эти элементы могут убрать из спецификации, тут хотелось бы больше подробностей. Ибо я пока видел только драфты расширяющие их.
По поводу HTML5Shiv и т.д. — помимо просто стилизации частенько встречаются задачи по работе с этими элементами из JavaScript и приведенный метод не сработает в случае вставки тегов через innerHtml. По крайней мере случаются баги. В целом же только для стилизации да, сойдет.
Может и не по теме статьи, но всё же спрошу уважаемый All: что-то изменилось с центрированием? Есть ли надёжный метод без javascript, используя только CSS, разместить DIV в центре экрана браузера? Спасибо.
Есть — там как раз о расположении блоков по центру экрана браузера.
UFO just landed and posted this here
На шпаргалку не тянет, но за border и отрицательное значение vertical-align спасибо.
UFO just landed and posted this here
От верстки очень далек, но все равно эти все приемы знал. Хочется чего-то посложнее :)
А для кого новыми оказались
А для кого новыми оказались
document.createElement('header');Пост показался скучным, показаны достаточно простые вещи. Для тех кому реально не хватает практики, рекомендую ресурс для изучения:
w3schools.com/html/html5_intro.asp
Нажав, «Try it yourself» можешь посмотреть результат кода в браузере.
w3schools.com/html/html5_intro.asp
Нажав, «Try it yourself» можешь посмотреть результат кода в браузере.
Пишу вот так:
<!doctype HTML>
Я бы еще упомянул об использовании cdn в случае использования js-фреймворков.
А createElement для IE заменяю на
<!--[if lt IE 9]><script src="http://html5shiv.googlecode.com/svn/trunk/html5.js"></script><![endif]-->
А createElement для IE заменяю на
<!--[if lt IE 9]><script src="http://html5shiv.googlecode.com/svn/trunk/html5.js"></script><![endif]-->
Sign up to leave a comment.
Шпаргалка по верстке для больших и маленьких