Шпаргалка по верстке для больших и маленьких

[Igogo2012]

Скорее все же «Шпаргалка по верстке для больших и маленьких»
Но в целом пост написан достаточно не скучно :)

[Paul_King]

Многие аксакалы верстки побаиваются html5:) Поэтому и для больших тоже… Хоть и в меньшей степени.

[monolithed]

А где вы вообще увидели здесь шпаргалку из часто встречающихся проблем?

Автор вы уж извините, но это какой-то неструктурированный обрубок а не статья.

[Smerig]

Ну ладно, я вон про задание бордеров в таком виде узнал впервые.

[achekalin]

> “?v=версия_файла”.

Вообще запросы с GET-параметрами порой не кешируются даже браузерами, не то что прокси-серверами. Взять ту же Оперу…

[Paul_King]

Возможно. Но для всяких айпадов эта штука очень полезна.

[rednaxi]

Поэтому можно делать ссылку просто вида /css/{версия}/css.css и в nginx рерайтить это в просто /css/css.css

Перезалил css, поменял версию, счастлив

[achekalin]

Согласен. Можно и /css/style-{версия}.css, дело не поменяется. Ну а на стороне сервера отдавать это, конечно, из заблаговременного сделанного style.css.tgz, который, кстати собирается из всех таблиц стилей сайта.

Странно, что рецепт с ?version=… так живуч. Так же, как живучи привычка вешать в head загрузку 15-20 малюсеньких css-файликов (конечно, каждый со своим довеском ?version=...). Уж не знаю, какой браузер счастлив от этого :)

[rednaxi]

/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 — заодно у вас будут и картинки тоже перезагружаться (актуально, когда вы добавляете, например, новые иконки в спрайты)

[rednaxi]

заблаговременного сделанного style.css.tgz

мы один раз столкнулись на проекте с проблемой, что ie и вроде опера после какого то количества правил css в файле переставали воспринимать все последующие, поэтому стали разбивать на несколько файлов по смыслу

[achekalin]

На Хабре порой комментарии познавательнее статьи :)

Спасибо, приму к сведению!

[SerCe]

Комментарии на хабре это как общение в кулуарах на конференциях.

[achekalin]

Кто не собрался/опоздал на доклад, чтобы прослушать то, что (по сути) можно и так найти в открытых источниках, узнает много нового от реальных практиков, да.

[kolyuchii]

31 файл css можно подключать на странице в ие, включая те, что в теге style. В каждом внешнем файле через import можно подключить ещё 31 файл стилей.

[rednaxi]

это понятно, я про количество самих селекторов.
Вот нашел запись:
www.thecssdiv.co.uk/2009/08/another-weird-ie6-bug/

IE6, 7 и 8 перестают воспринимать css селекторы после 4096-го.

Т.е. если у вас большой проект, упаковывать все файлы в один не стоит, если общее количество селекторов может превысить 4096.

[sapphiriq]

для автоматического разбиения на несколько файлов есть вот такая штука blesscss.com/

[Paul_King]

Зачем столько лишних действий? Разве не проще в дописать 4 символа?)

[faiwer]

Можно чуть подробнее? Только что проверил — всё прекрасно кешируется в опере. Проблема была в предыдущих версиях? Аналогичную ситуация наблюдаю за squid-ом.

[achekalin]

Да, похоже в свежей Опере справились. Со сквидом все интереснее, его директива

refresh_pattern -i (/cgi-bin/|\?) 0 0% 0

как раз обещает обратное.

Но дело в том, как ваша сквида реагирует на запросы, а в том, что кеш — это экономия и трафика, и времени, и уменьшение нагрузки на сервер. Если сквида каждый раз делает запрос («0%» как раз об этом), то сервер рад не будет.

[faiwer]

Я не наблюдал этого глюка и на предыдущих версиях опер (оперой пользуюсь последние лет 10, "?123123123" методом года 3). Может быть глюк совсем архаичный? Или это я так смотрел?

Касательно squid-а — печаль. Совершенно не понимаю — зачем они так сделали? Это из коробки так? А как squid дружит с 304?

[waitekk]

Чтобы обойти кеширование и в то же время иметь версию в имени файла придумано достаточно изящное решение в .htaccess, которое в факультативном порядке можно доработать для Nginx:

