SelenIT

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

Похоже, есть у IE8-9 (как минимум) такая беда, что при white-space: pre-что-то они понимают каждый из символов \r и \n как отдельный перевод строки (такая же беда наблюдалась в первом варианте этого трюка Лии Веру). Если есть возможность убрать символы возврата каретки (\r, код 13 или 0xD) из исходника, это должно помочь. Других вариантов сходу в голову не приходит...

Вероятно, логика (странная, но всё же) в одной подробности этого раздела спецификации:

В элемент A, да, теперь можно вкладывать почти что угодно (кроме интерактивных элементов, прежде всего других А). Но в UL, как и раньше, можно вкладывать только LI и ничто иное, и нарушение этого правила — насилие над DOM, при котором браузер имеет право на самооборону с непредсказуемыми для кодера последствиями Не заморачивайтесь «блочностью» и «строчностью» элементов HTML, она и раньше не решала (P, DT и все заголовки были «блочными», но вкладывать в них можно было только «строчное»), а теперь ее и вовсе отменили. Думайте о том, для чего элемент предназначен и в чем его функциональная роль, а не о том, как он обычно отображается на экране.

[offtop] Кстати, по иронии судьбы, единственные ботинки, которые у меня не пришли в негодность и почти не потеряли вид за 4 года — были китайские за 20 у.е. со стихийного уличного рынка (а до того были китайские же кроссовки за 10 у.е. с близкими показателями живучести) . А вот 100-с-лишним-баксовые из раскрученного фирменного магазина (правда, благодаря прошлогоднему обвалу мне обошлись вдвое дешевле ) едва-едва дожили до конца сезона (и от знакомых слышал схожие жалобы). Вообще весь мой персональный опыт говорит, что хорошая (не "модная", не "прикольная", не "крутая", не "авторитетная" и т.п., а именно хорошая) вещь дорогой быть вряд ли может. Слишком дешевой — тоже (хотя бывают приятные исключения), но стык верхнего края лоуэнда и нижнего края серединки — как правило, самое то или очень близко. А вот то, что дороже интуитивного психологического предела — с гораздо большей вероятностью блестящий пафосный хлам в дорогой упаковке для не разбирающихся в теме бездельников, чем скромная функциональная вещь "для народа". Может, и в верстке подобные закономерности есть? [/offtop]

По-моему нет, jQuery же в простом value сам собой не выполнится... Имхо, надо не JS-код в value писать, а вызывать $('input[name=cvet]').val(...) в том же jq, который меняет фон дива (а лучше хидден-полю дать id и обращаться по нему).

Судя по последнему Note здесь — весьма нежелательно. Я последнее время склоняюсь к тому, что списки — преимущественно для текста, как абзацы.

Но на то он и view, что сами данные при этом хранятся в виде, удобном для поиска

Сорри, нельзя ли пояснить? Я до сих пор наивно полагал, что прототипы — лишь один из стилей ООП, а не альтернатива ему...

Есть мнение, что прибегать к денормализации следует в самом крайнем случае, потому что сделать что-то типа materialized view для ускорения выборки из нормализованной базы (или еще как-нибудь закешировать результаты этой выборки) зачастую проще, чем спешно приделывать костыли к разросшейся денормализованной, если этот поиск по видам деятельности ВНЕЗАПНО всё-таки понадобится...

troll, спасибо за поправку!

Зачем тогда перед этим указывать font-family и font-size, если font всё равно их сбросит? Может, планировалось всё-таки font-weight: bolder?

Два wmode с разными значениями — взаимоисключающие команды для браузера. Надо оставить что-то одно — нужное.

По логике, должно "ужирнять" шрифт по сравнению с предком (делать bold из normal-а и heavy/black из bold-а), попутно сбрасывая font-family, font-size, line-height и остальные шрифтовые свойства к браузерным дефолтам...

Мда, по-моему, на Хабре сделана глупость. Эти наборы ссылок явно больше похожи на обычные одноранговые списки с заголовками, а вовсе не на «значения» «параметров» Разделы, Посты и т.п. (и уж тем более «определения-синонимы» для них). Притянуть за уши логику «имя—значение» сюда, конечно, можно, но так ведь и любой текст с главами и подзаголовками можно в DL запихать (чем текст главы — не «значение» ее заголовка?)

На каком основании?

