SelenIT

Article, aside, nav — это, по сути, специализированные разновидности section, они, как и section, указывают место раздела в "оглавлении" (которое "document outline") и, вдобавок, раскрывают "природу" этого раздела. Article — самодостаточная публикация, aside — "вольные ассоциации" на главную тему, nav — основная навигация. И основная навигация явно не часть "вольных ассоциаций", а самостоятельный подраздел того же ранга. И, совсем по-хорошему, всем этим разделам нужны бы заголовки.

Такой подойдет. Но на мой взгляд, вариант с rgba (+ фильтр для IE, как и здесь) проще и логичнее, всё-таки фон должен быть фоном...

dostel1, не фурычит (в FF как минимум). Наследование opacity так легко не обмануть. Rgba — самый правильный вариант (не работает разве что в вымершей 9-й Опере, для IE 5.5-8 есть надежный костыль через filter). Альтернатива — фоновая картинка в png-24 (работает везде, кроме IE6, но ценой лишнего запроса к серверу).

Пресловутый "стандартный паттерн" для настоящего селекта включает в себя кучу нюансов, особенно с клавиатурой (активация по табу, листание без раскрытия стрелками и раскрытие Alt-стрелкой, и не только). Вне зависимости от технологии, это всё надо честно воспроизвести, иначе юзер будет раздосадован неполноценностью замены. С настоящим спрятанным селектом оно, полагаю, попроще, но эта простота о двух концах... А мультиселект, имхо, вообще абсолютно лишняя вещь. Давно известна полностью ему эквивалентная, но более удобная и легкостилизуемая структура, а с новыми браузерами ей и JS не факт что нужен (и это еще не предел)

Хм, формально по текущей спеке градиент-то, оказывается, вона что: Так что тупо по букве спеки "северная красавица", возможно, и права . Но здравый смысл отчаянно возражает. У меня не отображается при "No images", отображается при "Cached ..." наврал, при cached отображается только если перед этим картинки были включены.

Де-факто к тому уже и приходит. Взять те же структурные теги ЖHTML: <nav> отделяет меню от остального контента, а как его внутри разметить — воля автора. А где нужно выразить строго определенную, устоявшуюся семантику — есть микроформаты и микроданные, которые можно "натянуть" на любые теги...

Нужный и полезный, не спорю. Но крайне редко главный. Особенно для машинного анализа...

Потому что на практике это в 99+% не нужно, имхо. Всё-таки "крошки" — обычно вспомогательный элемент и не стоят такой возни. А гугловцы — в первую очередь расчетливые практики. Softlink, во-во Впрочем, вложенные спаны, как компромисс (устранение неоднозначности структуры для машинного разбора при минимальной избыточности разметки) — тоже неплохо (а с RDFa — и подавно).

На вложенных UL-LI, типа такого: <ul> <li><a href="/">Home</a> <ul> <li><a href="/articles/">Articles</a> <ul> <li><a href="/articles/file.html">Title</a></li> </ul> </li> </ul> </li> </ul> Чисто семантически, имхо, действительно так.

Как обычно, оказалось, что в забугорнете тема была раскрыта аж в 2004-м году Пришли к практически тем же выводам, что и мы здесь (кажется): т.е.

Почему жалкая-то? Одна задача — одно решение...Про неидеальность PMA и ГМыла не спорю, но здесь упомянул их исключительно в плане (не)уместности и (не)ожидаемости ссылочного курсора на их элементах (мой личный user experience по этой части). А какая версия ГМыла была самой простой для понимания?

Имхо, да.

Полностью согласен насчет сайтов, вынужден поспорить насчет интерфейсов веб-приложений. Для традиционных сайтов, да, ссылки — чуть ли не единственная доступная интерактивность. Но вот, например, панель WYSIWYG-редактора — там кликабельных элементов не то что 90%, а чуть не 98:) И это очевидно без всяких выкрутасов (другое дело, часто нужна подсказка, что именно делает та или иная кнопка, но такие подсказки есть в тултипах). Еще пример — phpmyadmin. Казалось бы, везде "пальчики": что в списке таблиц в левом фрейме, что в заголовках для сортировки, что в верхнем меню. Но практически все эти элементы — настоящие ссылки (можно открыть, скажем, структуру таблицы в новой вкладке, не теряя вкладки с ее содержимым, то же самое можно делать с заголовками столбцов для сортировки и т.д.). Хотя львиная доля площади занята управляющими элементами, эти элементы не ломают стереотипы веб-юзера, а напротив, используют эти стереотипы для дополнительных возможностей. Как пример эталонного интерфейса веб-приложения нередко приводят GMail. Смотрю сейчас на свой корпоративный — в целом и впрямь логично: объекты (напр. папки в почте) — ссылки (можно перейти в папку в этом же окне, а можно открыть ее в новой вкладке), а действия с объектами (написать письмо, пометить как спам, удалить и т.п.) — кнопки, реализованы на дивах, на наведение откликаются подсветкой, но под ссылки не мимикрируют и паттерн не ломают . Вот то, что отдельное письмо я почему-то не могу открыть в новой вкладке/окне (ссылка же вроде!), не теряя из вида списка, несколько напрягает. Кстати, ЕМНИП, какое-то время GMail-овцы экспериментировали, делая все кнопки с "пальчиком", но в итоге, судя по всему, от этого отказались. Мне кажется, уж где-где, а в Гугле юзабилити-тестирование должно быть на уровне... Воистину так . Но вопрос, для кого что является привычками. Судя даже по результатам этого опроса, для более чем половины небезразличных привычно "раз кликабельно, значит, должен быть пальчик". А для меня (и не только) как раз это вызывает диссонанс, для меня привычно "раз пальчик, значит ссылка со всеми вытекающими" . Вот как бы набрать приличную статистику среди обычных юзеров, тех самых "домохозяек", а не разработчиков...

