SelenIT

Запомнить выехавший див в переменной, по клику на кнопку скрыть див из переменной, дать выехать новому и запомнить в ней уже его?

Насколько я понимаю, именно так: навроде того, как они раскидывают по неймспейсам SVG- и MathML-элементы в HTML-сериализации (словарь HTML5 зашит в самом алгоритме парсинга). А у WAI-ARIA, если я правильно понимаю их спеку, тоже есть более-менее четкий словарь...

Судя по "базовым принципам", задача ставилась скорее обратная — по-максимуму разнести семантику и оформление по разным, условно говоря, слоям разметки

У меня сложилось впечатление, что ARIA — это больше про доступность, преимущественно для веб-интерфейсов, и с RDFa они не сколько конкурируют, сколько друг друга дополняют. Ну и возможность явно указать для ссылки, что она является табом, пунктом меню или элементом дерева (role="tab/menuitem/treeitem" соотв-но), имхо, абстрактно радует. Но на практике применить пока, увы, не довелось...

Оно (IE6-7 - автоматом)?

Как минимум, есть MariaDB, и не она одна. Открытый код не задушишь, не убьешь!

Полностью согласен с "Базовыми принципами..." и "Последним словом" (по крайней мере, как я это понимаю на текущий момент). Есть сомнения насчет figure c заголовками "просто для того, чтоб они не попали в outline" — всё-таки основная задача figure не в этом, а в "инкапсуляции" иллюстрации (или чего-то подобного) с подписью (которая figcaption), здесь я такой функции не вижу. И насчет <menu> — насколько я понимаю, формально валидацию-то оно проходит, про недоподдержку — это лишь warning. А пример, имхо, удачный!

preg_replace_callback?

vertical-align: top/bottom/middle(лишь бы не дефолтный baseline)?

У каждого свои плюсы и минусы. Инлайн-блоки могут быть произвольной высоты, их можно выравнивать в строке как угодно (по верху, по центру, по низу), их легко центрировать, они не выпадают из потока и не требуют после себя clear'инга. Зато для них значимы пробелы между тегами (обычно это мешает, приходится либо убирать пробелы в коде, либо городить отрицательные маргины и/или word-spacing'и, либо - имхо самая неудачная идея - обнулять font-size контейнеру и заново ставить потомкам), а также требуется хак для старых IE (inline + hasLayout). Float-ы работают во всех браузерах (в IE6 капризничают, но на эти капризы есть проверенные и простые "затычки"), безразличны к пробелам в коде, зато выпадают из потока (требуют clearfix'а или overflow:hidden для контейнера), обязательно прижимаются к правому или левому краю, по вертикали выравниваются только по верхнему краю, а в несколько строк корректно размещаются только при условии равной высоты. Как по мне, инлайн-блоки чуть погибче. Но всё равно нужно смотреть по конкретной задаче. Ну и для полноты картины можно вспомнить про третью альтернативу в лице display:table/table-cell

А зачем регулярка? Просто split'нуть строку по слешу в качестве разделителя недостаточно?

Это не только Хром (всех версий), это все браузеры в стандартном режиме (при правильном доктайпе) так себя ведут. "Исправлять" бессмысленно, нужно просто учитывать (напр., ставить height: 198px, если нужна итоговая 200).

Понятно, значит, вторая кнопка к блокировке ни при чем. Ну а вариант с отдельной переменной-флагом чем плох?

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

А почему бы просто не воспользоваться той же самой проверкой видимости кнопки про корзину (if (document.getElementById('GotoBasket').style.display == "none") {...) при вызове ф-ции добавления?

Ну или так (с)

Зачем white-space:nowrap? Из-за него всё содержимое с display:inline(-xxx) и оказывается "сковано одной цепью" в единую неделимую строку. Плюс докинуть хотя бы 4-5 пикселей ширины контейнеру, чтоб влезли межсловные пробелы. Хотя здесь лично я бы, пожалуй, сделал по-старинке float-ами...

Так уж сложилось в стандарте. Повлиять можно только в новых браузерах с помощью box-sizing: border-box (CSS3). В какой-то мере и в старых IE путем сброса в quirks mode (напр. комментарий перед доктайпом)... но это из разряда лечения перхоти гильотиной . В сабжевой задаче, имхо, самое надежное и логичное — display:table контейнеру и table-cell пунктам. А IE7- (чтоб их уже...) подпереть скриптовым костылем...

Имхо, "Занятно, что :first-child поддерживался еще IE7, но до выхода IE9 это ("ослиное" семейство — прим. моё) — не то место, где поддерживаются остальные вышеперечисленные классные штуки". Или, более по-русски и по-простому, "Занятно, что :first-child работал уже в IE7, но вот всё остальное из перечисленного начало поддерживаться в IEшках только с 9-ки". По сути всё было правильно mishka, что, вправду? IE9 в режиме эмуляции прошел лишь 2 субтеста из семи...

Тут, насколько я понимаю, проблема не в браузерах, а в шрифтах — не на каждой машине дефолтный шрифт держит полный набор нужных символов. Впрочем, для верстки HTML-писем, действительно, лучше не извращаться и писать вообще плейнтекстом ("адрес", "тел." и т.п.). Там главная проблема даже не в браузерах, а в веб-интерфейсах типа mail.ru, которые вообще делают черт-те что со стилями, поэтому чем проще — тем предсказуемее и надежнее.

В canvas прямая дорога, имхо...

Неужели совсем никакой возможности свои стили картинкам приписать? Хоть <style> в <body> затолкать, на самый-самый крайний случай, если больше совсем уж ничего не остается...

Файрбаг 31 и показывает. То, что визуально между строчками больше — за счет line-height'а и отступа базовой линии текста.

Чудес не бывает, где-то путь расходится с действительностью. Открываете через http или локальным файлом?

От IE8 никуда не деться, потому что это последний IE для XP, а XP будет жить еще 3 года только официально. Но 7-ку с ее 5% (а тем более 6-ку с 2%) вполне можно подпереть костылями типа PIE или IE9.js Дина Эдвардса (недавно вспоминали в какой-то теме) и на том успокоиться, а если вдруг что — "ну так что ж вы хотели от доисторического браузера, на него уже сам MS забил". Блоки не разваливаются, ссылки кликаются, формы работают — и на том спасибо... Имхо.