# анти-прокси-кэширование стилей
# style.v123.css -> style.css
RewriteRule ^(.*)\.v[0-9]+\.css$ $1.css
RewriteRule ^(.*)\.v[0-9]+\.js$ $1.js

[achekalin]

Собственно, выше уже этот вариант обсуждался.

Изящное ли это решение, от схемы зависит, по мне — обычный милый хак :)

[Cougar]

Опыт верстки весьма немаленький, но вот про хак для IE с createElement() не знал. Спасибо :)

[kolyuchii]

html5shiv.js

[TiGR]

+ iepp чтобы оно на печати не поехало.

[drakmail]

div.class img {vertical-align: -50%;}

Мне кажется, или тут лучше использовать line-height?

[equinox7]

Лучше использовать div.class img {vertical-align: middle;}

[Resager]

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

[equinox7]

Речь не о блочном элементе, а о конкретном примере с картинкой.

[Paul_King]

Нет, middle не прокатит, если не задать, как минимум, высоту line-height. Поэтому с фиксировнным значением получается экономнее.

[equinox7]

А вы пробовали?

[Paul_King]

Конечно. Насколько я знаю, vertical-align: middle работает только в элементах с display: table-cell или с указанной высотой строки.

[GreatRash]

Неправда.

[Paul_King]

Черт, и правда, что неправда!
Благодарю!

[tagir_valeev]

Так вы пост подправьте :-) Комментарии-то не все читают.

[Paul_King]

Да, немного прослоупочил, простите. Хотел посмотреть, может еще что-нибудь сенсационное для меня напишут :)

[Paul_King]

Можно и через line-height.
Но я предпочитаю помещать изображение прямо в тег a, тогда vertical-align незаменим.

Но, в любом случае, это только один из вариантов.

[zTrue]

Оптимальным решением такой проблемы будет:
overflow: hidden

А как насчет блока с clear: both в конце контейнера? Так не будет побочного эффекта, как в примере, отчего считаю такой вариант более оптимальным.

[Paul_King]

Ну, это как посмотреть. 2 слова в css файле выглядят предпочтительнее, чем div, который может повторятся по нескольку раз на странице.

Поэтому, если известно, что никаких заходящих за границу примочек не предвидится, overflow: hidden — оптимальный вариант.

[lastwish]

Тогда .clearfix — этот метод основан на clear: both, но без лишних элементов.

[Paul_King]

Крутяк, только для IE<9 не прокатит:)

[medved13]

во-первых, для ИЕ<8. :after работает в ИЕ8. во-вторых, там это предусмотрено и он работает везде.

[medved13]

откройте для себя псевдоэлементы:

div:after {
  content: ".";
  height: 0;
  display: block;
  clesr:both;
}

И никакой хак в виде oveflow:hidden не понадобится

[Paul_King]

Спасибо, давно открыл:)
Согласен, способ самый универсальный. Спасибо вам за него.
Но опять же, много текста. В 99% случаев можно обойтись 2-мя словами.

[medved13]

На большом проекте, когда вокруг тебя несколько тысяч строк css-а в десятках файлов от разных разработчиков, лишний overflow:hidden, о котором ты не знаешь на уровне выше тебя может принести тонны головняка. Поэтому способ с псевдоэлементом намного предпочтительнее.

[Paul_King]

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

[medved13]

Любой проект, даже самый малюсенький, даже сайт-визитку, надо воспринимать ка большой проект. Они имеют привычку разрастаться. И тогда вы погрязнете в куче кода типа «ну у меня же маленький проект, и так сойдёт».

[Paul_King]

Тут уже вопрос психики.
Я не поверю, что сайт-визитка разрастется до таких масштабов, что мне при необходимости не удастся в нужном месте заменить overflow:hidden на .clearfix. Я хочу сделать все максимально просто.

А кто-то предпочитает жертвовать простотой ради универсальности, что тоже хорошо.

[Fesor]

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

Это порядком сократит время разработки, и упростит последующую поддержку.

[GreatRash]

overflow:hidden — не хак, это поведение описано в спецификации. Такого же эффекта можно добиться если применить к элементу display: inline-block; или display: table; В общем все что меняет контекст форматирования.

