SelenIT

Это самый популярный (хотя не единственный) способ заставить родительский блок создавать отдельный блочный контекст форматирования. Что убивает двух зайцев — не дает float-ам вываливаться из этого контейнера наружу (по умолчанию они проходят сквозь границы блоков) и не дает им «цепляться» за float-ы, лежащие снаружи, при использовании clear (как происходит здесь, если кликнуть по зеленому сайдбару). Оборотная сторона — проблемы, если надо всё-таки вынести элемент из такого блока наружу.

http://phpfaq.ru/paths

Полагаю, дело в асинхронности очереди событий в JS. К моменту навешивания обработчика события еще как бы «висят в очереди», а значение #hash уже окончательное. Оно и логируется для каждого события. Если навесить обработчик по таймауту (даже с нулевой задержкой), странность исчезает.

display: table/table-cell (+, возможно, table-layout:fixed)?

Можно так еще: http://jsfiddle.net/kBgRH/3/

Это я не всё лишнее удалил из вашего изначального примера (он, кстати, в Fx и не работал). Зачем позиционировать отдельный слой, что мешает задать фон и border-radius самой ячейке?

Я имел в виду, что если он уже используется для IE8, то можно "свести задачу к уже решенной" для IE8, обойдя проблему IE9 с высотой элемента, позиционированного в ячейке. Но скорее тут, действительно, можно обойтись без таких извратов... и вообще позиционирования. Нет?

Есть такая фигня, именно в IE9 (см. "Ложка дёгтя" в конце http://css-live.ru/articles-css/absolyutnoe-pozicionirovanie-v-yachejkax-tablicy-v-firefox.html). Лекарства пока сам не знаю. Если используются костыли для IE8- типа PIE, в качестве очень кривого и скользкого обходного пути можно попробовать сбросить IE9 в режим IE8 через соотв. meta X-UA-Compatible.

Дисклеймер: у меня та же фигня, что у Great Rash и wwt. Но на правах безумной идеи: если "внедорожность" нужна изредка и "чтоб не угоняли" — может, есть смысл подумать, напр., о победителе этого рейтинга в качестве не замены, но дополнения?)

http://stackoverflow.com/questions/14301935/where-has-fn-toggle-handlereventobject-handlereventobject-gone ?

Может, проще карту иначе отцентрировать?

Как табличный. В теории — чисто визуально (т.е. скринридеры не должны читать их, повторяя названия колонок перед каждым значением, хотя бывают исключения). И табличных DOM-свойств, типа коллекции rows и новомодной нативной сортировки, у элемента не появится (по идее, это очевидно). Больше того — банальные rowspan/colspan CSS-ом не воспроизвести (пока?). Еще тонкий нюанс (закрепленный в спецификации) — для <table>, по историческим причинам, по умолчанию применяется модель border-box, а для произвольного элемента с display:table — content-box. Но в реальности у браузеров (как минимум, Хрома) с этим бывала путаница.

С line-height поколдуйте...

В IE10 (Win 7 Pro x64) у меня ничего не падает (ни пример из Ксакепа, ни предыдущий). И при экспериментах с круглыми аватарками (с border-radius на половину размера и больше) в IE9 не разу не сталкивался. Действительно загадочное что-то

Вопрос — нужен ли при таком подходе вообще HTML А если серьезно, то навскидку как минимум одна проблема — такие заголовки нельзя скопировать (в Fx и вебкитах).

А всё-таки, кто/что запрещает обернуть оба внутренних блока одной ссылкой?

К сожалению, отрисовка вложенных флоатов - слабое место браузеров. Можно оставить float для самих блоков , а внутри располагать картинку и текст с помощью inline-block или table-cell.

Вообще-то именно это и написано. Запись означает буквально «задать всем select-ам внутри #table_small, всем input-ам, всем textarea и всем загадочным submit (кстати, что это и откуда?) 10-пиксельный размер шрифта».

Главная проблема в таком размещении — состыковать обе половинки обтекания по высоте. Проще всего поставить их в самом начале блоков, а перед ними добавить "толкалки" нулевой ширины (http://jsfiddle.net/ZQ8JF/).

Документация к плагину говорит, что для объединения картинок в серию нужно задать ссылкам общий класс с подчеркиванием:

У меня главная проблема была даже не с размерами как таковыми (посколько кроссбраузерность не нужна), а с координатами копируемой области. Виноват, не сразу смог сформулировать (поначалу меня эта проблема вообще запутала). Но всё равно спасибо! Есть надежда, что решить проблему сможет этот скрипт (отрабатывает на удивление шустро, правда, на десктопе и увы, не без глюков иногда). Завтра проверю на мобильных дивайсах...

В транке вебкита-то, может, и пофиксили, но в актуальной сборке iOS, судя по опыту, нет... У меня SVG-шка вставляется обычным <img>, и сами размеры из атрибутов width/height корректно считываются через img.naturalWidth/img.naturalHeight. Проблема в том, что реальные пиксели, которые drawImage запихивает в canvas, этим размерам не соответствуют. И получается, что до 3/4 площади картинки через drawImage вообще никак не достучаться: координаты в пределах размеров картинки соответсвуют реальным пикселям левой верхней ее четверти, а попытка обратиться к координатам за пределами вызывает ошибку. В общем, придется пока отказаться от SVGшек в этой задаче. Я бы бросил затею раньше, если бы не обнадеживающий эксперимент в отдельной странице, но в phonegap-приложении, к сожалению, этот финт не прошел... GreatRash, большое спасибо за отклик!

Поздравляю!

Видимо, баг вебкита. Но в отдельной странице ведь пинок картинки помогал... Должен же быть универсальный воркэраунд, даже для IE6 удавалось его найти!