SelenIT

Еще можно сделать через наложение фиксированных колонок поверх паддингов/бордеров резиновых (с бокс-сайзинг:бордер-бокс) отрицательными марджинами. А вообще пора флексбоксов на дворе…

Секция — логическая группировка по смыслу. Если контейнер-роу-что-то, то это, скорее всего, визуальная группировка, т.е. div.

Имхо, ресет — это «ковровое» обнуление нормальных свойств элементов, типа жирности у b/strong или полей у p, для всех случаев. Это бывает полезно в навороченных макетах из разношерстных неповторяющихся блоков, но чаще оказывается лишним действием. А тут именно браузероспецифичные хаки, не меняющие привычного поведения элемента в целом, но сглаживающие мелкие разночтения.

Да, прозрачные PNG очень не дружат с древнеIE-шными фильтрами. Иногда помогала комбинация с другими фильтрами. В случае alpha, говорят, помогало что-то такое (но не всегда, ЕМНИП).

В примере http://jsfiddle.net/avExc/3/ вроде по факту получается, что очередь чистится по завершении каждой анимации? И с тем же успехом можно чистить очередь всегда, перед запуском новой анимации?

Вот в данном случае, имхо, вреда от этих строчек всяко меньше, чем возможной пользы (напр. переносимости одного и того же стиля и для ссылок, и для кнопок). Но я бы не назвал это ресетом. Вариант кастомного нормалайза — возможно. Но по мне это просто часть своей библиотечки полезных хаков, наряду с клирфиксом-шмирфиксом и т.п. Вот однозначно вредным в популярных ресетах я считаю переопределение border-collapse у таблиц. Да, это убирает зазоры между ячейками в IE7-, но мешает, например, слёту закруглить углы у ячеек...

Конкретно для кнопок почему-то это не совсем так в IE9-10.

Да, так компактнее и изящнее. Но идея вроде ж та же, что у меня — игнорить нажатия во время текущей анимации?

Я встречал только исследование 2010 года, где влияние сочетания заголовка со ссылкой, да, признавалось отрицательным, но на уровне ниже существенной значимости. Вот картинка в заголовке, да, по тому исследованию — не ахти (честно говоря, эту страницу я только сейчас рассмотрел). С другой стороны, совсем без главного заголовка еще хуже, а больше его тут особо никуда и не приткнешь. Вообще SEO и логика разметки нередко друг другу противоречат, и, имхо, отталкиваться лучше всё-таки от логики (хотя бы потому, что она не так часто меняется, как критерии поисковиков), а SEO-проблемы решать по мере появления. В конце концов, поисковики становятся всё умнее и всё ближе подходят к идеалу, чтобы первые места в выдаче доставались хорошим страницам, удобным для пользователя, а не накрученных сомнительной магией... Слишком большая вложенность — плохо. 8 вложенных оберток ради стилизации сторон и уголков (бывало такое в до-border-radius-ную эпоху) — однозначное зло для рендерера. Но размещение 4 больших float-нутых блоков вполне может оказаться легче для рендерера, чем россыпи из 20 мелких (впрочем, надо тестировать). В принципе, поколдовав с justify, как раз можно добиться, чтобы это выполнялось автоматически. Имхо, следует избегать нелогичных оберток. Но обернуть список ссылок с его названием в единый логический блок, по-моему, как минимум логичнее, чем запихивать название списка внутрь его, в одну кучу с содержимым списка. Всё хорошо в меру, в т.ч. и упрощение. Иначе можно дойти до абсурда типа 1 тега <pre> с кучей логически неструктурированного текста . Как говорил Эйнштейн, «всё нужно делать настолько просто, насколько это возможно, но не проще».

Насколько я понимаю, проблема в том, что в этом случае куча анимаций ставится в очередь в промежуточный момент предыдущей. Игнорировать нажатия до конца предыдущей анимации (напр. как-то так) — не вариант?

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

