SelenIT

И зачем было эти разделители рисовать отдельными дивами??? о_0

Фонами они реализованы, как же еще. Притом, мягко говоря, не оптимально (в первой ссылке особенно). Вот описание более изящного решения (правда, по-английски)...

Зря, прежний лучше был. 4.0 всё-таки устарел. 4.01 для 99% нормальных сайтов для людей - самое то. Просто не надо было синтаксисы смешивать...

С точки зрения реальных браузеров, как правило, ничем. Но формально HTML 4.01 и XHTML 1.0 - разные языки, хоть и с одинаковым словарем (набором элементов и атрибутов), но с существенно разным синтаксисом (SGML и XML соотв-но). И многие записи из одного синтаксиса в другом либо недопустимы, либо имеют другой смысл. Так что крайне желательно соблюдать правила синтаксиса того языка, который объявлен в доктайпе. А то мало ли...

Просто сочетание доктайпа от HTML4.01 c xhtml-ным неймспейсом и слешами в одиночных тегах вызвало легкий когнитивный диссонанс . Хотя согласен, что это - меньшее зло, чем когда наоборот...

Все-таки решение нашлось! Если тупо выдерживать цепочку значений, рассчитываемую вот этим EM-калькулятором, всё сходится, вроде как во всех браузерах. Моя ошибка была, стало быть, в том, что исходные 11px я задавал как 68.75%, а не 0.69em. О как. Но не зря я был уверен, что эта задача уже кем-то решена!

Подтверждаю наличие проблемы в Опере 9.6. Но дело не в position, а в вываливании float-ов из предыдущего контейнера (с padding: 0 20px). Overflow: hidden для него или easy-clearing должен ее решить. P.S. На каком языке написан код этой странички?

В IE6 (и ниже) <select>-ы "волшебные" (по сути элементы Win-интерфейса). Есть три основных воркэраунда: - подложить под подсказку <iframe> такого же размера, он умеет перекрывать <select>; - на время показа подсказки сам <select> прятать; - отказаться от стандартного <select>-а в пользу самодельного или готового JS-контрола с подходящим дизайном.

... usemap="#karta1" ? P.S. Для чего перед этим кодом XHTML-доктайп?

Я имел в виду View - Text size (и там Largest, к примеру). В IE6 это влияет на шрифты без указания размера, с размерами в em, в %, даже в pt (что, имхо, абсурдно) - но не в пикселях. Другие браузеры (включая IE7) умеют либо масштабировать страницу целиком, вместе с графикой - как бы "растягивая" пиксели, либо масштабируют шрифты независимо от того, в чем указан их размер (FF2, Safari), либо и то и другое, на выбор юзера (FF3). Использовать JS очень не хочется. Хотя мысль интересная...

Сейчас так и делаю два разных стиля. Обидно, что проблема даже в IE8 RC1 не ушла... Но неужели в IE для этого случая не завалялось очередной порции магии навроде hasLayout? А размеры в em-ах понадобились потому, что IE6 - фактически последний из актуальных (пока еще, увы) браузеров, не умеющий масштабировать пиксельные шрифты. А заказчик требует, чтобы текст масштабировался везде...

В буквальном переводе на современный это будет примерно так: function changetext(whichcontent){ document.getElementById('descriptions').innerHTML='<span style="font-family:arial,sans-serif">'+whichcontent+'</span>'; } А все доисторические теги типа layer и ilayer - обратно на помойку. Но вообще, конечно, в выборе образцов для копирования действительно надо быть поразборчивее

