SelenIT

"Слушаюсь и повинуюсь!" — подобно сказочному джинну, откликнулся могучий Консорциум...

Ну, по быстроте JS (как минимум, по Санспайдеру) FF4 тоже на некоторых поворотах заметно обходит Хромого, а это уже для пользователей важнее

Мне ситуация напоминает древний народный анекдот про попа-чревоугодника и пост ("Господи, сделай чудо — преврати порося в карася..."). Для старой доброй таблицы взяли и придумали "волшебный" атрибут (правда, типа модный), с которым старая добрая табличная верстка макетов из гадкой и недостойной автоматически превращается в белую, пушистую и вроде как даже семантичную (как-никак, обозначена роль элемента, это почти что ARIA, а это модно и семантично по определению). В данном случае они лишь транслировали новость, "отморозили" ее как раз W3C.

http://blog.whatwg.org/weekly-layout-table Ыыыыы... какая няшная прелесть И за что, спрашивается, боролись полтора десятка лет?...

По моим наблюдениям, Вебкиты местами повторяют IE 90-х — подхватывают некие красивости, уже так или иначе работающие на исконной платформе (в данном случае Маке) и обзывают их "экспериментальными расширениями" стандарта. Так, насколько я понимаю, было с <input type="search">, примерно так начинались CSS-трансформации и анимации (правда, их по-быстрому, не иначе как по блату, пропихнули-таки в спеку-скороспелку), так "без спросу" добавили background-clip:text и еще что-то. Возможно, я неправ, но вот такое впечатление складывается. А с паровозом, да, забавная ситуация сложилась — укладку рельсов фактически возложили на пассажиров, ответственность за их неправильную укладку — тоже, естественно, камикадзей мало, а паровоз стоит себе. Кто похитрее, давно забили на него и потихоньку едут параллельным курсом на асфальтовом катке, запряженном коровами (WHATWG с их принципом "pave the cowpaths")...

Имхо, 1) необходимость для разработчика быть "слугой n (n?2) господ", держа в уме все нюансы и различия; 2) необходимость некоторое время параллельно поддерживать старое барахло с префиксом и новое как-бы-не-барахло без оного, частенько сильно различные (Мозилла не раз на это напарывалась), что опять же запутывает разработчиков; 3) вендорные префиксы как механизм предусмотрены только в CSS, ни в разметке, ни в скриптинге они не помогут. А так лучше, конечно, чем ничего . Особенно с учетом нынешнего дедлока "не реализуем, пока спека не дозреет" — "не апгрейдим спеку, пока нет реализаций"...

Справедливости ради, у куска "живой спеки" конкретно про video статус "Last call for comments" (даже тесты кое-какие уже имеются). Хотя к ней W3Cшные статусы, наверное, вообще уже не подходят... <sarcasm> Эта? </sarcasm>

На той страничке изменений, увы, не наблюдаю. Посоветовать также ничего не могу — в SVG я, к сожалению, пока вообще абсолютный профан... А вот на демке с кнопками нашел глюк, сильно похожий на описываемый. Правда, корреляции с текстом тоже не заметно, но факт, что внутренний <rect> со скругленными углами не растягивается на заявленные 100% ширины, а растягивается на какое-то своё значение (разное у разных кнопок). Еще бредовая мысль возникла (как безумная гипотеза для объяснения межхостинговых различий): с какими mime-типами отдаются svg-файлы в каждом случае?

Ой ли... Как и на основании чего можно было, например, предсказать такое (из совсем свежего)? Насколько я понял, это "последняя инстанция" в цепочке "вынесения приговора", как страничку рисовать. Перебивает всё, что могло влиять на режим до этого (X-UA-Compatible, настройки интранета и дефолтное поведение текущего "режима браузера") и "обжалованию" уже не подлежит...

По http://blogs.msdn.com/b/ie/archive/2010/10/19/testing-sites-with-browser-mode-vs-doc-mode.aspx:

Вау, и действительно — даже не верится, что всё настолько просто. Громадное спасибо за удаление каши из головы!

Смог поймать глюк при изменении масштаба страницы от дефолтных 100%. Текст, похоже, ни при чем, картинка просто смещается (при уменьшении масштаба) и не растягивается в ширину (при увеличении). Интересно, а если убрать 100%-ные размеры с корневого элемента — будет хуже?

Хм, только что проверил — у меня вот в этом примере SVG-фоны работают только при режиме документа IE9 (независимо от режима браузера). Какая-никакая кривоватая логика в этом даже есть — SVG-шки ведь отдельные документы, видимо, режим документа они наследуют от основной страницы, а режим браузера — нет. Но в целом, согласен, поведение настолько запутано, что можно считать багом и писать жалобу в коннект... UPD: я идиот, убейте меня кто-нибудь. Всё гораздо проще — это документированное поведение Document mode, за фактический режим отвечает именно он.

Я глюка вообще так и не видел. Вероятно, опоздал к его раздаче, попал на уже пофикшенную версию...

Минуточку, кого именно в режим — документа или браузера?

А эти связи "реальный id товара + вид оплаты — фиктивный id товара" где хранятся? Только в уме разработчика или где-то в базе? Если в базе — почему бы не доставать их в обработчике и не заменять пришедший из формы id товара соответствующим фиктивным в этом же обработчике, перед генерацией писем, инструкций и прочего зависимого добра? По крайней мере, не будем зависеть от наличия JS у клиента...

Имхо, переколбашивать функциональные DOM-атрибуты ради минутной визуальной красоты — извращение всяко не меньшее. Лично я в таких случаях обычно накладывал прозрачный input на его label, а во время набора и при непустом значении делал input непрозрачным. Конечно, все способы, кроме нативного плейсхолдера, в той или иной мере кривые, но, имхо, те, что обходятся изменением стилей, чуть-чуть прямее других...

zula, а логику обработки этой формы вы сами писали или подстраиваетесь под чужую? Если сами, то, имхо, что-то странное в постановке задачи, по-моему, вы усложняете себе жизнь. По банальному здравому смыслу, не должен id товара зависеть от способа оплаты, а любую специфичную инфу для их комбинации можно вытянуть из базы по составному ключу...

Баг валидатора, что поделаешь. Если знаете Яву, можете попробовать сами пофиксить...

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

Под виндой (что XP, что 7) воспроизвести не удалось. Может, экзотический глюк кеша или что-то в таком роде?

Сорри, какой-какой спецификации? В CSS 2.x, как справедливо отмечено выше, такой сущности, как "фоновый градиент", нет. А вот сущность "фоновая картинка из внешнего ресурса" есть, причем, по-моему, не уточняется, что картинка обязана быть растровой. Ergo... Кстати, FF4 тоже умеет фоновый SVG. Опера давно умеет, Хром тоже научился... кто там остался? Несчастные MS-овцы исключительно ради этого принципа заморозили в IE9 аж 3 архаичных движка со всем соотв. синтаксисом и глюками, нагородив стопицотэтажную схему переключения между их аж 7-ю режимами... а вам всё мало?

<trolling>неужели Internet Explorer? o_0</trolling>

А пустые головы совсем без никакого контента засчитываются?

Это для картинки внутри элемента списка, на который наведена мышка. Не знаю, что еще посоветовать... разве что попробовать явно задать для соотв. картинки background-color:transparent (возможно, она наследует откуда-то цвет фона текста и красит белым область, отведенную для alt). Но вообще, разве "картинка без изображения" — не аварийная ситуация, в которой по определению что-то будет выглядеть странно? С нормальной полноценной картинкой с заданными размерами тот же глюк? Так я и в старой учетке не нахожу файл-менеджера, хотя давно закачанные файлы в ней показываются...