Как сказал Якоб Нильсен(Jakob Nielsen) в своей недавней статье«Computer Screens Getting Bigger» — экраны компьютеров становятся больше.(На что кстати сослался Лебедев =)).
Дословно, гуру юзабилити сказал следующее: "Дизайнеры должны начать экспериментировать со способами утилизировать горизонтальное пространство экрана, и создавать веб-страницы с улучшенным взаимодействием для людей с большими и широкоэкранными мониторами.(Они так же должы использовать методы, такие как responsive design, для продолжения поддержки маленьких экранов, которые будут с нами до конца десятилетия)".
И вот вопрос вам, дорогие читатели — как мы можем это сделать?
В моей практике, я использовала несколько простых приёмов:
Если у вас есть, каталог товаров — вы можете использовать float или inline-block, чтобы разместить их на экране.
Вы можете использовать css media queries или их js-эквиваленты, например чтобы сделать размер текста или картинок больше и т.п.
Вы можете просто задать свойства min- и max-width для вашей обёртки контента(такой как body). Я так делаю в вёрстке блога, чтобы задать размер статей между 1000 и 1200px по ширине, для меня 1200 — это предел читабельной ширины строки текста. Так же я делаю для магазинов, чтобы при разрешении 1920px они не выглядели плохо.
Если ваш сайт, на самом деле веб-приложение, например онлайн игра, тогда вам нужно принимать целый комплекс мер, который относится к разработке пользовательского интерфейса, особенно оптимизируя сайт под мобильные устройства, так что я спрашиваю не о них.
Так же потихоньку разрабатывается свойство css text-size-adjust. Говорят на уровне префиксов кроме мозиллы уже поддерживается в -webkit- и -ms-, возможно можно использовать его.
Итак, вы владелец сайта, например блога, такого как мой, или магазина. Если вам гипотетически потребуется оптимизировать его для использования на мониторах шириной 2000 или 4000px, что бы вы использовали?
Или, представьте, что все дисплеи в мире шириной 4000px(не говорим про планшетки), может ли это изменить всю парадигму сайтостроительства? Какие изменения в интерфейсе браузеров могли бы произойти?
У меня чувство досады от того что данные представлены в сети не в виде "данных". Что такое "данные"? Это то что может понять компьютер. ... Я хочу представить себе мир, в котором все разместили свои данные в сети. Тим Бернерс Ли(Руководитель W3C, 2009, конференция TED).
Семантическая вёрстка — это когда я верстаю таблицами и думаю о таблицах. Или что-то типа того. Алексей Шилов aka mr.troll.
Четыре года назад мы даже не думали о HTML5(а многие ждали XTML 2.0).
Три года назад нам сказали, что HTML5 непременно к 2020 году будут использовать.
Два года назад мы узнали, что HTML5 уже можно использовать.
Год назад оказалось, что HTML5 давно все используют.
Сегодня, всё что не имеет доктайпа <!doctype html> выглядит остатками мамонтов (и пахнет точно так же).
Html5 принёс нам много-много всяких спецификаций и технологий. И хотя главное назначение html5 — это расширение мультимедийных возможностей браузера(в черновиках html5 назывался как Web Applications), всякие video и audio теги, их кодеки, canvas и WebGL, инкапсуляция(sandboxing) ифреймов и объектов, и т.п. — всё это довольно скучные для обсуждения вещи. То, что действительно интересно обсуждать — это новые семантические теги — nav, article, section, header, footer, и дюжину других.
О семантических тегах
Неделю назад(точнее уже три недели назад) вышла статья "Let’s Talk about Semantics(by HTML5 Doctor)", я настоятельно рекомендую с ней ознакомиться прежде чем читать далее.
Вот топ 10 самых популярных значений атрибутов Name и Id :
Name attribute value
frequency
Id attribute value
frequency
keywords
2,189,708
footer
288,061
description
2,100,858
content
228,661
generator
943,496
header
223,726
robots
937,844
logo
121,351
author
818,017
container
119,877
movie
530,989
main
106,327
quality
504,666
table1
101,677
revisit-after
475,765
menu
96,161
copyright
423,210
layer1
93,920
progid
281,339
В своей статье, HTML5Doctor, нас убеждают в том, что основываясь именно на данных списках и были приняты решения о внесении новых тегов в спецификацию HTML5. Однако, из таблицы видно что это не совсем так. Я очень люблю id="footer" или id="content" — но я никогда не использовала id="article". Значение "article" — находиться на 186 месте в рейтинге значений класса и на 728 месте в рейтинге значений id. Т.е. данные атрибуты используют меньше чем 0.1% вебмастеров из статистики. Я считаю что это очень показательные цифры, я не могу понять почему html5doctor ссылается на них.
Так откуда же появились новые теги? Если ответить коротко — они просто придуманы редактором спецификации html5 Яном Хиксоном(Ian Hickson). Когда я спросила его об этом два года назад, он ответил примерно следующее:
Element names in HTML have little relationship to the usage of those names
in reality, to be honest. I wouldn't pay too close attention to the
meaning of the element names in common conversation; only their definition
in the spec matters. - Ian Hickson(16 Mar 2010)
Это честно. И вполне разумно. Я верю что Ян Хиксон проделал колоссальную работу по составлению списка данных тегов и максимально конкретных описаний и примеров к ним. Однако большой проблемой является то, что все веб-разработчики по разному понимают данную спецификацию(ситуация чем-то похожа на библию). Кто-то прочитал и понял неправильно, кто-то подумал что он понял правильно, у многих вообще не было времени чтобы прочитать её, но было время прочитать статьи популярных авторов которые писали о том как поняли они, и т.п.
Также есть множество веб-разработчиков, которые считают, что в вёрстке названия как-то связаны с той ролью, которую выполняет тег. Я сама вкладываю в термин "семантика" именно такое значение. Было бы логично предполагать, что если тег a — означает anchor, h1 — заголовок первого уровня, abbr — аббревиатуру, то и тег menu — можно было бы использовать для меню, nav — для любого обособленного блока со ссылками на другие страницы и навигации по сайту, header — как шапку страницы, article хмм... как статью, а section — какую-то часть содержания, например той же статьи. Однако же можно привести примеры вёрстки, где, по спецификации, данные теги будут обозначать совершенно другое, и наоборот, можно привести примеры, где все значения соответствуют совершенно другим тегам.
Например тот же Ян Хиксон не рекомендует использовать тег <menu type="list"> для разметки меню. Вместо этого советуется <nav><ul></ul></nav> и т.п. Так же по спецификации возможно не рекомендуется использовать <nav> для разметки такой навигации как "хлебные крошки" и формы поиска, хотя для меня это было бы семантично(о чём я не раз писала три года назад тут и тут).
Что же я думаю по поводу новых семантических тегов? У них есть ряд положительных свойств:
В будущем можно действительно улучшить обработку и индексацию данных тегов поисковыми роботами и другими программами.
Ну, по крайней мере это лучше чем div.
Но есть и ряд и недостатков:
Названия элементов — не связаны с их значением. Например article — это любой объект который сам по себе представляет какой-то контент, а section — это группирующий элемент, например когда нужно связать много <article> воедино.(Тут важно группировать по смыслу, а не как визуальную обёртку ). Вместо <article> безусловно лучше был бы <zoidberg>.
Никто честно не говорит вслух — почему верстальщик должен использовать семантические элементы вместо div? Единственный ответ — "для поисковых роботов". Самому верстальщику — долгие раздумья, над тем какой тег использовать, приносят больше вреда чем пользы, imho.(За исключением конечно того, что таблицы надо верстать таблицами, а списки — списками. Прочие тривиальные вещи объяснял, например, Вадим Макеев, однако его объяснение про html5 не очень внятное). Веб-браузерам довольно всё равно какую кашу из тегов написал верстальщик. Прочие браузеры, типа машин Брайля — в России например составляют 0% от общего числа. Поэтому вёрстка html5 тегов — важна для роботов, и только.
Описания довольно размыты и их толкование во многом субъективно. В html 4.01 было меньше разночтений.
Очень мало примеров. В идеале — нужно создать сайт, html5samples — где собрать типовые примеры вёрстки различных сайтов. Блога, Каталога, Магазина и т.п. С подсветкой при наведении того, какие теги использовались и описанием почему. Если бы были конкретные примеры — тогда бы и html5doctor.com был бы не нужен. Вот Bruce Lawson например сделал html5 тему для wordpress, уже хоть что-то.
В html есть клёвые "стерильные" элементы div и span названия которых ничего не значат.(С большой натяжкой div можно расшифровать как division). Я считаю эти имена лучше подходят для html тегов чем "семантические" названия.
WAI-ARIA и Микроформаты
Это совершенно другой путь развития смысловой аннотации содержания. Несмотря на то что он менее удобный — верстальщику приходиться полагаться на атрибуты, а не на сами по себе теги — данный метод позволяет точно добавить семантику. Например у вас был код типа
<div style="font-size:30px;">some big big caption</div>
Несмотря ни на что — это полноценная html разметка. А затем вуаля
<div style="font-size:30px;" role="heading" aria-level="2">some big big caption</div>
Разметка показывает, что теперь это осмысленный заголовок второго уровня(конечно для тех же целей есть <h2>).
Нет никакой иллюзии в том что они используются в основном для поисковиков и других ботов.
Описания микроформатов всегда конкретны. Т.е. на каждый случай — свой микроформат.
Они отлично документированы.
В составлении микроформатов(например от Schema.org) активно участвуют сами поисковые системы — как следствие они уже хорошо поддерживаются ими.
Их проще понять
Из недостатков:
Их сложнее запомнить(если под рукой нет ссылки на wiki)
Они занимают больше места чем теги.(Однако когда не было CSS, всевозможное оформление занимало ещё больше места в html коде).
Эксперимент
Итак... После статьи на html5doctor я решила поставить небольшой эксперимент, касающийся в основном html5 тегов. Я сделала вот такой макет страницы каталога онлайн магазина:
и спросила некоторых известных людей как бы они её сверстали, по пунктам. Текст письма был примерно такой:
I have a question about semantic markup online store pages .
I'm wondering which tags you would use for the following items(see
attachment picture):
1) a horizontal menu of links to different pages
2) the entire block containing the page header(logo, cart block, and a
horizontal menu).
3) the block containing the search filters(the most important
navigation in curtain shop)
4) one filters block
5) block containing shop items
6) block of one items(which includes photo, item title, etc.)
7) pagination
8) page footer.
Can I quote your answer in my blog?
Thank you.
Данный вопрос я послала разным веб-евангелистам. Многие конечно не ответили(например html5doctor, работа у них такая, не отвечать на вопросы) — это нормально. Однако не ответил кое-кто кто обещал — это досадно. Впрочем я не буду называть тех кто не ответил, лучше поприветствуем тех кто смог ответить. Итак:
Итак. Кто из моих дорогих читателей любит сложные задачи? В награду, обещаю вам большую статью с моими скучными рассуждениями о семантике html5-элементов в начале недели. =)
Задание простое, но интересное. Художница нарисовала рамку диалога, для новой онлайн игры.(ссылка http://usabili.ru/news_imgs/151/border7.png ). Требуется сверстать её на прозрачном фоне, примерно вот так:
Blablabla blablabla blablabla balballa bla abl abl
Какой-то текст диалога тут
Рамка должна растягиваться по высоте и ширине. Либо в зависимости от контента, либо при заданной ширине и высоте контейнера.
Не обязательна поддержка IE.(т.е. вы можете использовать любые современные CSS технологии: мультибекграунды, border-image и т.п)
Чем меньше html-тегов тем лучше(Надеюсь у вас получиться сделать что-то элегантнее чем таблица на 9 ячеек =)).
Чем меньше отдельных файлов графики — тем лучше.(ну, про "css спрайты" вы в курсе).
Без яваскриптов
Сам контейнер будет всегда с position:absolute(это может упростить вам задачу)
Через неделю подведём итоги.
P.S. Кстати я снова открыла комментирование статей без регистрации.
Неделю назад, мой друг и коллега Джелу спросил меня, как я отношусь к разметке Schema.org и правильно ли в целях продвижения использовать разметку для картинок которую предлагает яндекс в разделе справки — «Schema.org для Яндекс. Картинок».
Я до этого не обращала внимания что там нового у яндекса, а оказалось новый формат разметки они уже с ноября прошлого (2011) года поддерживают. А ввели его Google, Microsoft и Yahoo аж в июне. Что ж, обычные микроформаты сказала я, глянув один раз на пример. Глянув на пример второй раз я заметила что микроформаты как раз необычные. И более того, используют кажущуюся невалидной с точки зрения html разметку. Об этом я и хочу сегодня рассказать, надеюсь статья будет интересной.
Сегодня, мой друг и коллега Cavin прислал мне ссылку на статью с хабра — «Браузеры запутались в блочной модели для таблиц». Я считаю, что эта статья в полной степени показывает мои мысли о том, что в россии специалистов любого профиля очень мало.
Некий царь призвал трёх мудрецов и попросил объяснить следующий факт: «почему, если в кувшин, доверху наполненный водой, опустить рыбу, вода не выливается».
Двое мудрецов представили подробнейшее обоснование. Третий опустил в кувшин рыбу. И вода вылилась.
С наступающим, дорогие друзья!
Я так и не нашла силы побороть лень и дописать таки статью о вариантах комментариях, которую пишу уже месяца четыре. Думаю ничего страшного если она полежит у меня в запасниках ещё немного.
Сама статья бесспорно хорошая, в ней говорится вообще о том как писать быстрый код, почему селектор потомков медленный, почему селектор родителя был бы ещё медленнее, однако не говорится почему собственно есть хоть одна причина такой селектор не сделать. Да, это будет медленно. Да, всем понятно что селектор по id самый быстрый. Но в любом случае мы говорим о миллисекундах машинного времени. Обычно этим можно принебречь если сайт нагружен картинками и потоковым видео.
Собственно я бы не стала об этом писать если бы не прочитала ещё в сентябре черновик селекторов четвёртого уровня. Т. е. то, что мы будем называть CSS4.
Ссылка: http://www.w3.org/TR/2011/WD-selectors4-20110929/#overview
В самом низу указан родительский селектор: $E > F , который выбирает элемент E, родитель элемента F.
Кроме селектора родителя, конечно добавилось много других новых, клёвых селекторов, которые отнимут у Джонатана Снука ещё лишние секунды жизни.
Заключение
Безусловно, в тех проектах, в которых важна скорость работы в браузере — нет места подобным селекторам. Пример: проект, который я сейчас разрабатываю, расчитан на использования только в современных браузерах полностью исключая IE6-8, и возможно IE9 из-за их низкой скорости работы с dom; и тем не менее, в оформлении используются только селекторы id и класса; в яваскриптовом коде большинство селекторов заменены с jquery на нативные и т. п.
Т. е. каждый разработчик обязан представлять себе где и сколько времени отнимает выполнение его кода(css, js, html). Но при этом инструменты для того чтобы сделать«быстро и сразу» должны быть. Например на главной странице моего блога, менее 400 элементов в DOM, использование тормозящего селектора в данном случае вообще не будет заметно.
Здравствуйте дорогие читатели моего бложика, надеюсь среди вас есть css-профессионалы, поскольку у меня есть любопытная задача. Я обнаружила следующую реализацию свойства opacity в современных браузерах:
http://usabili.ru/labs/css_opacity_bug.html — посмотрите эту страницу, на ней видно что у абсолютно позиционированного элемента внутри с прозрачностью, не работает z-index относительно другого элемента с прозрачностью. Т. е. он оказывается под ним, и соответственно красная ссылка в нём не доступна для клика. Красная ссылка в этом примере обрабатывается так как будто имеет z-index:0 или даже меньше, хотя это не так. Причём, при убирании свойства opacity у любого из элементов, или при перемещении элемента со ссылкой из прозрачного — ссылка становится рабочей.
Всё что говорится по этому поводу в спецификации css3: «If an element with opacity less than 1 is positioned, the ‘z-index’ property applies as described in [CSS21], except that ‘auto’ is treated as ‘0’ since a new stacking context is always created. See section 9.9 and Appendix E of [CSS21] for more information on stacking contexts». В упомянутых выше ссылках я не смогла найти точного ответа. Чтобы разобраться я отправила письма Яну Хигсону (hixie), который рекомендовал задать вопрос в лист рассылки www-style@w3.org, и Дэвиду Арону (dbaron), который ответил в топике багзиллы.
Ниже я публикую ответ этой загадки (пока в непереведённом виде):
Май месяц выдался напряженным, многое сделано, а многое нет, причин почему я не писала в бложик называть не буду, придумайте их сами =). Но материалов как всегда у меня накопилось предостаточно, и, как обычно первым делом я пишу о том что сейчас актуально моим друзьям и коллегам.
В частности, полезным может оказаться один способ избавиться от дублированного контента в поисковой выдаче. Не секрет, что часто одна и та же страница оказывается проиндексирована под разными url, для того чтобы этого избежать можно использовать тег link, с атрибутом rel="canonical". Использование rel="canonical" — является более удобной альтернативой редиректам, с точки зрения поисковой оптимизации, к сожалению яндекс пока не поддерживает этот тег, но надеюсь будет понимать в скором будущем. Располагать его следует вместе с остальными в <head>, например примерно такой результат вы можете видеть если посмотрите в код текущей страницы:
Замечу, что курсивом в примере я выделила канонический урл этой страницы. Каноническим, называют url не какого-то чёткого вида, а того вида который вебмастер установил сам для себя. Важно придерживаться выбранному стилю во всём сайте. В этой статье я хочу вкратце рассказать какой канонический урл предпочитаю я, какой принят у нас в студии, и почему.
Сперва, должна сказать, что эффект как атрибута, так и стилей, у блочных и строчных элементов отличается. В частности если задать выравнивание блочному элементу, то это повлияет на расположение дочерних элементов в нём, а если задать строчному, то вертикальное выравнивание повлияет на расположение его самого, а горизонтальное вообще ни на что не повлияет.
Для блочных элементов атрибут align - аналогичен стилю text-align, для строчных - атрибуту float. Атрибут valign (который можно писать как align, при отсутствии оного), заменяет свойство vertical-align, только с немного другими значениями, смотрите ниже таблицу соответствий.
Горизонтальное выравнивание
Раньше, например для того чтобы центрировать какой-то элемент, использовани элемент <center>, потом такой простой и понятный элемент запретили, в пользу <div align="center">, потом запретили и атрибут align, в пользу css свойств text-align, float и margin.
Важно помнить:
text-align - в правильных браузерах не влияет на дочерние блоковые элементы!
Т.е <div align="right"> и <div style="text-align:right"> не одно и тоже. Свойство text-align не окажет влияния на дочернюю таблицу или div, тогда как align="right" - расположит все дочерние элементы справа, даже блочные.
Когда vertical-align задан ячейке таблицы - это задаёт расположение базовой линии текста относительно ячейки.
<td valign="top"> и <td style="vertical-align:top"> - одно и то же.
Аналогично с inline элементами. Поиск в гугле показал что:
<img valign="absmiddle"> означает <img style="vertical-align:middle">
Правильно кстати писать не valign, а align, однако любимый эксплорер в каких-то версиях понимает для align только центровку по горизонтали. Возможно это сделано для того чтобы была возможность задавать отдельно align (css text-align) и отдельно valign (css vertical-align)
Интересно знать такую таблицу соответствий , например применительно к <img> (указываю атрибут align, но подразумеваю valign):
align="bottom"
vertical-align:baseline;
значение по умолчанию, выравнивает базовые линии текста и картинки
align="baseline"
vertical-align:baseline;
то же самое
align="absbottom"
vertical-align:bottom;
выравнивает базовую линию картинки по низу текста
align="absmiddle"
vertical-align:middle;
выравнивает середину текста с серединой картинки
align="MIDDLE"
не имеет аналога
выравнивает нижнюю границу текста с серединой картинки
align="top"
vertical-align:top;
выравнивает по высоте самого высокого текста
align="texttop"
vertical-align:text-top;
выравнивает по высоте шрифта элемента родителя.
P.S. Не забывайте, что элемент <p> - является блочным, т.е. для форматирования текста в нём достаточно применять style text-align.
Итак, долгожданная статья. Вопреки заголовку свойства display:float здесь не используется, что не отменяет результата.
Неделю назад мне потребовался эффект для создания плавающих блоков фиксированной ширины, примерно как на картинке:
Если вы пробовали верстать что-то похожее, то знаете в чём подвох.
В общем случае, сверстать этот макет было бы плёвым делом. Фиксированная ширина, фиксированная высота, float:left и готово. Но! Дизайн требует чтобы количество контента могло варьироваться, что означает — если в одном из блоков будет больше контента, то вёрстка поедет:
Так как первый блок выше чем другие, пятый блок, обтекает его слева, вместо того чтобы быть ниже. Я потратила немало времени в поисках нужной реализации, и в конце концов вспомнила про свойство display:inline-block, кроссбраузерную реализацию которого, как оказывается, я ровно год назад утянула себе в закладочки. Далее — перевод этой статьи.