В общем, заурядная задача - сделать между абзацами с 11-пиксельным шрифтом 5-пиксельный отступ - превратилась в... интересную, когда понадобилось исправить пиксели на em-ы (угу, ради 6-го IE, чтоб ему... . 5 на 11 нацело не делится, получается 0,(45). В FF3 и Опере 9 прекрасно работает округление до тысячных - margin: 0.455em 0. На целой странице в два экрана текста - ни пикселя расхождения. А вот в IE (пробовал на 8-м, в режиме 7-го и в новейшем) примерно каждый третий-четвертый абзац слипаются на пиксель ближе. Потому что (как показывают Developer Tools) реально используется значение отступа 0.45em - третий знак тупо отбрасывается. Если через хаки подставить 0.46em (округленное до двух знаков, но математически правильно), проблема становится меньше, но до конца не исчезает (каждый десятый-двенадцатый абзац все равно на пиксель ближе к соседу, чем надо). В остальных браузерах при 0.46em абзацы, наоборот, расползаются. Проценты не подходят - для отступов они берутся от ширины контейнера, а не от шрифта. Задавать отступы в пикселях при масштабируемом шрифте - не комильфо как-то... Неужели нет способа приручить IE?

Vlad, на 100% согласен, если речь идет об обычных ссылках в тексте. Но у меня вопрос возник в связи с выпадающим меню, где при наведении на ссылку уже "всплывает" подменю. Может, разумный компромисс - задавать title только для концевых пунктов, без подменю? Или я преувеличиваю неприятность "лишних" подсказок для пользователей (просто сужу по себе, мне они в подобных случаях мешают)?

Мда, там не только в шапке "параллели напрашиваются". Даже одно ведерко краски уволокли...

Уважаемые знатоки, подскажите пожалуйста: есть ли прок (с точки зрения SEO) от прописывания title-ов ссылкам в выпадающем меню? С моей точки зрения, всплывающие подсказки там юзеру только мешают (навел на одну ссылку - выскочили две надписи, к тому же некликабельная наехала на кликабельную и приходится ждать лишнюю секунду, пока она пропадет). Но вчера меня пытались убедить, что для SEO это здорово, притом убеждали тупо продублировать в title текст самой ссылки (т.е. наводит юзер на ссылку "Новости", а сайт как бы говорит: "Там действительно новости, честно, мамой сервера клянусь!". Бегло погуглив, нашел несколько упоминаний о том, что адекватные осмысленные title-ы с ключевыми словами действительно могут помочь (напр, здесь), тогда как тупое дублирование текста скорее мешает (как я интуитивно и предполагал). Но мне кажется, что выгода от такой оптимизации (даже если делать ее с умом, именно как оптимизацию контента) не перекроет потерь от неудобства этих назойливых подсказок для юзера. Так что в выпадающем меню они напрочь не нужны. Вот для обычных ссылок в тексте, из-под которых ничего не выезжает, эти подсказки могут быть действительно полезны - и пользователю, и поисковым ботам. Заблуждаюсь ли я? Заранее благодарен за любые подсказки по этой теме.

Смело, но спорно. Насчет табличной/списочной природы календаря я согласен с аргументом, что вертикальная группировка по дням недели в нем значима (не только представление). Хотя, конечно, от ситуации/задачи зависит, для программы киносеансов, пожалуй, это и неважно. Насчет ins-ов и del-ов... Занятно, что del-ы для "клеток" соседних месяцев мне по первому впечатлению дико понравились, то ins-ы для пустых дней текущего месяца вызвали отторжение: разве мы тут что-то вставляем? Последовательность дней ведь не поддается правке, это объективная данность. Не лучше ли (по семантике) было бы тут, к примеру, использовать консервативные span-ы, обернув дни каждого м-ца в свой спец. контейнер? А если бы все браузеры поддерживали CSS Counters - тогда можно было бы и числа вручную не проставлять... Вот насчет добавления столбца в HTML-таблицу - это да, морока (если без визуального редактора либо автоматической генерации). И про FF2 согласен полностью (хорошо, его осталось меньше 3% и он уже официально не поддерживается даже самой Мозиллой). Но у display:inline-block есть и другие подводные камни - значимость пробелов между тегами, например...

Первое, видимо, для 5-го IE (с нестандартной боксовой моделью, в которой padding-и не плюсуются к ширине). Ну а второе для всех остальных, со стандартной моделью (включая IE6 при правильном доктайпе).

Vlad, да, программы тоже вносят свою лепту в путаницу (взять ту же PHP-шную nl2br). Но примеры и аргументацию из топика я слышал от людей, а не от программ. Притом с весьма ненулевым практическим опытом. Victor Ananiev, четвертый вариант говорит, что и третий неверен. Нельзя ничего сказать ни о валидности, ни о невалидности примеров без схемы, по которой их валидировать. Вот о логичности/оправданности их использования - вполне можно (по моему мнению).

Vlad, именно так. Особенно странно порой видеть такие теги в страницах на шаблоне икснадцатилетней давности (никакого доктайпа, разумеется, таблицы-перетаблицы, отступы прозрачными гифами... зато в NS4 работает. Мотивировка: "...ну как же... иначе невалидно ведь!" А какие разумные основания могут быть для записи "<BR />"?

На самом деле, этим топиком я пытался приблизиться к разгадке, почему из всех требований XHTML именно эти слеши в одиночных тегах закрепились в массовом сознании как едва ли не "главный признак хорошей вёрстки". Поэтому и составил вопрос намеренно некорректно. Ведь валидность по определению - соответствие схеме, а схему я нарочно не уточнил. Так что единственный логически строгий ответ на этот некорректный вопрос, имхо, последний ("в задаче недостаточно данных"). Первая запись, очевидно, невалидна в XHTML из-за регистра. Как ни странно, проходит формальную валидацию и в HTML4.01, и в HTML5 . Правда, в HTML 4.01 Strict она (в теории) означает не совсем то, что можно ожидать (и что показывают браузеры)... но официальный W3C-шный валидатор считает это не ошибкой, а всего лишь warning-ом. Правда, менее бредовой она от этой валидности не становится . А вот вторая запись, да, полностью правомочна в любой версии HTML. Ну а совместимы ли вообще принудительные разрывы строк и "правильная вёрстка" - вопрос философский... P.S. По предварительным результатам можно сказать, что вера в "волшебные слеши" действительно популярна. Не оттого ли это, что они - самая неинтуитивная (для начинающих) из явных особенностей XML и потому, "волнует и манит, как всё неизведанное"?

-=PSU=-, тест на внимательность пройден, поздравляю! . Наверное, после этого наводящего вопроса особого смысла сохранять интригу нет, так что можно потихоньку начинать холиворить...

Будут одинаковой ширины

Равная высота колонок (или ее эмуляции) - давняя и избитая тема у верстальщиков, но "серебряной пули", насколько мне известно, так и не изобрели. Основные варианты - либо padding-bottom: 32767px; margin-bottom: -32767px, либо наложение колонки на border соседней, который "притворяется" ее фоном. Либо вообще одна фоновая картинка на контейнер, имитирующая фон обеих колонок сразу ("faux columns"). Еще вариант - псевдотаблица (display: table-cell). Но он не работает в IE (ниже 8-го) и не позволяет визуально менять колонки местами.

lampo4ka, к сожалению, в нынешнем CSS раскладку абсолютным позиционированием и прижатый к низу футер не совместить, позиционированные блоки (левое меню в данном случае) не влияют на высоту контейнера (body) и тупо обрезаются. Не вижу другого выхода, кроме как переделать раскладку на float-ы. Заодно можно будет убрать меню в конец кода, после контента (говорят, это для SEO полезно). И еще, блок green_line, по-моему, абсолютно бессмысленный. И вообще эти параллельные линии (как и в футере), по-моему, вполне можно нарисовать без фоновой графики, одними фоновым цветом и бордерами...