SelenIT

Так это, на мой взгляд, как раз к вопросу «зачем ставить доктайп, не имеющий отношения к реальности». Разве что ради какой-то экзотической IDE, понимающей только XML-синтаксис... но тогда надо держать в уме кучу оговорок (напр., что формально валидный в X(HT)ML <div /> с точки зрения реального парсера — незакрытый тег, грубейшая ошибка!).

Про логотип (img vs. заголовок) — это давний холивор . Лично я в общем случае за img (т.к. это часть контента и при этом графика), но бывают нюансы, так что надо смотреть по ситуации.

С HTML5 действительно таких необходимостей стало гораздо меньше. Раньше могло понадобиться, например, поставить Strict-доктайп (чтобы страница отображалась в полностью стандартном режиме, в частности, без глюков с инлайн-блоками в Опере), но при этом оставить target="_blank" для некоторых ссылок (потому что «заказчик очень просит», а формально валидные выверты типа onclick="return !window.open(this.href)" куда хуже). Сейчас, пожалуй, из необходимого остались лишь незнакомые валидатору значения <meta> для интеграции с соцсетками и подобные «косметические» нюансы.

...который всё равно (с вероятностью >99%) будет парситься как HTML5, не так ли? По поводу alt-ов, имхо, неплохое правило буравчика — если не нужен alt, то, скорее всего, не нужен и img (картинка чисто оформительская, которой прямая дорога в фон). Хотя есть исключительные ситуации, когда отсутствие alt допускается. Ну я бы не сказал, что это «несущественное»

В отношении базовой разметки валидатор практически всегда прав. Как минимум, любое сообщение валидатора — повод задуматься. Даже если разработчик может объяснить каждое исключение, зачем и почему оно понадобилось — возможно, они понадобились потому, что разработчик изначально выбрал неудачный инструмент/подход к задаче Голые li без ul/ol — ненормально и неприлично . А вот отсутствие явного закрытия p, li, td, tr, option, явного открытия tbody и т.п. валидности не нарушают, это стандартная (хоть и рискованная в плане поддержки) возможность HTML. Ошибки в микроразметке адреса — из-за лишнего itemprop="address" у дива с itemscope. Ему itemprop не нужен, это не свойство item-а, а его контейнер (грубо говоря, сам item). А так парсер путается, где сам объект, а где чьи свойства. Ну и вместо span class="hr" лично я использовал бы h2:after, но это уже ладно, можно отнести к вкусовщине

Фон — полбеды, его как раз можно «костыльнуть» псевдиком (одним, абс-но позиционированным). У calc() пока еще серьезные проблемы в мобильном царстве...

Теоретически, в новых браузерах можно извернуться как-то так. Практически, я согласен с Комаровым и hypnocolor-ом (и не только): не стоит борьба с этой несчастной оберткой таких контринтуитивных подвыподвертов в стилях. Я бы сказал, что у внешнего контейнера (структурного «строительного блока» страницы) и внутренней обертки (общий контейнер содержащейся там информации) даже есть своя отдельная семантика . Во многих случаях можно заменить внутренний div на section и разграничить визуальную и логическую обертки еще более явно.

Это не форма, а черт-те что. Начиная с закрывающего textarea при открывающем input (!) и заканчивая отсутствием нужных label-ов и отступа двумя br-ками.

В описании tspan в том же MDN написано, что в Gecko (движке Фокса) некоторые презентационные атрибуты не работают. А alignment-baseline как раз относится к презентационным атрибутам. Решение сходу на ум не приходит, надо еще подумать…

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

Нигде в официальной документации по HTML5 не написано и не может быть написано, что перекрытие тегов разрешено. Как не было оно разрешено и в HTML4. Другое дело, что стандарт HTML5 содержит предписания как для авторов (как писать правильно), так и для браузеров (как разбирать любую разметку, в т.ч. устаревшую и явно ошибочную, не падая от нее в обморок). И в разделе для браузеров, да, сказано, как парсить код с перекрытием. Но это не значит, что такой код допустим, и что горе-верстальщиков, допускающих такие косяки в коде, не надо учить канделябром Валидатор проверяет по тому стандарту, по которому ему укажут. По умолчанию — по тому, который указан в доктайпе.

Если это та же проблема, что некликабельность прозрачных элементов без фона, то ее должна фиксить даже фейковая картинка. Раньше я юзал url(about:blank), чтобы не дергать зазря сервер. Но он, бяка, в Хроме гадит в консоль ошибками «не тот тип ресурса», так что пришлось перейти на пустой Data Uri вида url(data:image/png,) — с ним, вроде бы, нигде никаких ошибок, а IEшная магия срабатывает. Чуть позже проверю, работает ли она и для этой проблемы (сейчас с планшета, там нечем.

ЕМНИП, именно в 31-й версии это и пофиксили

Как бы то ни было, это явный баг IE11. По спеке ведь однозначно Хорошо, что есть обходное решение, но вообще мелкомягких надо попинговать, чтоб не расслаблялись. А то ишь, вложенные 3d-трансформы так и не освоили, а туда же — на CSS2.1 забивать

Еще и дата публикации 1 апреля)

Как раз наоборот. Мы можем обратиться к первому по номеру потомку в DOM-дереве, независимо от его параметров, но не можем (пока) обратиться к первому из элементов, удовлетворяющих определенному условию (напр. с определенным классом). Максимум, что есть — возможность считать отдельно разные теги (nth-*-of-type).

Псевдокласс — как класс. .box.lol — элемент, имеющий классы "box" и "lol" одновременно. .box:first-child — элемент, одновременно отвечающий селекторам .box и :first-child, т.е. имеющий класс "box" и при этом являющийся первым потомком родителя. Для разных тегов можно пользоваться :nth-of-type. Для разных классов пока, к сожалению, ничего нет. В CSS Selectors 4 предлагали nth-match, потом вместо него решили расширить nth-child до nth-child(an + b of <селектор>). Но пока, насколькл я в курсе, нигде не поддерживается.

Пишут, что это не тень, а градиентный фон. Соответственно, background-image:none (или сокращение с аналогичным смыслом) должно помочь. В т.ч. если оно есть в ресете

В теории, градиентами можно. Но в IE11 какая-то непонятная бяка (может, только у меня?). Пожалуй, присоединюсь к совету про

3@14.by info@travel.travel Помощники четко идут доучиваться…

Насколько я понимаю, там не с line-height проблема, а с ее распределением над/под базовой линией (метриками ascent/descent). В экспертных настройках белкогенератора есть включенная по умолчанию галка Fix Vertical Metrics, но есть подозрение, что ее недостаточно. Полный контроль над метриками для всех платформ (более-менее) дают редакторы шрифтов типа FontForge.

А если так?

Да. Но только в новых браузерах.

Для transform, судя по всему, тоже пока нужен -webkit-префикс. А вот -moz-radial-gradient давно можно и нужно заменить на беспрефиксный вариант с ключевым словом at.

Судя по всему, кодировка многобайтная (99,9% — utf-8), а обрезка слов с подстановкой «...» делается серверным скриптом (типа php-шной substr) не по символам, а по байтам. Получается, что последний символ слова бьется и от него остается огрызок, не имеющий смысла в utf-8. Надо посмотреть, чем сделана обрезка, и переделать на что-то совместимое с многобайтной кодировкой (напр. mb_substr), а то и вовсе убрать и сделать text-overflow: ellipsis в CSS.