SelenIT

Да ладно, хвалить надо Great Rashа — это он придумал метод, а я так... модифицировал) И я, как выяснилось, даже не оригинален — способ с :after уже опубликован (via getincss.ru). Там как раз реализовано через обнуление/переустановку font-size и line-height, что дает бонус в виде возможности верт. выравнивания блоков по центру (у меня получается только по верху или низу). Правда, в вебкитах всё равно остался двухпиксельный зазор снизу (по крайней мере на моей машине), хотя это легко поправить, напр., задав отдельный отриц. отступ через @media screen and (-webkit-min-device-pixel-ratio:0). Но, думаю, знание вариантов и их граблей в любом случае полезно...

Еще не разобрался, нашел в гугле впопыхах буквально за 20 мин до того, как залить . Интерфейс веб-ФТП показался тормозноватым... Так в том-то и дело, что тут это не контент, а всего лишь хелпер, которому как раз не место в контенте. Имхо...

Да, именно это. В IE6 select не слушается z-index-а и перекрывает почти всё, но iframe оказывается "козырнее" и перекрывает его (даже если этот iframe сделать полностью прозрачным или вообще невидимым с помощью фильтров). Поэтому под всплывающие элементы подкладывается (обычно скриптом) пустой iframe такого же размера, позиционируя его в те же координаты, но ниже по z-index'у. Выше psywalker показал вариант, как именно

Пробел (или табуляция) не обязательно может быть в этой же строке, может быть на следующей. В изначальном примере Great Rashа этой проблемы не было именно потому, что там лесенка тегов глубже и перед </ul> пробелы были. А я вот решил "компактизировать" и напоролся). Странно, что сам перевод строки не работает, это же тоже пробельный символ, по идее...

Вот залил по-быстрому: http://selenit.freeoda.com/experiments/justify.html Вместо кондишнл-комментов поставил старые добрые хаки, чтобы IETester'ы/multipleIEs не запутывались. У меня почему-то даже в IE5.5 нормально, может, у меня multipleIEs поломан?..

Совсем без хаков нет — по той причине, что IE6 понимает :hover только для ссылок, а ссылок в ссылках не бывает. Но вариант без скриптов существует. Хотя лично я скептически смотрю на pure-CSS-выпадачки глубже одного уровня. Всё-таки для нормальной работы с ними нужна небольшая задержка после увода, а этого без скриптов пока не реализовать...

Сорри, но iframe валидируется всё-таки с Transitional-доктайпами (Frameset — это для обычных фреймов, с frameset-ом вместо body). Либо с HTML5. Используется чаще всего, да, в качестве подпорки или замены аякса (фоновый аплоуд файлов и т.п.). Во времена IE6 еще использовался для перекрытия select-ов всякими раскрывающимися меню (там они непослушные), это актуально везде, где поддержка IE6 еще нужна. Еще вариант — замена всплывающих окон (вместо нового окна — что-то типа lightbox с iframe внутри, а в iframe — то, что должно было быть в попапе). Поддерживается сейчас везде, но недостатки все те же, что у обычных фреймов, поэтому основную функциональность сайта завязывать на него не надо.

Можно и без JS (легендарный "CSS-маньяк" Роман Кортес даже показывал, как), но ценой кучи избыточной разметки. А разрешение тут на что влияет?

Разумеется (через multiple IEs и эмуляцию в IE8). Во втором варианте, правда, я убрал text-align для li (без него IE6 невообразимым образом растягивает слова), но его всегда можно вернуть. А какие еще в IE6-7 проблемы?

quirksmode.org предлагает еще более простую конструкцию (как кроссбраузерную): var text = x.innerText || x.textContent

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

А IE (6-7) не нуждается в элементе-затычке для клиринга флоатов, там hasLayout-а достаточно. А 8-й умеет по стандарту.

