SelenIT

Забудьте о "блочных" и "строчных" элементах, в HTML5 их отменили. Смотрите на смысл элементов и на их content model. Смысл абзаца - деление текста на смысловые фрагменты (грубо - от "красной строки" до "красной строки"), поэтому ничего, кроме текста, в нем содержаться не может. Начало любого блока текста автоматически означает, что это не продолжение старого абзаца, а что-то новое. Будь моя воля, я бы сделал закрывающий тег для <p>, и так не обязательный, вообще запрещенным. Толку с него немного, а новичков (особенно наслушавшихся XHTML-проповедников) его наличие только сбивает... А если нужен абстрактный универсальный контейнер, чтобы группировать что угодно - это div.

Тупо подсмотрел у мастеров...

А, так там еще и Cufon . Лично мне повезло с ним дела не иметь, но, насколько я понимаю, дело в заготовке шрифта (видимо, файл Myriad_Pro_300.font.js), где просто не оказалось нужных символов. Вот этот генератор, если я верно понял, позволяет выбрать нужные поддиапазоны набора символов - включая кириллицу. Но вообще Cufon - уже немножко прошлый век, сейчас в моде @font-face, они работают во всех уважающих себя браузерах и гораздо удобнее и гибче. Да и Myriad Pro - на мой взгляд, не такой уж суперэкзотический шрифт, что замена его на другой похожий sans-serif будет прямо сверхкритичной (списки подходящих альтернатив наскоро нагуглились, например, тут и тут). И еще: <meta charset> в коде должна идти до <title>, т.к. кодировка должна определиться до начала любого вывода текста, а <title> - уже вывод (в заголовок окна/таба). Здесь это, судя по всему, ни при чем, но на будущее может помочь избежать проблем вида "указана одна кодировка, отображается в другой"

Без display:block (или переопределения vertical-align) для картинки под ней получается зазор в 3-4 пкс (для нижних выносных эл-тов текста). Соотв-но, снизу полоска перехода будет чуть уже и может даже некрасиво обрезаться.

Основная идея примерно такая. Фантазия в оформлении не ограничена, но для старых IE нужно предусмотреть или скриптовый костыль, или (имхо, лучше) деградацию к обычному виду.

В приличных браузерах вроде и без псевдоэлемента выходит... )

Можно вот так для чуть большей универсальности.

Уберите коммент перед доктайпом. Из-за него IE валится в режим обратной совместимости (фактически, превращается в IE5.5).

Можно просто bottom: 0, ничего вычислять не придется. А еще картинку можно положить фоном для общей обертки с background-position: 100% 100%.

При большом желании, можно и сами пункты растянуть через justify (с изящной деградацией в IE7-), но стоит ли равенство внутренних отступов таких вывертов...

yatsan, можете показать минимальный пример проблемного кода (желательно в виде ссылки на беспл. хостинге или jsfiddle.net/dabblet.com)? И на будущее, желательно подобные вопросы задавать в отдельном топике (т.к. от HTML5 тут только доктайп, а проблема пока вообще непонятно в чем). Уважаемые модераторы: может, отделить вопрос? Возможно, deafult-charset на сервере настроен в прошлом веке. На мой взгляд, лучше разобраться с его настройкой.

Вдогонку: пример в три клика из комментов к примеру в стартовом посте

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

Для данного примера, сугубо имхо, CSS-таблица — самое то.

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

По-моему, скорее мораль "никогда не рассчитывайте на размер текстовой надписи строго до пикселя". Потому что, кроме IE9 и WinXP со сглаживанием и без оного, в мире есть Линуксы со своими дефолтными шрифтами каждая, Андроиды (тысячи их!), на которых шрифты тоже почему-то чуть крупнее нормы, и т.п. Имхо, правило "плюс-минус 2 шага текстового зума" — ну ладно, хотя бы плюс-минус 1 шаг — при кроссплатформенной верстке рановато сбрасывать со счетов...