Про h1 поддерживаю мысль, что название этой страницы выражено логотипом. Чекбоксы, имхо, можно было бы чисто для удобства сгруппировать в плавающие столбцы по 4 шт., аналогично спискам ссылок в подвале. Тогда не пришлось бы плодить нелогичные классы для задания ширины. В горизонтальных менюшках смущает, что пропадает место под отступы, тогда как текст умещается практически впритык (добавится одно слово текста в любую из ссылок — и привет вторая строка). Я бы рассмотрел варианты CSS-таблицы либо чего-то такого. А то и флексбоксов с деградацией до нынешнего варианта в старье. Еще я бы не делал заголовки списков их элементами (<li class="title">), а поставил бы отдельные h3 какие-нибудь. Не стоит экономия одной обертки такого насилия над логикой. Так можно в HTML5, но знатоки советуют этим не злоупотреблять, т.к. 1) не все браузеры/читалки и т.п. освоили новый алгоритм структуры заголовков, 2) у многих поисковиков по-прежнему особо трепетное отношение к h1, и лучше, чтобы в нем было только самое-самое главное.

Пардон, движок зажевал ссылку, фиксед. Надеюсь, что юмор. Но «комплекс ритуалов и техник, направленных на гадание и предсказание будущего [успеха странички у поисковиков] на основе мифо-магической картины мира» — по-моему, где-то перекликается с правдой…

!= pixel-perfect Зависимость верстки от ширины текста === некроссбраузерно. Потому что есть еще Мак и Андроид (с прочими Линуксами), где рендеринг шрифтов отличается по-настоящему. Кроссбраузерная верстка обязана не ломаться даже в этом случае, поэтому всегда должен быть запас. Но вообще хотелось бы увидеть это чудо. По логике, отличаться при правильном доктайпе должен как раз IE9+...

Имхо, спецификация (хотя бы одна из, в случае HTML5) всё же источник более авторитетный. Имхо, да, как-то так. Впрочем, с точки зрения технологий доступности разница между ними всеми действительно пренебрежимая.

Это что-то новое. Что именно «ломается»? И какой размер шрифта указан, в каких единицах? И не надо! Надо разобраться в причине проблемы. Хотя вообще в 2013-м вполне достаточно идеального отображения в IE9+ и всём современном, а в IE8- достаточно, чтобы текст просто читался. Уже доля мобильных браузеров в разы больше, чем старых IE.

Это точно ни при чем. Другое дело, что среди «табличных» сайтов гораздо больший процент не имеет доктайпа. А без доктайпа страницы рисуются в Quirks mode, в котором все кошки серы все IE — пятые. В 9-м IE нецелые размеры в пикселях стали округляться по-другому. Кстати, вот ответ на вопрос, должны ли сайты абсолютно одинаково выглядеть во всех браузерах.

В спецификации написано «слегка обратное»: 1Перевод фразы «small print» согласно словарю Lingvo. Ага, «SE-мантика» как она есть

«Дрыгается» — в смысле, в примере http://jsfiddle.net/3fvCr/ див при нажатии опускается на 2px? Так там же для .active явно margin-top прописан... Или я не понял проблемы?

Netrenderer.com на этом тесте показывает, что да... UPD: правда, он там слишком округляется. Так что в дополнение к этому методу надо включать hasLayout (если нужно отменить схлопывание с обеих сторон) или отдельно задавать ненулевой padding/border.

Раньше использовал прозрачный однопиксельный border. Сейчас чаще использую padding: 0.1px.

Firefox пока не поддерживает значения space для background-repeat. Хром, судя по всему, только-только начал поддерживать, Яндекс пока за ним не угнался. А в чем фокус картинки back1.png? На моем мониторе она практически неотличима от сплошной заливки... Формально верно, для множественных фонов (см. пример 2).

Имхо, зависит от ситуации. Если правый блок и кнопка относятся к разным логическим блокам, пожалуй, предпочел бы обертку, если желтая кнопка — именно кнопка button, то тоже (т.к. нельзя просто взять и поменять display у button на что попало). Но вообще, по-моему, у одноячеечной псевдотаблицы без border-ов и padding-ов фатальных межбраузерных разногласий возникать не должно, так что панически бояться их не стоит.

Совершенно верно.

Внутренний радиус определяется как внешний минус толщина границы (если результат отрицательный, то 0), Сделать по-другому, насколько мне известно, можно только вложенными блоками.