SelenIT

Мой пример не учитывал IE7-, они не понимают псевдоэлемента :before. Если IE7- нужны, придется заменить :before на пустой спан в начале (либо добавить его скриптом/одноразовым экспрешном). В моем примере у розового блока опасити нет Но даже если сделать с ней — контента там не будет...

??? Верно ли я понимаю, что в ископаемом ослике скрипту придется замостить всю плашку сотнями тысяч однопиксельных VML-квадратиков? В принципе, IE5.5-8 понимает rgba (точнее, argb) через фильтр градиента (вроде как еще через какие-то фильтры, полного списка я не нашел). А в чем проблема с картинкой в левой колонке?

Ради прикола еще вот тривиальный вариант (без CSS3, но зато и без поддержки старых IE

Как-нибудь так — не вариант?

Нет, именно как HTML5, по четко описанному алгоритму согласно соотв. разделу спеки. От SGML там по сути остались только угловые скобки и упоминание, что нынешний синтаксис был им "inspired by" Только валидаторами. Кстати, только благодаря тому, что браузеры не занимались честным SGML-парсингом, и можно было отдавать XHTML как text/html без опасений, что все эти <br/> начнут выводиться как "перенос строки + правая угловая скобка" (как формально того требует SGML).

Переходить — однозначно да, собственно говоря, вопрос так даже не стоит, HTML5 is not an option Но вот использовать сразу все его фичи — пожалуй, скорее нет.

Ну так задать тексту position:relative и z-index еще выше, делов-то...

Вставить полосу внутрь левой половины (насколько я понял дизайн, она всё равно должна привязываться к конкретным абзацам текста в ней) и спозиционировать абсолютно? Тогда она заведомо накроет и текст, и всё, что ниже левой половины...

Зря Чем же он такой... нехороший, что столько вебмастерских сил, достойных лучшего применения, уходит на борьбу с ним? Но если невмоготу, и именно для IE6-7 — имхо, ничего лучше старого почти-что-доброго onclick="this.blur()" едва ли найдется...

sigma77, вау, круто! Действительно просто, как всё гениальное! Вот только padding этим же блокам без CSS3 уже не задать, но это мелочи.

Какая версия IE? Старые, ЕМНИП, outline не поддерживали вообще.

Использую body, неявно. И с несплошным фоном проблемы, с border:transparent... без CSS3 (background-clip) удержать фон в границах padding-box у меня не вышло. А можно всё-таки труЪ-вариант подсмотреть,в личку или на мыло selenit(гав)mail.by?..

Ходят слухи, что поисковики слегка пессимизируют "кричащий" текст КАПСОМ. Ну и по смыслу капс — именно визуальное выделение, текст под ним-то обычный, не аббревиатура какая-нибудь и т.п...

Когда-то было занятное исследование на тему. Правда, достаточно уже давно, боты могли и учесть его результаты...

Насколько я в курсе, можно только целиком подменить своей картинкой. По дефолту каждый браузер в каждой ОСи рисует кто во что горазд, а надпись на кнопке вообще зависит от языка установки...

Очень даже по теме. Имхо, достаточно весомый аргумент против "пусть будет на всякий случай". Насколько я в курсе, беспрефиксный вариант должен идти последним — чтоб браузеры, поддерживающие и экспериментальную, и общепринятую реализацию применяли именно последнюю.

А я поддерживаю предложение Влада. Из старых работающих сайтов, конечно, -webkit вычищать незачем, но новые вполне можно делать без этого мусора. Пока верстка будет прикручиваться к движку, оставшиеся старые хромы как раз тихонько и обновятся...

Пока ничего лучше этого не придумал. Думаю дальше

Пока смог придумать только вариант с абсолютным позиционированием одного из блоков. Либо без, но только для жестко фиксированной высоты всей конструкции. Насколько понимаю, не то... думаю дальше. IE6 без хаков особенно занимает, по идее, решение должно быть не просто простым, а простым до безобразия...

Хм. Заинтригован, много думаю. Интересно, коммент перед доктайпом за хак для основной версии считается?..

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

Flash еще вот так умеет, чему JS, боюсь, еще не скоро научат. Но когда научат — это будет фантастика, по-моему

Насколько я понимаю, знания XHTML автоматом складываются из знаний XML и знаний HTML (именно в таком порядке). XMLность на стороне клиента — пока экзотика, но ее фанаты умудряются выделывать вот такое и вот такое. Вообще, по-моему, главные преимущества XMLности разметки — простота преобразований из одного представления в другое (напр., XHTML ? RSS) и интеграция с другими XML-приложениями. HTML5-парсер научился делать кое-что из этого (XPath-выборки, внедрение SVG и MathML) и с обычным HTML. Но добрый старый честный XML-синтаксис в таких редких задачах универсальнее. Моё имхо — HTML5 (во всех допустимых синтаксисах) будет жить в массовых коммерческих проектах, а XHTML с экзотическим обвесом (для химических формул и т.п.) — в академических областях (примерно там, для чего сэр Тим изначально задумывал HTML). Но действительность любит преподносить сюрпризы...

Переписывать все — однозначно бессмысленный. Одну-две — вполне достаточно, чисто чтобы показать, что "так я тоже могу". Грамотные заказчики вряд ли будут этим заморачиваться, совсем неграмотные — и подавно, а для полуграмотных сейчас более "модно" звучит HTML5.

Все плюсы и минусы XHTML вытекают из того, что это XML. Если вы точно уверены, что эти плюсы вам важны, а минусы не страшны — пользуйтесь на здоровье. Если вы в этом не уверены или вообще еще плохо знакомы с XML, имхо, лучше не пытаться сходу объять необъятное — это ведет лишь к путанице. Сегодняшняя реальность веба сложилась так, что решающих преимуществ у XHTML в типичных задачах практически нет. К тому же любая разметка, отдаваемая как text/html, для браузеров всегда будет HTML (для современных — HTML5), что бы там ни "воображали" по этому поводу ее доктайп и валидаторы. В HTML5 вообще синтаксис глубоко вторичен, гораздо важнее семантика и логичность структуры DOM.