SelenIT

Сегодня я внезапно обнаружил, что Хром теперь тоже поддерживает content и псевдоэлементы для <img>. Ох, что-то начинается...

Прогресс на самом деле офигенный, но преимущественно в гламурненьких UI/свистелках-трещотках/объемных тенюшках и всякой прочей вау-интерактивности типа клиентской валидации. А базовые протоколы и низкоуровневые интерфейсы, с их принципиальными ограничениями и глюками обратной совместимости, всё те же. Впрочем, в вебе аналогично...

Все спеки W3C лежат в http://www.w3.org/TR/ (от "technical reports", емнип). Там можно клацнуть по нужной технологии и откроется всё, что актуально есть по ней на данный момент (напр. для CSS: http://www.w3.org/TR/#tr_CSS). То, что в статусе Group Note — отмершие ветви, живость остального можно примерно определить на глаз по соотношению текущего статуса (шкала такая: Working Draft ? Last Call Working Draft ? Candidate Recommendation ? Proposed Recommendation ? Recommedation) и даты последнего обновления. А версий у CSS теперь нет, есть "уровни" для каждого модуля (напр. модуль селекторов уже "прокачался" до 3-го уровня и сейчас "качает" 4-й, в то время как остальные довольствуются третьим или даже вторым). HTML5 живет параллельно на W3C (http://www.w3.org/TR/html5/, для веб-разработчиков актуальнее эта версия) и у WHAT WG (http://www.whatwg.org/specs/web-apps/current-work/multipage/ — как "живой стандарт HTML без версий"). Теоретически WHAT WG-шная версия ближе к жизни (т.к. WHAT WG состоит, грубо, из разработчиков браузеров), но т.к. обе линии разработки курирует один и тот же Ян Хиксон, различия вряд ли будут радикальными Новые браузеры воспринимают любой (X)HTML как HTML5, поэтому можно считать, что он вобрал в себя и "переварил" все предшествующие наработки по (X)HTML.

Так вы два раза назначаете filter, затирая первый. Плюс в IE9 фильтры плохо дружат с нативной прозрачностью. Вот как-то так не решает? Правда, старый IEшный баг с рендерингом шрифтов с фильтрами без фона вылез...

Если ничего не путаю, еще для Хрома — предлагать или нет иноязычным юзерам перевести страницу на их язык автоматически. В любом случае вреда не видно, а польза вероятна

Сурово Тогда можно поковырять в сторону известного способа центрирования position: absolute; left: 50%; margin-left: -640px... возможно, даже пожертвовав ограниченной резиной (всё равно диапазон у нее несерьезный). Или ступенчато менять этот маргин через @media queries. Больше сходу идей нет...

По ходу дела, баг в консоли Хрома (в Опере пока не смотрел, в IE9 вроде адекватно). Хром, видимо, фигачит в консоль честную ссылку на объект — и естественно, после отпускания мышки (а иначе запись в консоли не раскрыть) там уже обновленное значение с false. Вот в таком варианте если раскрыть object сразу — таким он и останется, а если сначала кликнуть другой див и раскрыть оба object-а — они будут одинаковыми...

Если на JSfiddle, то надо было выбирать слева "no wrap (head)", иначе оно в еще один $(window).load(function(){ ... } оборачивает, что сильно меняет момент инциализации... Но вот теперь объясните мне, полному тупице: почему для обработчиков мышки этот state действительно становится глобальным? Потому что у них общий activation object и этот state живет в его контексте?

Не вдавался в детали, но вроде помогает margin-bottom: -556px для .bgB1. Но вообще зачем так сложно? Почему бы просто не положить оба фона на два вложенных контейнера (хоть те же html и body)?

Горький факт: специального механизма для раскладки макетов в CSS на сегодняшний день тупо нет. Всё, что есть — хаки разной степени извра неочевидности. Флоаты в том числе... и таблицы в том числе тоже. Валидность и семантика — вообще вещи слабо связанные, таблицы для каркаса формально валидности не нарушают (а с rel="presentation" — вроде как и вообще не так страшны). "Валидно и семантично" — конечно, идеал, к которому надо стремиться, но без компромиссов на сегодня не получается. Впрочем, семантичная верстка обычно выходит валидной по построению, обратное неверно . XHTML тем более слабо связан с валидностью, еще слабее — с семантикой и практически никак — с реальностью (увы). А по вопросу — как вариант, спозиционировать шапку и подвал абсолютно поверх колонок с min-height: 100%, а содержимое колонок отпихнуть на столько же пикселей (благо высота фиксирована) паддингом обертки (либо box-sizing: border-box, а для старых IE — expression)...

display: inline-block для span?

Для айпада/айфона можно включить принудительное масштабирование. А для узких десктопов — как вы себе представляете "центрирование" блока минимальной шириной 1280px в окне шириной, например, 1024 со скроллбаром (нетбук)?

Для IE (полагаю, любых) — через всё тот же фильтр

Есть вариант со скриптом через Canvas, имхо, поддержка у него чуть пошире, чем у SVG-фильтров. В частности, есть вот такой JQ-плагин. Более стандартного, боюсь, пока не сделали...

Единственное, взяли меня тут сомнения по поводу IE10 (у меня под рукой пока нет, а он, по слухам, поддерживает и writing-mode, и колонки). Думаю, в боевых условиях добавку для IE8-9 (writing-mode и word-spacing для компенсации пробелов между инлайн-блоками, которые тут оказываются вертикальными) надо вынести в условные комменты. Но вообще, по-моему, вполне совместимое с жизнью решение вышло

Я имел в виду, что если изменится ширина блока, то и множитель в nth-child придется менять соотв-но, иначе будет так. А значит, для "неизвестного кол-ва блоков в строке" способ уже не подходит. Хотя идея с инлайн-блоками и псевдоэлементом для первого блока следующей строки мне очень понравилась, красивее моей идеи с отменой float для последнего в ряду! Вроде даже ее еще чуть упростить можно...

Вау! Кажись, методом научного бубна и в IE7 получилось! Заодно разночтения между браузерами худо-бедно убрал...

Softlink, в этом решении всё равно привязка к 4-м элементам в строке стоит изменить ширину, скажем, на 20% (5 в строке) — уже получается некузяво...

Ну тогда ничего лучше parentNode.replaceChild(), по-моему, и не придумать особо

Решение-то логичное (хотя, наверное, по-хорощему надо бы и потомков заменяемого в заменителя циклом перебросить?), задача странная... Оп-паньки, а это уже интересно. Что в этом object-е — уж не сторонняя ли HTML-страница?

Для неизвестного кол-ва вот сходу красивого решения не придумывается, к сожалению...

Типа такого, если IE8+ и новые. В IE7 у меня вышло только задом наперед...

Для современных браузеров несложно (да и для неравной высоты ненамного сложнее). Но для старых, видимо, придется каждому 4-му блоку задать класс (это-то в шаблоне прописать, думаю, можно)...

Я бы и с рукой не понял. А если я хочу изменить адрес в этом поле, раз уж оно выглядит как поле ввода? Какое-то аццкое издевательство над юзабилити. Что это вообще за интерфейс, в котором возникла такая противоестественная задача? Не говоря о том, что пихать в ссылку любые другие интерактивные элементы запрещает Женевская конвен любая спека *HTML (т.к. требование по клику перейти куда-то, но при этом иметь возможность редактировать что-то по старому адресу - строго взаимоисключающие параграфы)... P.S. cursor:hand - анахронизм времен IE4-5, и нигде кроме этих музейных экспонатов работать не обязан, пора бы о нем забыть.

Поздравляю!