Кажется, выяснил, откуда корень бед с Вебкитом: он не позволяет сжать строки текста плотнее, чем на величину очка шрифта (т.е. чтоб буквы слиплись вплотную, но всё-таки остались кое-как различимы). По идее, это должно быть 1ex, но на практике из-за округления цифра скачет, да еще от размера шрифта зависит. Проще всего поставить font-size:1px (c нулем бывают странности) для ul, а для li вернуть какой надо, но это не позволяет использовать em-ы и сквозной размер для всего документа. Без этого ограничения (хотя с другими, имхо менее существенными) у меня получилось так (только стили, разметка та же, строчки для IE6 и FF2 убраны для простоты): <style type="text/css"> ul, li { margin: 0; padding: 0; } ul { list-style: none; text-align: justify; text-align-last: justify; background: #060; line-height: .7em; /* гарант. минимальная высота строки, на которую "соглашается" Webkit */ } li, ul:after { display: inline-block; vertical-align: top; /* или bottom, но не middle и не baseline */ } li { background: #f88; line-height: 1.4em; /* это минимум общей высоты блока со всеми паддингами/бордерами */ margin-bottom: -.7em; /* даем псевдоэлементу "нахлестнуться" на блоки на всю его высоту */ position: relative; /* но приподнимаем блоки над ним, чтоб он не закрывал их от выделения */ } ul:after { width: 100%; height: 0; content: '\00a0'; } </style> <!--[if lte IE 7]> <style> ul, li { zoom: 1 } /* для hasLayout-а */ ul { text-justify: newspaper; } li { display: inline; margin: 0; /* раз нет псевдоэлемента, то и "нахлест" не нужен */ } </style> <![endif]--> Имеет право на жизнь, как вариант? Или слишком сложно и негибко?

Первая мысль - самая правильная. Фтопку пустые оформительские дивы, :after - труЪ CSS-путь. Просто надо было найти в CSSнике объявление класса .clr и заменить на .clr, h3:after - ну и для подстраховки добавить туда display:block и content:'.'

Сегодня на Хабре обсуждают жуткое решение этой же задачи с лишними обертками (и без всякой магии), один из комментов натолкнул на мысль, как всё-таки можно усовершенствовать решение Great Rash. Кажется, получилось! В архаике, правда, не проверял (кроме IE6), но в мало-мальски актуальных релизах "большой пятерки" полет нормальный. Главное улучшение — в полном отказе от несемантичного блока .helper, который для IE (где работает text-align-last) не нужен, а в остальных легко заменяется псевдоэл-том :after. Главные подводные камни, обнаруженные по ходу улучшения, упомянуты в комментах. Буду благодарен за регрешн-тесты и любые другие соображения! <!DOCTYPE html> <title>Test</title> <meta charset="utf-8" /> <style type="text/css"> * { margin: 0; padding: 0; } ul { list-style: none; text-align: justify; text-align-last: justify; /* на будущее :) */ background: #060; line-height: 0; /* чтобы перенос последнего псевдоэл-та не добавлял высоты */ } li, ul:after { display: -moz-inline-box; /* уже не актуально, можно выбросить */ display: inline-block; vertical-align: top; /* лишь бы не baseline, чтоб не распирало контейнер */ } li { text-align: center; /* лишь бы не auto, иначе сносит крышу IE6 - опять мистика! */ background: #ffc; border: 2px solid #ccf; padding: 10px; line-height: 1.33em; /* или любое др. норм. значение для приятного вида текста */ } ul:after { width: 100%; height: 0; content: '.'; overflow: hidden; } </style> <!--[if lte IE 7]> <style> ul, li { zoom: 1; } /* видимо, всё-таки достаточно просто hasLayout-а */ ul { text-justify: newspaper; } li { display: inline; } </style> <![endif]--> <ul> <li>home</li> <li>about us</li> <li>contacts</li> <li>some other link</li> <!-- ВАЖНО! Перед закрывающим ul нужен хотя бы один пробел, иначе ломается Webkit! --> </ul> UPD: первые грабли (уже знакомые) нашел сам. Если задать UL фон (как в обновленном примере), виден странный отступ снизу в вебкитных. В оригинальном решении он тоже, увы, был, так что это не регрешн. У вебкитов какое-то ограничение на минимальную высоту строки, что ли? Есть идеи, что это может быть и как его бороть, не прибегая к отрицательным маргинам и оберткам с overflow:hidden?

Хорошая статья по теме (включая советы по выбору).

Хм, действительно, Verdana и Arial вроде есть (судя по этой таблице... странно, почему-то в моей памяти из нее же отложилось обратное. Просто недавно сам напарывался на похожий глюк, по всем симптомам выходило, что дело в замене Arial-а на что-то системное... теперь, видимо, придется изучать вопрос заново..

Насколько я в курсе, под маком не существует ни Verdan'ы, ни Tahom'ы, ни Arial'а, поэтому браузер подставляет дефолтный системный шрифт, который, судя по всему, оказывается гораздо шире, и этим растягивает пробелы между кнопками. Нужно явно указать в списке что-то из маковских аналогов, напр. Geneva и/или Helvetica...

Для FF есть остроумное обходное решение с использованием XBL (продвинутого мозилловского аналога IE-шных htc).

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

В IE есть фильтр Matrix (собственно, в библиотеке по той ссылке он и используется).

Если доктайп XHTML, то надо закрывать. Если HTML4.01, то не надо. Если HTML5, то как угодно/привычно (можно закрывать, можно нет). У разных языков — разные правила.

Во всех, кроме IE И для чисто оформительских целей, имхо, семантически пресный <span> оправданнее, чем <ins>. Если плюнуть на Strict-валидность ради экономии десятка байт, можно древний <u> вспомнить...

Vlad, спасибо еще раз!

Можно через display:table для контейнера и table-header-group/table-row-group/table-footer-group для самих элементов (как здесь). Но насколько это оправдано и семантично — каждый решает для себя...