SelenIT

Полностью присоединяюсь к вышесказанному!

Сделайте 2 тени с отрицательным 4-м параметром и нужным смещением по вертикали.

в IE7- с баттонами было несколько багов: во-первых, при наличии в форме нескольких кнопок, при сабмите отсылалось не value нажатой, а innerHTML всех (делая невозможным определение, какая кнопка была нажата, на сервере). Во-вторых, по умолчанию у кнопки был тип button, а не submit, как по стандарту HTML 4+. В-третьих, с кнопками во всех браузерах есть проблемы с оформлением. У кнопки по умолчанию display:inline-block, и во многих браузерах его не изменить вообще (напр. display:table-cell для кнопок игнорируется). В Фоксах у кнопки по умолчанию лишних 3px паддинга (лечится его обнулением для ::-moz-focus-inner). Из-за этих проблем кнопками пользуются намного реже, чем следовало бы. Потому что идейно и с точки зрения юзабилити (управление с клавиатуры и т.п.) для абстрактных активных элементов ничего лучше нет.

AdBlock очень придирчив к картинкам, в именах и путях которых присутствуют слова «banner», «ad» и т.п.

Мне кажется, компромиссным вариантом тут будет вариант с подзаголовками, но без <article> (дело не в том, сколько раз его использовать, а в том, что вряд ли пол-статьи без главного заголовка — законченная отдельная самодостаточная смысловая единица, т.е. <article> для нее просто неуместен). Если уж во что бы то ни стало хочется использовать модные новинки HTML5, можно в варианте 2 заменить <article> на <section> — он уместен как раз для несамодостаточных смысловых частей.

Повторяющаяся коричневая полоса с формой "сделать заказ", по-моему, вполне фиксированной высоты. Я бы, честно говоря, сделал повторяющийся кусок одной PNGшкой с прозрачными вырезами зубцов, и заставил всю полосу чуть накладываться на предыдущий/следующий блок через margin: -10px 0; position: relative;. А шапку и первый блок, если не заморачиваться видом при отключенной графике и т.п., можно вообще одной картинкой сделать.

Авторитетных подтверждений, что модные элементы HTML5 помогают поисковому продвижению, мне до сих пор не попадалось. Так что по умолчанию лучше отталкиваться от здравого смысла и делать хороший контент для людей. Подзаголовки — хорошо, с ними и текст легче читается, и поисковики их ценят. А вот <article> лучше не злоупотреблять, т.к. <article> предполагает, что его содержимое — самодостаточная, независимая от окружения смысловая единица и может без проблем быть целиком вынесена в RSS-поток или еще куда-нибудь. С <header> то же самое, ради одного голого заголовка он избыточен, а вот для объединения заголовка с именем автора, датой публикации, ссылками на предысторию и т.п. — вполне уместен.

При указании float игнорируются многие значения display. Float и inline-block противоречат друг другу (inline-block помещает элементы в текстовый контекст, а float вообще вырывает их из потока, но оперирует ими, как блоками), при этом float приоритетнее. В итоге при наличии float итоговый display оказывается просто block. Да, и еще «скукожить» пробелы между блоками, если они есть (напр., через font-size: 0 для контейнера).

Зачем? Зачем указывать inline-block (который, кстати, после минимальной доработки напильником мог бы решить задачу) и тут же вырубать его float-ом?

Насколько я могу судить по докладу главного разработчика печатной версии Яндекс-карт на недавнем минском WSD, яндексовцы (по крайней мере, те, кто делает карты) — ребята прагматичные и стараются, чтобы решение как можно лучше удовлетворяло 99% пользователей, ориентируясь на результат и особо не заморачиваясь ни абстрактными «хорошо-плохо», ни проблемами оставшегося 1% (ведь недовольные будут всегда). Заменять амперсанды HTML-сущностями нужно только при вставке URLов в HTML-атрибут, при этом в браузерах всё прекрасно работает и без этого (т.е. большинству пользователей никакие добавочные действия не нужны). Скрипты часто переносят в «ленивую загрузку» и т.п., где HTML-сущности были бы только лишними. Без сущностей URL легче читается, добавить их ради валидности проще, чем убрать. Не могу ручаться, что логика была именно такая, но если оно так, вполне могу это понять...