Какой шрифт? Что выводится вместо русских букв — квадратики? вопросики? В общем случае — напрасно. UTF-8 гибче и универсальнее.

Моя догадка не подтвердилась, провел эксперимент, получил такой результат: Тут скриншот с IE9 наложен на скриншот с FF9, в IE все размеры почему-то чуть шире (даже 16px и 12px, однозначно переводимые в 12pt и 9pt соотв-но). Видимо, просто другой рендеринг, просто надо учитывать (как раньше учитывали возможно разную ширину текста со сглаживанием и без, а также вероятность другого шрифта на другой ОС). С em-ами, боюсь, как бы не было еще хуже...

include тупо вставляет содержимое файла в текущий скрипт, функционально он эквивалентен eval(file_get_contents(...)), если не вдаваться в детали. Все переменные, доступные в текущем скрипте, автоматом будут доступны и в подключаемом, так что для исходной задачи $_GET['s'] = 'music'; include('file.php'); и вперед. Инклюдить текст, получаемый по HTTP (и вообще работать с HTTP-ответами как с файлами) можно при соотв. настройке PHP, но, как справедливо замечено выше, это глупость (и потенциальная дырища в безопасности). За собственными файлами не надо так далеко ходить, они лежат тут же на файловой системе, а чужие надо аккуратно парсить и доставать из них только нужное...

Насколько я понимаю, причина где-то здесь. Дальше тупо моя догадка: поскольку пиксели теперь абсолютная единица и однозначно переводятся в пункты, получается, размер у ссылок 8.25pt. Другие браузеры, видимо, умеют рисовать шрифты только из дискретного ряда округленных значений (ближайший — 8pt), тогда как IE9 со своим новым граф. движком выдает дробные пункты (или дробные пиксели — для рендерера это теперь одно и то же с точностью до масштабного коэф-та) во всей красе. Факт в пользу этой догадки — если выставить для IE9 размер шрифта 10.67px (соответствующий целым 8 пунктам), отображение становится гораздо ближе к отображению во всех браузерах...

Любым другим способом из over 9000. Мне ближе всего этот (да, в примерах там используется text-indent в качестве фоллбэка для IE6-7 — но сейчас уже вполне можно от этого отказаться, пусть IE6-7 довольствуются простым текстом, как при отключенной графике). Вариант с text-indent для меня прочно стоит в одном ряду с табличной версткой. В качестве грубого и быстрого решения маловажной задачи (какая-нибудь вспомогательная плашка в сайдбаре и т.п.) — годится. Но основная верстка не должна падать в обморок от отключения графики, а основной текст (тем паче заголовок!) должен читаться при любом раскладе. Для контента, верстаемого с любовью, всегда можно выбрать способ получше...

Для этого используют много способов (и это далеко не всё). Вариант с огромным отрицательным text-indent'ом, имхо, один из самых неудачных (т.е. с ним нельзя прочитать ничего, если картинки отключены/не догрузились, он противно распирает рамку нажатых ссылок в FF и т.д.).

Как вариант, можно посмотреть в эту сторону.

Пока нет. Template layouts будут позволять, но когда они будут (если будут) — еще большой вопрос...

В половине браузеров (FF 4+, Chrome 7+, на подходе Opera 12+ и IE 10+) "version(html) < 5" всегда false. По построению парсера. Так что, имхо, ставить короткий доктайп, юзать вариант 3 (никакой концепт это не нарушает, парсер позволяет, а "строчность и блочность" теперь все в CSS) и не переживать по поводу. А выкрутасы типа этого примера со спанами оставить истории. Есть такое. Увы, за этим нужно следить самому — чтобы у всех элементов с display:block обязательно был контейнер с display:block, inline-block, table-cell или другим подходящим, а внутри элементов с display:inline был только текст или элементы с display:inline, inline-block или inline-table (если это нарушить — катастрофы не случится, браузер добавит анонимный бокс нужного типа, но управлять им станет намного сложнее).