SelenIT

Вообще, по стандарту, это должно растянуть элемент на всю ширину и высоту родителя. Но в Fx, да, у табличных элементов есть баг по этой части (частично его можно обойти, но лишь частично). Другое дело, 1) зачем этот ужас с дублированием текста ссылок (бедные поисковики!), 2) зачем тут вообще таблица?

не нужен. IE10 понимает стандартный вариант.

Логически header и footer всегда относятся к ближайшему родительскому секционному (структурному) элементу: article, nav, aside, section. Если таковых нет — то к body (т.е. ко всей странице). Другие элементы на эту логику не влияют, поэтому, если для оформительских целей требуется обернуть их дивом — это ничему не помешает.

Я бы сделал как-то так: li { list-style: none; position: relative; } li:before { content: '—'; position: absolute; left: -2em; }

И что, если картинка? А для IE6-8 — более статичная страница или можно пошаманить с фильтром AlphaImageLoader...

Не задавать ширину вообще? Блочные элементы ведут себя нужным образом по умолчанию. Еще можно «добить» недостающие пиксели соответствующим увеличением padding-а или border-а, но скорее всего это не понадобится. В теории есть width: calc(100%+7px), но пока вот так.

Не вместо, прямо как написано. Это сочетание :not() и простейшего селектора атрибута.

a:not([class]):not([id])?

Нашел подтверждение, что IE8-таки пофиксили между бетами и RC1 (заметка Сильвена Галино в блоге MS 2009 г.): Наконец можно забыть про -ms-filter с полностью спокойной совестью

Во втором случае имелось в виду a:hover, a.more-link p:hover {...}?

Как вариант (на скорую руку, есть куда оптимизировать).

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

Поддерживать или не поддерживать теги может только браузер. От доктайпа лишь зависит, будут ли они валидными или невалидными, но работать (или не работать) они будут независимо от этого. Хотя крайне желательно, чтобы браузер работал в стандартном режиме отображения, и короткий доктайп — простейший способ гарантированно добиться этого.

Мысль первая: alert не умеет писать в документ, значит, надо поискать другие методы вывода.

Размер шрифта (кегль) не равен высоте прописных букв (там еще резервируется место под выносные «хвостики», диакритические знаки типа точек над Ё и т.п.). Придется подгонять точный размер для конкретного шрифта.

Как вариант — родительскому диву position: relative, дочернему position: absolute; top: 0; bottom: 0;. Но вообще создавать отдельный див ради двухпиксельной отбивки — сомнительная идея. Бордером/фоном/outline-ом/тенью самого контейнера с текстом эту линию никак не нарисовать?

Как вариант.

На самом деле всё чуть сложнее. Статья по ссылке — вольный пересказ статьи Люка Стивенса на netmagazine.com, в свою очередь являющейся переработанной главой из его книги «Правда про HTML5 для веб-дизайнеров» (подзаголовок статьи — «отчасти полемика, отчасти руководство к действию»). И ситуация с построением схемы (плана) документа по структурным элементам действительно несколько противоречива — настолько, что W3C готов выбросить этот раздел из «первой очереди» стандарта, которую он собирается выпустить к 2014 году под названием «HTML5.0» (и оставить «на неясное будущее» для следующей итерации стандарта, «HTML5.1»). Нативно этот алгоритм (и соответствующая стилизация заголовков!) поддерживается минимум в 3-х браузерах (Fx, Сафари и Хром) и минимум одном скринридере для слепых (JAWS). Но в остальных случаях возможна неоднозначность (а семантика придумана, чтоб уменьшить ее, не так ли?). Даже такой давний авторитет в юзабилити, как Роджер Йоханссон, не советует злоупотреблять section-ами (и как минимум советует сохранять структуру заголовков обратно совместимой со старым алгоритмом схемы документа). Реалистичный взгляд на семантику в HTML5, имхо, в этой статье (особенно насчет неоднозначной сущности <article>).

Из-за display: block. Vertical-align работает только в инлайновом контексте, для инлайновых элементов, либо для элементов с display: table-cell. Как вариант, делать меню псевдотаблицей, с display:table у контейнера и table-cell у пунктов. Иначе, пожалуй, в общем случае — только с помощью дополнительных оберток. В частных случаях (когда текст гарантированно в одну строку и т.п.) можно «поиграть» с верхним паддингом. В очень скором будущем появятся новые CSS-механизмы (напр. flexbox), с которыми это станет проще.

Делать все ссылки пунктиром — не очень хорошая идея. Есть недокументированное, но более-менее общепринятое соглашение, что пунктиром подчеркивают псевдоссылки, которые не переходят куда-то, а подгружают что-то аяксом, раскрывают какую-то выпадушку и т.п. Так что в любом случае лучше завести для пунктирных ссылок отдельный класс и задавать его только где нужно.

Ширина float-бокса определяется по «желательной» ширине контента, т.е. сколько занял бы контент, если дать ему свободно растечься в строку (пока хватает контейнера). В данном случае ширина контента сама зависит от ширины красного контейнера (причем заведомо ее переполняет), поэтому, судя по всему, браузеры разруливают циклическую зависимость следующим образом: определяют ширину «голого» контента без учета width подпунктов (т.е. считают, сколько заняли бы внутренние float-ы без указания ширины, т.е. просто суммируют ширину их текста и бордеров), и именно ее берут за 100%, от которой потом берут 70% для подпунктов. Поэтому, чем больше суммарно в подпунктах текста, тем шире становится их контейнер. Но вообще полагаться на эту магию рискованно, т.к. с шириной (и вообще отображением) вложенных float-ов у браузеров бывают разногласия.

Совершенно верно! Приношу извинения (привык с ситуации с height: 100%, и почему-то запомнил ее как общий случай)...

Имхо, это мегаврядли. По-моему, к иконке раздела и фотографии блюда явно требования разные. Про такой компромисс я подумал первым делом. Единственная проблема навскидку, если понадобится этот фон переопределить (напр. для той же моб. версии), придется юзать !important... хотя что это за проблема Ну и сложность, имхо, различается всё-таки не на 5 порядков, а на 1-2 (с учетом кучи готовых/полуготовых решений). Просто вариант, когда у нас полный контроль над графикой (напрямую или через дизайнера) я как-то упустил как тривиальный — интересно было решение в общем случае, даже для секретарши...

Ужимать/обрезать картинки при закачке всё равно ведь заставят, даже в варианте «под секретаршу» . А если всё равно подключать imageMagik и ему подобных, то уж сгенерить на основе результата еще и CSS-строчку — и вовсе пустяк, как мне кажется (по крайней мере, для работника в духе пушкинского Балды, этакого универсала=). Что на картинке «рыба» (в прямом и переносном смысле), понятно, но, имхо, всё равно эти картинки гораздо ближе к дизайнерскому оформлению, чем, например, к картинкам товара в каталоге. Нужны ли они в контенте? Я пока взвешиваю «за» и «против». Вариант с фонами, имхо, подкупает легкостью прикручивания адаптивности. На другом полюсе шепчется малодушная мысль «а не сделать ли, раз пошла такая пьянка, вообще всё картинками, включая текст — так заодно и проблема кроссбраузерности отпадет», но я давлю эту мысль в зародыше

Если всё-таки картинка, то как быть с ее alt?