Но вариант с псевдоэлементом, конечно, лучше все равно.

[medved13]

Можно ткнуть в спецификацию?

[medved13]

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огласен. Проглядел.

[medved13]

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

[Connor]

Всегда шокировала такая запись:

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])
}

[powerman]

Что проще написать — вопрос спорный. А вот то, что первый вариант читается и понимается намного легче и быстрее — это факт.

[GearHead]

факт в том, что код вам надо поддерживать, а не только читать и понимать. второй вариант редактируется гораздо проще.
см. en.wikipedia.org/wiki/Don%27t_repeat_yourself

[powerman]

Чтение и понимание это важнейшая часть процесса поддержки кода.

Простота редактирования… ну, у меня есть ощущение, что количество кнопок, которое потребуется нажать в Vim будет примерно одинаковым в обоих случаях.

Что касается DRY — не стоит верить всем модным аббревиатурам, да и википедии тоже. Некоторые вещи действительно категорически нельзя дублировать. А в других случаях дублирование абсолютно уместно и даже необходимо. Нормализация данных в базе, goto, копипаст, Code Reuse, XML, ООПухоль мозга… много их было, объявленных вселенским злом и вселенским добром, а потом выяснялось, что и зло не такое ужасное а иногда так и вовсе жизненно необходимо, и добро иногда так доставляет, что зла на это добро не хватает. Конкретно в данном примере кода Ваш DRY идёт лесом, ибо он здесь нафиг никому не сдался.

[faiwer]

Неужели вам этот вариант (ниже) не милее? К тому же он достаточно элементарен, чтобы на нём не спотыкался глаз.

var tags = [ 'header', 'footer', 'nav', 'section', 'article', 'aside' ];
for( var i = 0, n = tags.length; i < n; ++ i )
{
  document.createElement( tags[ i ] );
}

Вариант powerman-а, конечно, перегиб.

[senia]

Для меня DRY свят и непогрешим, но в вашем варианте, если сравнивать с исходным копипастом:

• больше синтаксических конструкций
  Массив, for, var, сравнение, инктемент, присвоение, обращение по индексу, вызов метода. Вместо одного только вызова метода (повторенного 6 раз).
• 3 дополнительные переменные
• всего на 1 строку меньше (да, я посчитал скобочки)
• строковые литералы отдалены от места фактического использования двумя строками. В копипасте — использование на месте.

Я не говорю, что какой-то вариант хуже или лучше. Просто явного превосходства нет ни у одного из них.

[faiwer]

Помимо прочего, я считаю, мой вариант более идеологически верный. Посудите сами — в чём заключается задача? В подключении тегов <header>, <footer>, <section>, <article>, <aside> к списку поддерживаемых тэгов, или всё таки подключения ряда тегов (в число которых входят: ...) к списку поддерживаемых тегов? В данной задаче есть какая-либо существенная разница между aside и section, чтобы был резон описывать подключение каждого тега в отдельно взятой строке?

Сейчас их 6, завтра 12. Добавим ещё 6 строк? :) А если будет удобно передавать список тегов извне в отдельном массиве? Ну и т.д… Я, конечно, несколько перегибаю палку, но ведь вопрос идеологический. На мой взгляд, единственное преимущество исходного варианта — в скорости клепания таких строк.

[senia]

Не столько в скорости клепания сколько в скорости чтения.

К сожалению самый идеологически верный способ довольно громоздок.

При поддержке ECMAScript5 вопросов бы не возникало:

var tags = [ 'header', 'footer', 'nav', 'section', 'article', 'aside' ];
tags.forEach(function(entry) { //можно даже без дополнительной переменной обойтись
    document.createElement(entry);
});

[Jeket]

Такое ощущение, что про метапрограммирование автор и его приверженцы не слышали) DRY спасает от лишней головной боли.

[Jeket]

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

[powerman]

Я Вам скажу, какой вариант мне милее. Вот такой:

document.createElements('header', 'footer', 'nav', 'section', 'article', 'aside');

Он ещё легче в чтении и поддержке.

[powerman]

Или вот такой, если js это поддерживает:

[ 'header', 'footer', 'nav', 'section', 'article', 'aside' ].forEach(document.createElement);

