SelenIT

В Хроме 28 и выше градиент работает, для более старых можно продублировать с нужными префиксами. А вот с бордер-радиусом, да, досадный баг. В Хроме удалось побороть добавлением невидимого бордера (http://jsfiddle.net/Rh6U7/2/). В Safari 5.1, к сожалению, обрезка по контуру уголков не хочет работать ни в какую... но эту версию уже вполне можно считать устаревшей.

В старых IE, кажется, a:focus при клике не поддерживался, приходилось дублировать его a:active. И при фокусе клавиатурой, да, тоже будет работать. Еще в новых браузерах можно использовать :target, например, как-то так (©).

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

Как вариант, возможно, BOM-метка в include-щемся файле.

CoDy, спасибо за найденный баг! Видимо, надо добавить в обработчики листалок stop() для отмены предыдущей анимации. Моя грубая недоработка. Решил простым игнорированием нажатий во время предыдущей анимации: http://jsfiddle.net/3Ch6a/6/. Если кто-то предложит вариант лучше — буду благодарен.

А что это дает? Если надо выстроить ряд блоков в строку, лучше использовать специально обученный inline-block. А если просто убрать отступы между li, лучше обнулить их явно.

В принципе, можно вставить картинку прямо в content: a[rel=nofollow]:after {content: url(../images/template/blank.png); } Но вариант alexriz гибче и практичнее.

1) Есть background-size: 100% и cover (в разумных пределах, но всё же). 2) Картинка не обязательно должна быть цельной (напр. в «Аватаре» №9 парящий утес справа при расширении окна может отъезжать, открывая дальнейшие красоты пандорского горизонта, и т.п.). 3) По-хорошему, да, дизайн должен предусматривать вид хотя бы для нескольких ключевых размеров. Если дизайнер не предусмотрел, в ТЗ явно не оговорено, а сроки поджимают, сугубо имхо — вполне можно воспринимать такой макет как фиксированный.

Дело не в том, что выше или ниже. А в том, подпадает блок одновременно под «раздел с навигацией» и «вводный контент для своего родительского article/section/aside или, при их отсутствии, для всей страницы» или нет. Не каждый header — шапка и не каждая шапка — header (в прошлых редакциях спеки это явно подчеркивалось, сейчас вроде подчистили, но всё же).

Вот такая модификация подойдет?

Но с вероятностью > 90% не нужно

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

Лучше отталкиваться от дизайна . Где дизайнер недодизайнил — там, по идее, всем пофиг. Но если случилось непредвиденное, имхо, пользователю сайта лучше отталкиваться от чего-то осмысленного (даже если в его браузере оно «осмысливается» иначе, чем в соседнем*), нежели от нулей, с которыми текст слипается в кашу. * кстати, по мере развития браузеров различия дефолтных стилей становятся всё меньше и меньше

Может, пора обсуждение «за» и «против» ресета/нормалайза выделить в отдельную тему? Тема-то важная, а здесь затеряется со временем...

Был неправ, признаю.

А вот нечего пользоваться устаревшими атрибутами Видимо, корни привычки тянутся из борьбы с отступами под базовой линией текста, по которой картинки равняются по умолчанию. Но их точно так же можно убрать через vertical-align: top/bottom, еще и с меньшими издержками (картинки останутся в ряд по горизонтали).

По-моему, бордер тут не градиентный, он лишь кажется таким за счет фона. Со светлой полоской, по-моему, проблем нет вообще, тёмную достаточно сделать полупрозрачной (rgba()). Как вариант, темную полоску можно сделать через что-то типа box-shadow: inset -2px 0 -1px rgba(0,0,0,.4).

Не знаю, нумерованные списки в контенте, по-моему, очень часто используются как есть. Плюс у меня устойчивое мнение, что если верстальщик случайно забыл застилизовать какой-то момент, то дефолтный браузерный стиль — меньшее зло, чем слипшаяся нечитаемая каша после reset-а. Хотя «на вкус на цвет», да и случаи разные бывают-с...

Нет, это лишь значит, что терминология для модели содержимого (HTML) и модели визуального отображения (CSS) теперь разная. Чтобы не было путаницы. Что во что можно вкладывать, по-прежнему придется подглядывать в спецификации (или «уточнять» у валидатора). На первый взгляд так, но нужно следить за line-height (справа от размера шрифта в окошке «Character»). Далеко не факт, что тамошнее «Auto» и браузерный дефолт — одно и то же (т.к. алгоритмы рендеринга шрифта разные). И даже при одном и том же значении line-height в пикселях расстояние может «гулять» на пиксель не только между фотошопом и браузерами, но и между разными браузерами — опять же из-за разного алгоритма округления.

Скорее всего, Fx по-своему округляет дефолтный line-height (который зависит от шрифта и очень дробный), из-за особенностей своего субпиксельного рендеринга. Практически, да, 1px погрешности из-за разницы в рендеринге шрифтов (кроме Fx, свой субпиксельный рендеринг бывает еще у IE9+, а еще есть веселуха Win vs. Mac) — абсолютно нормальное и допустимое явление. Но если очень хочется и очень много свободного времени, можно попробовать «пошаманить» с комбинациями font-size/line-height (с шагом по полпикселя в обе стороны) до попадания в приемлемую комбинацию (если повезет).

Catherine, не за что! Еще же не факт, что я не напутал. Но судя по оговорке Бориса Збарски (в цитате s0rr0w выше) про «point of view of the CSS spec» — по-моему, получается логично

Нам надо проверить, что данная tr-ка — не первая. Т.е. перед ней есть хотя бы одна другая. C «+» для каждой tr-ки нужна ровно 1 доп. проверка — именно та, что нас интересует. Всё. Никаких 20 строк С «~», формально, для каждой tr требуется перебрать всех ее предшественников и проверить, не является ли какой-то из них первой tr-кой (да, выглядит нелепицей и в браузерах, вероятно, оптимизировано... но алгоритм есть алгоритм ). Нормально. Короткие селекторы рулят

А чем это лучше? Навскидку явно не быстрее...

Кстати, кто-нибудь может объяснить мне, хотя бы примерно, «что хотел сказать автор» этими таинственными строчками? Спасибо, уже сам нашел ну и некрофилия, конечно...

Имхо, как-то примерно так. Я понимаю так, что для CSS важно лишь то, что рендеринг элемента определяется не только CSSовской же визуальной моделью, но и чем-то еще (напр. какой-то «магией» из недр UI самого браузера или внутренними свойствами стороннего объекта типа картинки). А для HTML тут принципиальная разница в поведении — если для отрисовки системного контрола, грубо говоря, достаточно обратиться к методам этого самого браузерного UI, то для отрисовки внешнего ресурса нужно сперва его запросить, а это уже нетривиальные, к тому же асинхронные, танцы в HTTP (особенно в свете последних нововведений с адаптивными картинками)... Насколько я понимаю, на уровне спецификаций — нет. Но могу (и хочу ) здесь ошибаться.