swetlana

если я что-то в чём-то понимаю, то inline-block именно так себя и ведёт. или display: table-cell. Но это немного нелогично будет, хотя результат тот же самый

ошибка в версии сафари уже наверно год как актуальна пятая версия.

речь о display: inline-block?

вообще, до сих пор не понятно, в чём именно проблема. Если не срабатывает :active, то смотрите, не перезадан ли он с большей специфичностью например. Если вы находитесь по адресу /contacts/, и ссылке не назначается класс selected или active — тут проблема та, которая описана выше. Ссылка зря вынесена из меню.

Для восстановления картины можно ещё показать нам содержимое файлика SITE_TEMPLATE_PATH/components/bitrix/menu/top_default/template.php Хотя подозреваю, что там всё в порядке, а проблема строго та, которую излагает Searcher. Ну и есть ещё одна проблема, из которой следует возникшая у вас проблема. Ссылка на контакты должна быть в меню. То есть, в .top_default.menu.php, а не здесь.

без него нормально отрабатывают конструкции с минимальной вложенностью. В данном же случае этот символ вполне уместен. Обратите внимание, что у автора темы менюха с тремя уровнями вложенности. то есть, если наводим мыша на пункт первого уровня, то селектор ul.nav-main li:hover ul затронет все ul, расположенные в ul.nav-main li при наведении. Все — это означает, что все независимо от вложенности. То есть подменю и все подподменю. Чтобы такого не было, и ограничивается действие селектора только прямым потомком. Так что тут всё нормально.

Комментарий Садовского конечно может за авторитетное мнение приниматься. А вот вопрос: моё ламерское имхо полагает правильным использование h1 главным заголовком на секцию, но не имеет уверенности в том, что именно так — единственно верный вариант. Твоё же ламерское имхо утверждает, что новой спеке абсолютно параллельно, h1 или h2-h6. Если твоё ламерское имхо правее моего ламерского имха, то вопроса насчёт заголовков просто не остаётся, этот вопрос тогда признаётся порождением моего незнания в чистом виде, и ничем больше. А как бы можно удостовериться в том, что действительно номер заголовка не важен?

насчёт идеально — это, конечно, громко сказано. Но хорошо, и сделать можно что угодно — это факт.

покажите страницу

Если заказчик боится договора, вам следует задуматься, почему. Договор, конечно, не панацея, но он в какой-то мере подтверждает серьёзность намерений сторон. Разве что от совсем дурачка. — но вы возьмётесь столь нетривиальным способом сверстать целую страницу? Можно, конечно, пойти на другой изврат, и подгружать страницу аяксом откуда-нибудь. По Cmd+U тоже не будет виден код. Но любой хотя бы минимально грамотный человек всё равно этот код получить сможет. Так что все эти извраты не стоят того, чтобы ими заморачиваться. да, конечно.

или так. Так даже лучше, поскольку каждый занимается своим делом, и такие вопросы, с какого началась тема, просто не возникают.

поддерживается он как раз везде. Ну разве что ископаемые IE его понимают как type="text" (что, в принципе, вполне приемлемо). А особый внешний вид — это на самом деле правильно. Вообще, элементы форм должны выглядеть так, как их браузер отрисовывает. И должны быть такими же, как принято в используемой ОС, учитывая и внешний вид и поведение. В частности, в сафари если нажать Shift+Cmd+F, фокус ввода помещается в <input type="search">. Это и есть правильное ожидаемое поведение. Это и есть часть поведения, описываемого -webkit-appearance:searchfield. Внешний вид, повторяющий внешний вид системного поля поиска — тоже из той же оперы. Другое дело, что уверенному в собственной гениальности дизайнеру эконом-класса этого не объяснить. Или может и можно объяснить, но это стоит дороже, чем поставить одну строчку в css и согласиться с надругательством над здравым смыслом.

договор.

да. С момента, когда ссылка нажата, до момента, когда браузер сменит текущую страницу новой, будет применён этот стиль.

пока что не видно ни одной причины, чтобы этот стиль применился. Если он для класса active, то он и должен применяться к <a class="active">. Тут же ссылка без класса. Или я чего не так понимаю?

это <input type="search">. по функционалу он не отличается от <input type="text"> (по крайней мере пока). Однако вебкитные браузеры такой инпут оформляют по своему, и повлиять на это средствами css не во всём возможно. В частности, нельзя задать форму, рамку. Однако это всё легко задаётся простому текстовому полю. Вот и переопределяется из поля поиска в простое текстовое. Влияет это переопределение только лишь на особенности внешнего вида.

специально забацать не буду. Покажу в какой-нибудь из моих недавних работ. Например, тут. Поле поиска тут, правда, надо ещё суметь найти, но подскажу: оно справа наверху еле заметное. Вот к нему и применён стиль -webkit-appearance: textfield. Попробуй в веб-инспекторе выключить это правило и посмотреть, что будет.

-webkit-appearance заведует лишь внешним видом. К примеру, есть определённый внешний вид у <input type="search">, а вот дизайнеру захотелось его хитро по-своему оформить. Вебкитные браузеры плевать хотели на стили и оформляют его всё равно так, как по их мнению должно выглядеть поле поиска. А чтобы оформить было можно, задаётся -webkit-appearance: textfield — и всё, можно творить что угодно.

если float: left, то не отцентрировать. Если нужно сделать, чтобы ширина по содержимому была, то display: inline-block (или inline, если поддержка ископаемых браузеров требуется).

Такие случаи не редкость. Эта проблема известна. Решается только беседой с заказчиком. Технические же решения только кривые и непозволительные существуют вроде заголовков картинкой.

как занятно! Вот уж нет, не пропустил. А наоборот, обратил внимание, своё и общественности. Даже если сказать ul ul { list-style: none; }, всё равно для вложенного списка появляется маркер. Хотя по идее не должен. Или я не понимаю почему. Вот такое странно повердение у Оперы. И особенно ничего и не находится по данной проблеме. Может, её и не замечал раньше никто? Ведь традиционно в менюшках маркеры списков не используются, убирают их, а если задумка дизайнера велит поставить маркер, то его делают обычно фоном. Вот и не было широко известно о данной проблеме.

Ну это не совсем то. Это всё-таки в рамках более традиционных представлений.

EDark, вот вы отрицаете наличие проблемы с отображением зажатых в тесные рамки текстов в маке. А не боитесь, что здесь могут оказаться пользователи маков, которые вам не поверят? Проблема есть. Да, в отдельных случаях с некоторыми шрифтами в Windows 7 она тоже есть — с этим соглашусь. Но природа этой проблемы в маке и вин7 одинакова. Да, ФФ4 несколько странно работает со шрифтами. Это замечено неоднократно. Иногда он даже путает шрифты — ставит с засечками там, где велено тахому ставить. Такое тоже замечено. Но вот только пользователям объявлено, что ФФ4 вышел. Переход начался. Мы ж не будем по домам ходить, удаляя с компов ФФ4 или правя в нём настройки, не так ли? А решение всех этих проблем одним махом крайне простое: не зажимать текст в узкие рамки, оставлять ему свободу. И все дела.

Без сомнений возможно. Но js тут значительно уместнее.

по прежнему адресу пока всё так же visibility. попробуй поменять способ скрытия на display: none. ну и display: block соответственно, чтобы отобразить. Если после этого не встанет всё на свои места, то значит я ничего не знаю о css, блоках и вложенных меню. Будем тогда учиться вместе.