bayanruby2, аутлайнер строит для этой разметки такое "оглавление" (outline):

Фух, выходит, я не один

В том-то и дело, что у меня, когда я натыкаюсь на ссылочный курсор у нессылки, стандартный паттерн рвется... Напротив, когда я вижу элемент, который выглядит как кнопка и при наведении подсвечивается как кнопка, у меня срабатывает стандартный паттерн для кнопки и мне плевать, какой у нее курсор (хотя "некнопочный" курсор чуть-чуть прибавляет сомнений). Это я один такой ненормальный, что ли?

Но всё-таки, почему? Причем, AFAIK, только в вебе, что характерно...

А вот у меня когнитивный диссонанс возникает, когда я вижу "ссылочный" курсор и не могу применить к этому объекту никаких ссылочных действий (подсмотреть в статусе, куда эта ссылка ведет, открыть ее в новой вкладке мидл-кликом, скопировать адрес и т.п.). К тому же нигде за пределами веба ссылочный курсор для кликабельных элементов не встречается (припоминаю только вариант настройки какой-то редакции Win98, отображавшей ярлыки ссылками — с "пальцем", синим подчеркиванием и открытием одиночным кликом — но это было жутко непривычно и неудобно, потому и не прижилось). У кнопок на панели браузера — дефолтный курсор, у системного меню — дефолтный, почему же в окне браузера правила меняются? Откуда вообще пошла эта традиция? В спецификации (что CSS 2.1, что CSS 3 Basic UI в статусе CR) вроде бы четко написано, что То, что кликабельные элементы должны как-то визуально реагировать на :hover и :focus/:active — это само собой. В нетривиальных случаях, имхо, нелишним будет тултип (title). Согласен, что изменение курсора тоже своего рода подсказка. Но почему именно тот вид курсора, от которого ждешь вполне определенного поведения — и эти ожидания обманываются? Для себя я вижу лишь две причины, почему веб стал "тыкать пальцем" везде, где кликабельно. Главная — то, что из-за убогой реализации кнопок в HTML, не позволявшей толком их стилизовать, вебмастера долго были вынуждены реализовывать чуть ли не все дизайнерские фантазии "про интерактивность" через ссылки (обычно с href="#" onclick="...", или, того хлеще, href="javascript:..."), а сменой курсора никто не заморачивался — вот и выработалась привычка. И мелочь — Flash, в которой почему-то курсор "пальчиком" изначально был сделан признаком "нажимабельной" кнопки. Имхо, этого явно мало, чтобы повально использовать этот курсор вразрез со спецификацией и устоявшимися стереотипами системных GUI (что мы наблюдаем). Какая же еще причина упорно ускользает от моего внимания? А теперь, в эпоху наступления тач-скринов, роль курсора как "признака нажимабельности", имхо, вообще должна круто пойти на спад, настоящему пальцу ведь нарисованный не покажешь, там кликабельность должна быть очевидна из общих соображений. А раз такое в принципе возможно, надо ли плодить путаницу с курсорами?

Упс, и действительно (странно!). Ну тогда вариация на изначальную тему — filter:alpha(opacity=0);background:#fff. Это вроде работает во всех режимах (IE9/8/7)...

Нет, имелся в виду filter:progid:DXImageTransform.Microsoft.gradient (startColorstr=#00000000, endColorstr=#00000000) — как заменитель этого неработающего "#rgba".

В связи с обсуждением верстки форм вспомнился старый холивор. Интересно узнать мнение профессионалов в 2011 году. Как всегда, рассчитываю как минимум на обогащение моей head { content: '' } чем-то новым, а как максимум — на рождение той самой истины (которая "где-то там")...

Ну, пардон. Просто не могу спокойно смотреть на такую вивисекцию. Это ж всё равно, что пихать еду в брюшную полость снаружи желудка...

Нет доктайпа — нет и варенья новых модных функций Фиговатый костыль, вообще-то, лишний запрос к серверу — лишняя нагрузка на оный и тормоза при загрузке. Еще about:blank в этом качестве — куда ни шло, но всё равно "некузяво"... Аналогично, зачем лишний запрос, где прекрасно живется без него? На крайняк, можно использовать фильтр для полупрозрачности — он и в IE5.5 работает как надо

Что делает <div class="content-midl"> между <tr> и <td>? P.S. А вообще давно у нас экраны меньше 1680px стали неактуальными?

Честно говоря, лично мне как раз стереотип ломает cursor:pointer для нессылок. Когда я вижу "пальчик", я жду от него возможности открыть в др. вкладке (по мидл-клику) и/или специфического ссылочного контекстного меню. Нативные контролы — что select, что button/submit/reset, что checkbox/radio вместе с их label-ами — по дефолту отродясь мне пальцем не тыкали (равно как и подобные элементы интерфейса ОС), почему же их дизайнерские функциональные аналоги тычут? Я понимаю, когда pointer ставится на совсем неочевидные дизайнерские примочки в виде точечек и облачков, чтобы хоть как-то показать их интерактивную природу, но визуальной похожести на "беспойнтерные" нативные аналоги, имхо, достаточно и без этого. Хотя я уже привык, что по этому вопросу я вечно в меньшинстве, так что это я так... просто поворчать