SelenIT

По-моему, понимает. Другое дело, что все IE (как минимум, по 10-й включительно) требуют явного overflow:visible для button, если надо "высунуть" что-либо за его границы. Ну и с z-index'ами в 8-м всё плоховато, да...

Только псевдоэлементов И у button они есть.

Как вариант, можно подложить под текст кнопки абсолютно позиционированный ::before, и применить трансформацию к нему. Модуля для произвольных форм в CSS пока, насколько мне известно, нет (CSS Shapes — это не про рисование форм, а про заполнение текстом произвольных контуров, да и его поддержка пока только экспериментальная).

Не страшно. Вообще экранирование — просто добавление обратного слеша перед символом. Например, если в имени файла а-ля 'image(2).jpg' есть скобки, то без кавычек придется писать или так: url(/image\(2\).jpg), или с кавычками: url('/image(2).jpg'). Иначе вторая скобка будет воспринята как закрывющая от url(). Если таких символов в путях нет, без кавычек можно смело обойтись.

1) Разницы практически нет. Разве что без кавычек нужно экранировать спецсимволы в файловых путях (пробелы, скобки, сами кавычки и т.п.). 2) Так делают, если файл был изменен, чтобы браузеры загрузили его заново, а не использовали старую закешированную версию. После каждого изменения файла цифры обновляют.

Это фича встроенного браузера Андроидов (по слухам, и некоторых других мобильных). Для того, чтобы при увеличении сайта для комфортного чтения текста он вмещался в экран хотя бы по ширине и скроллить его приходилось лишь по одной оси, а не зигзагом. Как по мне, очень удобная для пользователя.

С наступающим!

До недавнего времени не понимал, но, видимо, вот-вот начнет.

Видимо, минус 10 миллионов пикселей. В смысле, очень-очень много. Чтоб наверняка скрыло, сколько текста бы ни было Использовать такое, конечно, нет смысла. Особенно для ссылок.

А давно colspan валидации мешает?

Абзацы следуют после <p>. После <br> следуют строки (относящиеся к тому же самому абзацу). Всё работает, как надо.

P, LI, DT, DD, TD, TH, RT, RP. Если не считать других тегов в промежутках, то еще TBODY. Но «внутренний» тег на самом деле будет открывающим для последнего закрывающего (и неявным закрытием первого).

Ну если считать слово «пиво» модифицированным в 4-х местах словом «хлеб»…

Не знаю тонкостей, но на беглый взгляд в https://github.com/mozilla/gecko-dev/tree/master/parser HTML- и XML-парсеры лежат даже в разных поддиректориях. Алгоритм первого описан в отдельном разделе спецификации. К тому же XML-парсер работает до первой ошибки, а в алгоритме HTML-парсера зашита обработка и ошибочных ситуаций…

Если тег может быть в варианте как с, так и без закрывающего — значит, это не пустой элемент и речь идет об опциональном закрывающем теге. Для всех элементов, для которых закрывающий тег опционален, новый открывающий тег неявно закрывает предыдущий. Поэтому приведенная запись в валидном HTML возможна, но означать она будет не «элемент внутри элемента», а «два элемента рядом». Это не совсем верно. Парсинг при text/html и XML-парсинг различаются очень существенно.

Да, к сожалению, там в тексте ошибка. Вместо font-size там должно быть «высота текста» (высота кегельных площадок). Приношу извинения за мою оплошность при подготовке публикации и спасибо за внимательность!

Высота строки (которая line-height и которая определяет высоту ее блочного контейнера) складвается из высоты кегельных площадок символов (она задается метриками шрифта, обычно бывает дробной типа 1.227, и может по-разному округляться в разных браузерах — вот ответ на п.3) и вертикального межстрочного пробела («leading»). В данном случае «leading» отрицательный, поэтому итоговая высота строки меньше высоты площадок символов. А высота инлайн-элемента определяется только высотой текста, поэтому она и «выпирает» за рамки уменьшенного line-height (ответ на п.2). Инлайн-блок же сам внутри представляет собой блочный контейнер, поэтому его высота ограничена line-height'ом его содержимого, а он наследуется от внешнего родителя (ответ на п.1).

Имхо, не должна. Какое, казалось бы, парсеру поисковика дело до разметки других страниц?

Зачем тестить, когда можно прочитать?Редактор W3C-шной версии спеки почему-то лично «вызверен» на этот несчастный алгоритм HTML5 Document Outline и при каждом удобном-неудобном случае яро агитирует за традиционную структуру заголовков (с одним главным H1). В чем ему регулярно поддакивает не менее известный гуру Роджер Йоханссон. Пока с другой стороны баррикад нет сопоставимых по авторитетности подач, я склонен соглашаться с ними. А для главной блога чем название блога не кандидат в H1? То, что страницу со множеством H1 из индексации не выкидывает совсем, еще не гарантирует высокой позиции в выдаче, а по крайней мере 3 года назад множественные H1 рассматривались как не очень страшная, но всё же SEO-ошибка.

Так а с какого испуга ему быть белым? «Козырный» inherit придает цвет родителя (body, который #333), вроде всё верно…

Его можно переписать в виде filter (без кавычек) и объединить с другим filter-ом. На практике -ms- обычно не нужен.

В примере из топика стоит inherit !important, так что срабатывает.

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

Когда "ранее"? В примере он как раз наследуется при :hover (от родителя, как всегда), а без hover-а явно задан. Возврат к немодифицированному :hover-ом состоянию — не наследование, отношения родитель-потомок там нет. Хотя то, что возможности явно сослаться на это состояние в CSS до сих пор нет (даже с нововведениями типа default и initial) часто действительно бывает обидно…

У body? Пардон, где? В bootstrap.min.css вижу для body color:#333;, это же видно у кнопки при наведении...