SelenIT

В примере с Хабры, к сожалению, выделение под градиентом в IE работает по принципу "всё или ничего", выделить пару слов таки нельзя. У IE когда-то была особенность, что полностью прозрачные элементы становились прозрачными и для событий (как минимум, это было справедливо для флешек с wmode=transparent и, по-моему, для png-шек, наложенных с помощью AlphaImageLoader-а), но с обычными блоками, по-моему, нужных чудес там не происходит...

Ух ты! Про pointer-events я вообще как-то пропустил, был даже не в курсе существования такой клёвой штуки... Огромное спасибо за новое полезное знание!

Кстати, да, MathML — вообще правильный подход для этого дела. К тому же HTML5 разрешает внедрение MathML прямо в HTML (с типом text/html!), такой вариант должен работать в FF4+, Хроме 7+, и, судя по всему, Опере 12+. А для IE9 можно допилить привычным методом навроде такого...

И вправду работает. Теперь уже я прошу пояснений, за счет чего это так? Благодаря отрицательным маргинам, что ли?

Имхо, сильный минус такого подхода — невыделяемость текста под градиентом. Возможно, есть смысл поковырять скриптовые варианты (вот мой навскидку, подозреваю, что жутко неоптимальный).

Да, это другое. Абсолютно позиционированные потомки отсчитываются от этого элемента (п. 10.1 спеки), но нового контекста форматирования обычных, не позиционированных блоков (в т.ч. плавающих) в нем не создается, и float-ы по-прежнему из него "вываливаются".

С absolute — да, с relative — нет. Случаи, когда создается новый контекст форматирования блоков, перечислены в п. 9.4.1 спеки:

Там UL-ка сама плавающая, это создает отдельный контекст форматирования. Из контекста float-ы вырваться уже не могут, он поневоле охватывает их. Такой же эффект дает overflow: hidden/auto (часто используемый для борьбы с "вываливанием float-ов") и display:inline-block/table/table-cell.

Лишки плавающие, а значит, выпавшие из потока, а значит, не влияющие на высоту предка. А других потомков у уэлки нет...

Полагаю, потому что она хотела быть впереди планеты всей и решила поддержать экспериментальный черновик CSS3 (застывший в 2003-м), где свойство content было допустимым для всех элементов. А сказав "А" (разрешив пустым элементам иметь контент, пусть и генерируемый), пришлось говорить и "Б" (разрешать вставлять перед/после этого контента еще что-нибудь). P.S. По сабжевой проблеме — когда-то что-то слышал, что Опера впридачу к SVG-фонам умела применять к ним SVG-эффекты, в частности маску. Теоретически, могло бы помочь. Но рабочей хотя бы демки этой фичи я что-то сходу не нагуглил...

Кстати, в HTML5 name у форм есть. Но в основном тоже для совместимости (document.forms).

Смотрим: <!ATTLIST form %attrs; action %URI; #REQUIRED method (get|post) "get" enctype %ContentType; "application/x-www-form-urlencoded" onsubmit %Script; #IMPLIED onreset %Script; #IMPLIED accept %ContentTypes; #IMPLIED accept-charset %Charsets; #IMPLIED > %attrs; расшифровывается в это (идем по ссылке): <!ENTITY % attrs "%coreattrs; %i18n; %events;"> где % coreattrs — это <!ENTITY % coreattrs "id ID #IMPLIED class CDATA #IMPLIED style %StyleSheet; #IMPLIED title %Text; #IMPLIED" > Как видно, никакого нейма нет. В атрибутах локализации и скриптовых событий его нет и подавно. Даже в HTML4, чьей переформулировкой в XML является XHTML 1.0, про name для форм написано следующее: А так ли нужен этот name на самом деле?..

Почему бы не вызвать parent.location = "..." из дающего добро обработчика?

Он не ругается на кавычку Прочитать, на что именно он ругается; Открыть указанный в доктайпе DTD (или спеку соотв. языка) и посмотреть, какие атрибуты допустимы для тега form; Привести в соответствие (либо убрать запрещенный атрибут, либо сменить доктайп на тот, где он разрешен).

Попробуйте потестить мой вариант там в комментах . За ближайшие выходные постараюсь его еще допилить (уже представляю как)...

Судя по текущим спекам CSS3 Selectors (с прошлого месяца в статусе рекомендации!): и W3C HTML5: я полагаю, что да — в ближайших несколько лет псевдоэлементы для картинок поддерживаться не будут...

Псевдоэлементы применяются к элементам, у которых может быть контент (перед и после него соотв-но). <img> — пустой элемент, контента не имеет по определению, поэтому псевдоэлементов у него быть не должно (и нигде нет). Но Опера позволяет менять контент у всего (через св-во content), в т.ч. у <img>, поэтому в ней у <img> контент может появиться, а значит, и псевдоэлементы для него имеют право на существование — и потому отображаются. Я так это понимаю. Кстати, благодаря этой оперной особенности задачу можно решить еще и как-то так. Да, через бякграунды, но (только что проверил) Open Image/Save Image в браузерном меню работают...

Что за CMS?

Кнопка инлайн-блочная, ссылка инлайновая? Скорее всего, ограничение минимальной высоты line-height'ом сработало и не дало скукожить общую высоту меньше (дополнительные пиксели высоты визуально наложились на паддинг). А line-height мог быть разный из-за разного дефолтного масштаба, например.

Формально без разницы, но с ними как-то аккуратнее.

Что за браузер такое позволяет? Опера? parent-а там, по идее, вообще быть не должно, это же не фреймы...

Т.е. window.open создает сначала пустое окно, а потом, в результате отправки формы, в него загружается новый контент? Видимо, в момент этой загрузки св-во opener и теряется. А заменить открытие дочернего окна на какой-нибудь lightbox с iframe-ом внутри — не выход?

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

А в попапе случайно не сабмит формы происходит? Ссылка на opener живет только до перезагрузки страницы. Как вариант, сабмитить форму в невидимый iframe или еще куда-нибудь кроме самого окна, тогда ссылка выживет...

Если ничего не путаю, энтер по дефолту сабмитит только форму с единственным полем (по крайней мере, в HTML2 было так), а тут оно как бы не единственное...