Я думаю, оно намного раньше пошло, вернее, POSHло

Да, особенно «старый» -webkit-синтаксис и тому подобное. Раньше я был их сторонником (максимальный охват и всё такое), но практический опыт пользования андроид-браузером на одноядерном проце учит, что чем проще страница — тем больше шансов, что она по крайней мере загрузится и отрисуется до конца...

С современными смартфонами не всё так просто. То, что там 1280-1920-100500 пикселей в ширину, еще не значит, что сайт будет открываться как на окне такой ширины. Думаю, разумно ориентироваться на 800 как минимум, причем на этих 800 шрифт не должен быть слишком мелким, и, желательно, не должно быть ничего лишнего (media queries спешат на помощь). И, по опыту пользователя дешевого андроида, скажу, что не надо насиловать старые браузеры градиентенями и трансформанимациями — и слабенькому процессору легче, и батарея целее, и в коде писать меньше (достаточно стандартного синтаксиса)...

Чем таким суровым валидировали, если не секрет? Насколько я в курсе, атрибут title ни в одной спеке ни для одного элемента не был обязательным. С alt для <img> не перепутали случаем? Можно увидеть источник такого интересного определения? Если там XSLT-шаблоны (как говорит автор), то они в общем случае должны быть веллформным XML, это да. Тут совместимость выручает. Сила HTML5 — не в том, что слеши можно не ставить, а в том, что ими можно не париться

Тема 10-го года. Вообще вопрос про формы издавна был холиворным (даром что спеки HTML 4/XHTML 1 разрешали использовать для этой цели таблицы, и это был самый практичный выход, но тогда многие страдали таблицефобией и спискоманией). Что касается преимуществ, то «тематическая группировка» между полем, его подписью и (опционально) расшифровкой/подсказкой/пояснением/уточнением, имхо, очевидна. И читалкам желательно делать между такими группами паузы, а не тараторить их подряд. Поэтому span отпадает, группа должна быть «блочным» (в терминах HTML 4) элементом. Имхо, дивы, конечно, универсальнее (в спеке полно примеров и с ними), но они оправданнее, если форма должна быть навороченным виджетом с хитрым оформлением и интерактивностью. А если форма идет прямо в тексте, с общепринятыми для контента сайта отступами между полями и т.п. — вполне оправданы и абзацы.

Спецификация (см. второй пример использования для <label>) не так категорична)

Потому что span по умолчанию имеет display:inline и живет в инлайновом контексте форматирования, а там вертикальные margin-ы и padding-и на высоту не влияют, всё решает line-height. А с display: block сам margin-то работает, но мы этого не видим, потому что у родителя стоит фиксированная ширина 40px и overflow: hidden, поэтому отступ, создаваемый margin-ом, просто обрезается.

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

Градиент же радиальный. Вот радиус (для эллипса — соотв. полуось) и указывается относительно размера контейнера. Если радиус (большая полуось) 50% от ширины контейнера, значит, диаметр (вся большая ось) будет 100%. Что и наблюдаем, по-моему.

Видимо, ближайшей стороной к середине верхней стороны оказывается... сама верхняя сторона. Т.е. эллипс рисуется нулевой ширины. Нагляднее, если вместо top взять, скажем, 2px. А противоположная сторона при таком раскладе считается дальней стороной.

Где здесь что-либо про встроенную анимацию браузеров?

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

Есть, называется «изящная деградация» и «прогрессивное улучшение». Правильное отображение сайта в старье — быстрое, а не навороченное ценой нагромождения костылей.

См. здесь, перед примером 3.26 и ниже.

http://webfont.ru/blog/about-font-face-part-two/#section_2