[matiouchkine]

js поддерживает map:

['header', 'footer', 'nav', 'section', 'article', 'aside'].map( function(el) { document.createElement(el); })

[Jeket]

Первый вариант — признак непрофессионализма

[matiouchkine]

Э-э-э…

['header', 'footer', 'nav', 'section', 'article', 'aside'].map( function(el) { document.createElement(el); })

[Connor]

Это нужно только для IE8 и ниже. А они не поддерживают метод map.

[Flammar]

Копипаста в умеренных дозах нередко выразительнее смотрится и лучше читается.

Хотя лично мне в общем идеологически противна.

[Fesor]

1) Нулевая высота блока с плавающими элементами.
Самый лучший способ решить эту проблему это всевдо элемент ::after

2) HTML5 — описанный вами способ это примитивно. Этот способ не решает целой группы проблем при работе с DOM в старых браузерах. Намного лучше воспользоваться HTML5Shiv и подобными штуками а не изобретать свое колесо.

В общем и сложном — все это банально.

[Grammka]

Сколько верстаю… пользуюсь clearfix'ом и не наблюдал проблем указанных в примере… я к тому, что все зависит от того «чем и как» верстается… Хотя новая фича понравилась)

[alexriz]

Не забываем про обновление того варианта!
Строки:

/* Лекарство бага с отступом в Opera */
font-size: 0.05em;
line-height: 0.05em;

Заменены на:
font: .13em/0 sans-serif;

т.к. с выходом Opera 12.10 оно поломалось, плюс sans-serif решает проблему в случае если к этому же элементу будет применяться сторонний шрифт.

[Fesor]

Ну методов с клерфиксами на самом деле много. Метод по ссылке интересен, но я пока не сталкивался с макетами где .clearfix делал что-то не так. Хотя возьму на заметку.

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

По поводу HTML5Shiv и т.д. — помимо просто стилизации частенько встречаются задачи по работе с этими элементами из JavaScript и приведенный метод не сработает в случае вставки тегов через innerHtml. По крайней мере случаются баги. В целом же только для стилизации да, сойдет.

[Fesor]

Безопаснее это да, но опять же способ не универсален.

[HandleX]

Может и не по теме статьи, но всё же спрошу уважаемый All: что-то изменилось с центрированием? Есть ли надёжный метод без javascript, используя только CSS, разместить DIV в центре экрана браузера? Спасибо.

[Vend3tta]

Есть — там как раз о расположении блоков по центру экрана браузера.

[evil_random]

На шпаргалку не тянет, но за border и отрицательное значение vertical-align спасибо.

[Paul_King]

Логично! Ведь position:relative у блока указывает, что его дочерние элементы должны позиционироваться относительно его.
Именно это я и имел ввиду.

[Paul_King]

Да. Тут с вами согласен.

[olegafx]

От верстки очень далек, но все равно эти все приемы знал. Хочется чего-то посложнее :)
А для кого новыми оказались

document.createElement('header');

и подобные — можете почитать об этом в замечательной книжке по HTML5.

[Jeket]

Пост показался скучным, показаны достаточно простые вещи. Для тех кому реально не хватает практики, рекомендую ресурс для изучения:
w3schools.com/html/html5_intro.asp
Нажав, «Try it yourself» можешь посмотреть результат кода в браузере.

[hejioshin]

Пишу вот так:

<!doctype HTML>

[u4n]

молодец. держи нас в курсе.

[de1vin]

Я бы еще упомянул об использовании cdn в случае использования js-фреймворков.

А createElement для IE заменяю на
<!--[if lt IE 9]><script src="http://html5shiv.googlecode.com/svn/trunk/html5.js"></script><![endif]-->

[Fesor]

Скорее уж так:

<script src="//ajax.googleapis.com/ajax/libs/jquery/1.8/jquery.js"></script>
<script>window.jQuery || document.write('<script src="/bundles/relaxercore/jquery-1.8.3.min.js">\x3C/script>')</script>

[Fesor]

Путь к локальной версии уже самому нужно дописывать. Но рассчитывать на живучесть CDN не стоит.

[Fesor]

Вообще хорошей практикой является вынос всех подключений JS файлов поближе к закрывающему body. Так что да.