Я полностью поддерживаю такой подход. Но у меня складывается впечатление, что очень многие разработчики плоховато представляют себе этого "наиболее неопытного пользователя" — и за неимением реальной картины заменяют ее удобными для себя мифами. Например, представляют себе его этакой дрессированной крысой с примитивным рефлексом "вижу пальчик — можно нажимать, не вижу пальчика — нельзя нажимать". Тогда как по моим наблюдениям (да и не только моим) большинство таких пользователей (которые вообще чувствуют себя "не в своей тарелке" за компьютером и пугаются любых диалоговых окошек) не чувствуют границы между интерфейсом браузера и сайтом, для них нет никакой разницы между формой поиска Гугла на сайте Гугла, панелью поиска Гугла на панели браузера и даже адресной строкой (которая по умолчанию тоже ищет в Гугле, а в Хроме совмещена с панелью поиска by design). И мне странно бывает порой слышать, будто для таких людей будет "естественно", если в половине этих мест запрос будет отсылаться по нажатию "стрелочкой", а в половине — по нажатию "пальчиком". Интуиция упрямо шепчет мне, что принцип "лепи пальчик везде, так пользователю проще" придуман разработчиками именно для упрощения жизни себе — чтобы не думать о тонких различиях семантики () разных нажимабельных элементов, а "забота" о мифическом (?) пользователе-придурке — лишь прикрытие их собственной лени. Могу, конечно, заблуждаться...

Имхо, в случае, когда площадь самого поля раз в пять больше площади лейбла — толку от этого пойнтера меньше 20%. Нормальные люди всё равно будут кликать в само поле. А увидев рядом с полем (но не на самом поле) "пальчик", лично я бы первым делом подумал, что по клику выпадет какая-нибудь пояснялка (и сильно удивился бы расхождению ожиданий с действительностью). Хоть давно понял, что я в подавляемом меньшинстве, но всё равно не могу я понять и принять этой пальчиковой истерии. Все стандарты в один голос кричат, что "пальчик" — указатель ссылки, а не "кликабельности". Все стандартные контролы типа кнопок-чекбоксов-радиобаттонов-дропдаунов, что в ОС, что в браузере по дефолту — с дефолтным курсором, и покажите мне идио оригинала, который не поймет, что "туда можно кликнуть". А на тачскринах курсор как указатель на "нажимабельность" вообще неактуален, его попросту нет. Ну дайте мне наконец, пожалуйста, ссылку на серьезное исследование по юзабилити, обосновывающее, что этот "пальчик" на всех местах действительно чему-то/кому-то помогает...

wildhind, всего лишь попытка скаламбурить известное выражение с кол-вом открывающих <body>. Видимо, неудачная . Хотя больше двух раньше мне действительно не встречалось...

Самая кровавая страничка из до сих пор мной виденных, body count пока рекордный

В HTML5 <menu> служит прежде всего для создания собственных контекстных меню (работает в новых FF) и тулбаров (насколько я в курсе, нативно пока не работает нигде, но можно эмульнуть с помощью CSS). Нужен в основном для веб-приложений (напр. на dabblet-е он "в тему"). Как правило, описывает действия, которые можно совершать прямо на текущей странице, никуда не уходя. Навигация (<nav>) — как раз то, куда можно перейти (разделы сайта, подразделы статьи и т.п.), больше подходит именно для сайтов. Основной смысл группировки ссылок в <nav> — улучшение доступности контента (напр. возможность скринридера для слепых пропустить навигационную секцию, перейдя сразу к основному содержанию, а по команде пользователя вернуться к ней). В <header> тоже могут быть ссылки — на вводные/поясняющие материалы (инфо об авторе, ссылка на предыдущие публикации цикла, ссылка на оригинал для перевода и т.п.). Но вообще эта семантика — вещь достаточно гибкая, многое оставлено на усмотрение автора, так что надо руководствоваться здравым смыслом.

Просто <button> эквивалентен <button type="submit"> (только в IE7- было иначе). А type="button" (что для input, что для button) для того и нужен, чтоб кнопка была нажимабельной, но никаких действий с формой не производила. И в отправляемые из формы данные такие кнопки, по идее, попадать не должны (наскоро проверил в актуальном FF и трех режимах IE9 — не отправляет...).

Работает. В этом и весь фокус: при отключенном JS применяются дефолтные стили попроще, а при включенном — те, которые нужны для правильного отображения всего добра, завязанного на JS-функциональность. Причем применяются сразу, без "моргания" страницы в момент смены (как бывает с jQ-обвесками, подцепляющимися по domready).

или просто атрибут type="button" А что, обычные <input type="button"> отправляются? Где? И давно?