Seleckis.lv :: журнал Никиты Селецкого

Вёрстка в Латвии: Вчера. Сегодня! Завтра?

Никита — Thu, 27 May 2010 15:31:55 +0000

Версия моего выступления на Web Standards Days Riga 2010 вызвавшего неоднозначную реакцию.

Много было регистраций работников различных дизайн студий, компаний занимающихся разносторонней веб-разработкой, банков, министерств, фрилансеров и просто интересующихся. Я не зря добавил в форму регистрации поле для адреса сайта. Те люди, что собрались на конференцию, скромно говоря, флагманы, пионеры латвийской веб-разработки. Поэтому не грех было покопаться в их работах и попробовать понять, что же всё-таки у нас происходит с текущим использованием технологий?

Статистика вещь интересная, но только если она связанна с интересными темами. Мне было интересно заняться небольшим статистическим анализом, результатами которого я с вами сейчас поделюсь. Конечно в дебри я не полез, из-за большой лени, но то, чего успел накопать хватает достаточно, чтобы составить небольшую рекомендацию, с чего стоит начать осовременивать свою вёрстку.

Вчера

Итак, что же можно назвать «вчера»?

ASCII кодировка
Не использование DOCTYPE
DOCTYPE с указанием спецификации
Валидация ради валидации

Список можно продолжить, но мне лениво.

Кодировка

Для начала рассмотрим какие кодировки использовались на проанализированных сайтах.

Здесь всё замечательно, почти на всех сайтов используется кодировка utf-8. Это проще, чем подбирать для каждого языка свою. Здесь могу только посоветовать, тем 7 %, кто остался переходить на uft-8. Больше говорить не о чем.

DOCTYPE

Многие до сих пор не понимают значения доктайпа. Для того, чтобы это понять, нужно сначала обратиться к истории. Ну долго копаться в ней не будем, единственно упомянем, что существует два режима отображения веб-страницы — Standards Mode и Quirks Mode, ну так исторически сложилось. Первый — это режим отображения согласно веб-стандартам W3C, второй — режим поддержки старых сайтов, написанных в 90-е годы. Чем конкретно они отличаются читайте на W3C или в Википедии, ищите в Гугле… информации полно, но я на этом зацикливаться не буду. (Ну там ещё есть almost standards, который от standards почти не отличается)

Если вы не пишете доктайп, то включается Quirks Mode. Если пишете — Standards Mode. Но есть исключения:

Internet Explorer воспринимает декларацию HTML 4.0 и старее как Quirks Mode.
В случае с XHTML по правилам требуется xml-декларация. И её фактически никогда не пишут, поскольку из-за неё IE6 переключается в Quirks Mode.
Опера вообще не поддерживает Quirks Mode. Даже без DOCTYPE страница рендерится в Standards Mode.

Более подробные нюансы о QuirksMode можно почитать в Википедии.

Итог: Чтоб избежать проблем нужно использовать DOCTYPE обязательно.

DOCTYPE с указанием спецификации или валидация ради валидации

Теперь посмотрим как у нас обстоят дела с доктайпами на латвийских сайтах.

Великолепно! 68 % указывают XHTML декларацию. А теперь проверим, проходят ли они валидацию?

Внимание, вопрос! Зачем для сайтов указывать доктайпы со спецификацией, если валидацию они не проходят?

Если почитать спецификацию XHTML, то такой документ по сути должен передаваться в формате application/xhtml+xml. Это можно сказать «чистый» XHTML. Правильный. Мы все любим правильность и я в том числе, поэтому большинство сайтов написаны в формате XHTML. Там и правильные закрывающие теги и правильная вложенность и дубрирующееся написание значения атрибутов-флагов.

А на самом деле все передают такой документ в формате text/html. Почему? Во-первых многие не знают, что он должен передаваться как application, а во-вторых — незачем! Чаще всего модульные технологии расширения, для которых был создан XHTML, не используются. Ни прстранства имён, ни MathML, ни семантическая вёрстка через RDF и другие крутые вещи не нужны для создния веб-сайтов и сервисов.

Так зачем же мы пишем такой сложный Доктайп? И при чём он у всех такой разный. Он вам не нужен такой! Напишите его проще. Вот так:

Дело в том, что именно по этой части DOCTYPE браузер определяет, переходить ли ему в режим Standards Mode или нет. Указание дальнейшей спецификации и соответствующего адреса браузеру не нужно, он прекрасно справится. Спецификация нужна только для валидатора. Тем более что данная декларация, вот именно в таком виде уже включена в стандарт HTML 5 и тупые ошибки вы сможете определить W3C-валидатором.

Хорошо, допустим вы такой упрямый и всё равно считаете, что будете верстать в XHTML и указывать соответствующий доктайп, просто потому, что так правильней и можно проверить в валидаторе ту самую паранойю «disabled=”disabled”». Но на какой стадии вы это делаете? На стадии девелопинга! Так на продакшен-сервере, то он вам зачем?! Вот то-то и оно…

Холивар про «em vs. px» напишу чуть позже.

Восприятие информации по горизонтали и вертикали

Никита — Tue, 09 Feb 2010 08:51:28 +0000

Почему мы воспринимаем информацию слева направо и сверху вниз (как говорят некоторые «буквой Z»)? Правильно, потому что мы так пишем. Так пишет добрая половина человечества, а создатели компьютеров «навязали» такой стиль и восточным народам (хотя те и сопротивляются). А почему мы так пишем? Да потому что писать справа налево неудобно так же как писать левшам слева направо. Мы же себе строчку рукой закрывать будем!

«Лево-право, право-лево…» © Фунтик

Т. е. вывод какой? Виновата физиология, а не мозги (у востока — наоборот).

Посмотрим правде в глаза… человека:

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

В силу опять-таки особенности физиологии человеческого глаза, мышцы двигающие глаза по горизонтали гораздо сильнее (или более развиты, не знаю как правильно), чем те, что двигают глаза по вертикали. Иными словами, нам проще смотреть из стороны в сторону, чем сверху вниз (на самом деле всё ещё сложнее).

Веб-сайт — это прежде всего информация. И её расположение очень важно определить, основываясь на особенностях человеческого зрения. Информация на сайте должна структурироваться согласно логической связи различных объектов, которые эту информацию передают.

Допустим, имеем четыре колонки, чтобы всех их просмотреть и понять, что мне нужно, нужно сделать несколько резких движений глаз, причём не только горизонтальных, но и вертикальных, поскольку надо ещё и пробежаться в каждом блоке по вертикали.

В случае, если расположение информации у нас организовано не по колонкам, а по широким блокам идущим друг за другом по вертикали, то информация воспринимается более последовательно. Сначала просмотрели первый блок, потом второй, потом третий.

Это не говорит о том, что не нужно использовать колонки. Речь идёт о том, что в случае расположения разной по смыслу информации в колонках, требуют от пользователя большей концентрации на её поиск и фокусировку. Нам прийдётся совершать гораздо более сложные движения глаз, тем самым всё больше утомляя пользователя. Внимание будет перемещаться от объекта к объекту, согласно иерархии акцентов, расставленных с помощью контраста цвета, формы и размера. Вы наверняка замечали, что на новостных порталах в основном воспринимается только центральная колонка с основной информацией, о от остальных как-то абстрагируешься и не воспринимаешь их.

А если вы в колонках будете располагать связанную друг с другом информацию, то колонки начнут воспринимается как звенья одной цепи, например, перечисление возможностей конкретного продукта, перечисление элементов одного списка картинок, видео или пользователей.

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

Ещё использование колонок для разделения контента и инструментов (сервисов, пользовательского меню и т. д.) тоже является хорошей практикой.

Некоторые разработчики считают, что колонки справа можно использовать для размещения похожего или связанного контента. Конечно, это верно, но только лишь в том случае, если этот контент является основным на текущем портале и акцент на него нужно делать очень сильный, чтобы пользователь смог оторвать глаза от материала. Но тогда мы ухудшаем восприятие основного материала. А если там будет просто блок со списками статей, то никого он там не зацепит и будет висеть фоновым шумом.

В этой статье я прочитаю до конца (она ещё ниже заканчивается), а направо даже не посмотрю.

А что вы думаете по этому поводу?

Всемирная HTML 5 истерия

Никита — Tue, 25 Aug 2009 10:51:52 +0000

Я не знаю, об этом просто сейчас модно писать или народ действительно в восторге? На самом деле, я бы с удовольствием, присоединился к толпе ликующих, если бы событие произошло год назад, именно тогда я написал статью «HTML должен быть…».

Чему всё-таки радуется человечество? Например, одна из самых распространённых тем в блогах, это новые тэги: header, footer, nav, article, aside, section и др. Очнитесь ребята! Эти тэги можно было использовать с тех пор как регламентировали стандарт xhtml! Все бразуеры, кроме IE воспринимали их как строчные элементы, а с помощью CSS их можно сделать блочными.

Ну да, Internet Explorer… Но почему только когда официально консорциум объявил об отказе от XHTML 2.0 (кстати, я это пророчил), появился простой и понятный код, решающий эту проблему?

document.createElement("header");

Это тоже работа группы WHATWG?

Ах, да! Ещё и Firefox 2, в котором работают эти тэги, но только в режиме парсинга xhtml+xml. Это большая проблема, которая решилась переходом на FF3, а те два с половиной процента пусть думают, что сайт не работает, когда вы напишите « » вместо « ».

Почему зная решение, всё это не использовалось раньше? Ждали, пока FF3 заменит FF2? Ждали пока выйдет IE8? Ждали, пока дядя Тим во всеуслышание признает, что он как дурак 10 лет копал не в ту сторону? Ждали, когда Гугл официально объявит о поддержке новых тэгов HTML 5 (кстати, дайте источник, почитаю, а то всё слухи, да слухи).

Да, Гугл, позвольте вас спросить, а что будет если я напишу текст примерно так:


Название сайта

Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore
magna aliqua. 
Заголовок

Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur
sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

Это как-то по-другому будет восприниматься, по сравнению с той же структурой вписанной в

? Я не сеошник, но мне интересно.

Насчёт всего остального функционала предложенного в HTML 5, начиная от элементов форм, заканчивая «драгэнддропом», пока с мнением не определился. Но определюсь, напишу.

Seleckis’ method vs Pixy’s method

Никита — Sun, 16 Aug 2009 20:01:41 +0000

Честное слово, пытался найти и убедить себя в том, что этот метод уже существует. Не нашёл. Исправьте меня если я не прав.

Pixy’s method отображение картинок с надписями заключался в том, чтобы внутрь блока с текстом поместить пустой , и вставить картинку как фон для этого span-а. Причём, для того чтобы текст показывался в случае если картинки отключены, необходимо span поместить поверх текста.

В методе Pixy, для того чтобы с картинкой налез на текст используется абсолютное позиционирование. В таких условиях кнопка не может находиться в строке, она может существовать только как блочный элемент. Почему? Потому что Firefox 2 не поддерживает свойство «display: inline-block». Для отображения блока в строке в Firefox-е используется проприетарное свойство «display: -moz-inline-box» или «display: -moz-inline-stack». Но в таком случае браузер не совсем адекватно позиционирует помещённые внутрь элементы. В частности некорректно работает абсолютное позиционирование.

Задачи, с которыми я сталкивался в вёрстке, требуют гораздо более эффективного решения. Вот эти задачи на примере создания ссылки-кнопки:

Ссылка должна быть «инлайновая», т. е. чтобы можно было поместить в строке.
При отключенных картинках в браузере вместо кнопки должна быть надпись-ссылка.
У кнопки должен работать «ховер» — при наведении мышкой, картинка должна меняться.

Метод Селецкого (Seleckis’ Method)

Фактически тот же Pixy’s method, только:

используется строчный блок (inline-block),
помещается не после текста, а перед,
не налезает на текст, а текст подлезает под .

Ну а в качестве реализации «ховера» выступает обычный CSS-спрайт.

Итак HTML:

Seleckis

CSS:

.seleckis {
	/* только для FF2 */
	display: -moz-inline-box;
	-moz-box-orient: vertical;

	/* Для остальных */
	display: inline-block;

	line-height: 20px;
	text-align: center;
}
.seleckis span {
	display: block;
	position: relative;
	margin-bottom: -20px;
}
.seleckis,
.seleckis span {
	height: 20px;
	width: 74px;
	background-image: url(seleckis.gif) no-repeat top left;
}
a.seleckis:hover,
a.seleckis:hover span {
	background-position: bottom left;
}

Как видите, в этом коде сам блок становится строчно-блочным, а для FF2 срабатывает свойство «-moz-inline-box», что придаёт ссылке фактически такие же свойства. «-moz-box-orient: vertical» понадобится в том случае, если внутри блока вам нужно поместить содержимое в несколько строк.

Также, хочу отметить, что для элемента мы определяем относительное позиционирование и добавляем отрицательный нижний отступ размером с высоту кнопки, чтобы текст «подлез» под с картинкой. Кстати, картинка спрайта прописывается как ссылке, так и спану. Мало ли что…

Если будут баги, пишите попробуем решить. А так, в моём случае работает в Internet Explorer 6, 7 и 8, Firefox 2 и 3, Opera, Safari, Chrome.

Качем пример.

Min-width и max-width в IE6 с помощью expression

Никита — Thu, 06 Aug 2009 08:52:17 +0000

Уже писали много раз, просто приведу свой код.

В JavaScript-файле размещаем такую функцию:

function width(min,max){
	w = document.documentElement.clientWidth;
	return (w <= min) ? min + "px" : ((w >= max) ? max + "px" : "auto");
}

Функция всего лишь принимает значения максимальной и минимальной ширины, проверяет текущую ширину документа и возвращает значение:

Если ширина документа меньше минимальной ширины, то возвращается минимальная ширина;
Если ширина документа больше максимальной ширины, то возвращается максимальная ширина;
Иначе ширина указывается автоматическая.

Функция из CSS вызывается следующим образом:

div {
    width: expression(width(600,1000));

    /* далее для нормальных браузеров */
    min-width: 600px;
    max-width: 1000px;
}

600 и 1000 — минимальная и максимальная ширина. Поскольку expression работает только для IE, а min-width и max-width уже работают в IE7 и IE8, то этот CSS нужно изолировать и вынести в отдельный css-файл и подключить его с помощью условных комментариев, либо воспользоваться хакками, поскольку чтобы изменить значение придётся лезть в два файла, а не в один. Ну это уже как кому удобнее.

Скачайте пример и убедитесь, что всё работает.

Минимальную ширину в IE 6 можно эмулировать с помощью приёма, в котором указывается правый border для контейнера шириной в необходимую минимальную ширину элемента, а элементу задаётся правый отрицательный margin равный той же минимальной ширине. При этом внутренний элемент должен быть либо плавающим (float), либо inline-block. В общем не читайте и не внимайте в эти последние предложения, а просто посмотрите пример на cssplay.co.uk.

«Резиновое» поле ввода в форме

Никита — Fri, 31 Jul 2009 14:48:20 +0000

Как известно у полей ввода ширина не может рассчитываться автоматически относительно контейнера, как это работает у блочных элементов. Значение ширины можно задать фиксированное, либо относительное.

Есть сервисы в интернете с полями ввода (например, поиском) у которых ширина задана фиксированно. Соответственно, если шаблон сайта резиновый, то поле ввода растягиваться не будет. Как правило такие сайты имеют фиксированную вёрстку. К примеру, если вы зайдёте на «Yahoo Answers» и с помощью Firebug (Firefox), Web Inspector (Safari, Chrome) или Developer Tools (Opera, IE8) отключите у элемента

свойство «width: 750px;» в стилях, то сайт растянет на всю ширину, а поле поиска вопросов останется той же ширины. Конечно, кроме всего прочего, некоторые другие элементы останутся фиксированными, но мы говорим о полях ввода.

И вспомним работу студии Артемия Лебедева, поисковик «Яндекс» и его страницу ya.ru — облегчённую версию поисковика или посмотрим на давно забытый (мною) Рамблер. Вёрстка как видите «резиновая» и соответственно ширина поля ввода для поиска такая же растягивающаяся.

Как же они сделали так, чтобы ширина была динамичной? Очень просто: таблицы. Создаётся таблица из одной строки и нескольких ячеек, в одной из которых помещается поле ввода и растягивается на всю ширину.

Это простейший путь. Но не самый лучший.

Вариант получше

Начнём со структуры. особо наворачивать не будем. Чем проще, тем лучше.

Проще некуда. на самом деле можно было бы обойтись без лишнего div-а, если бы не Internet Explorer 6 и Firefox 2. Но об этом позже.

Перед описанием внешнего вида в CSS сначала нужно понять как предлагается решать задачу. Лучше всего показать схематически.

Из схемы видно, что предлагается контейнеру элементов формы добавить боковую границу шириной примерно равной кнопке отправки формы, а растягиваемое поле ввода предлагается растянуть на 100%. Ну и чтобы кнопка не перенеслась на следующую строку, контейнеру нужно запретить перенос строк.

.form fieldset{
	border: none;
	border-right: 90px solid #fff;
	white-space: nowrap;
}
.form fieldset .text-input{
	width: 100%;
}

Этого достаточно, чтобы форма правильно работала в Firefox 3, Opera, Safari, Chrome и Internet Explorer 8.

Для IE 6 и 7 нужно подправить отображение кнопки:

.form fieldset .submit{
	overflow: visible;
}

А для того, чтобы в IE6 и FF2 контейнер не растягивался так, что появляется горизонтальная прокрутка, нужно внешнему div-у прописать следующие свойства:

.form{
	overflow: hidden;
	width: 100%;
}

Вот и всё, теперь у вас есть бестабличная вёрстка растягивающегося поля ввода.

Скачайте и посмотрите пример. Он немного приукрашен.

Пара нюансов:

Вам нужно точно знать ширину кнопки.
Для
нельзя добавлять margin и padding по горизонтали, иначе будет сдвиг. Ну это вы и сами знаете.

Конечно же, никто не мешает вам добавить и левую границу и с отрицательным отступом поместить что-нибудь перед полем ввода (например логотип Яндекса).

Собственно, это я расписывать не буду, а просто посмотрите пример, как я сверстал ya.ru.

Элементы управления в веб-сервисах

Никита — Tue, 28 Jul 2009 12:29:41 +0000

В продолжение предыдущей статьи посвящённой организации навигации в социальных сетях, пройдусь по другим темам.

Существуют следующие виды элементов управления в веб-проектах:

Контент-ссылки
Контролы

Контент-ссылки — это те ссылки которые позволяют перейти на страницу с каким-либо содержимым. Они могут быть следующего вида:

Ссылки
Иконки
Ссылки с иконками
Кнопки
Табы
Навигационное меню

Контролы — это те ссылки, которые подразумевают какие-либо действия: добавить, удалить, изменить, искать, отправить и т. д. Внешний вид может быть:

Ссылки
Иконки
Ссылки с иконками
Кнопки

И кстати говоря, кнопки могут быть тоже разные:

С текстом
С иконкой
С текстом и иконкой
1. Иконка сверху
2. Иконка слева
3. Иконка справа

Также контролы можно классифицировать по эмоциональному признаку:

Позитивные
Негативные
Нейтральные
Бонусы

Их может быть и больше, но эти основные. Следующим примером иллюстрируются различия этих контролов по эмоциям:

Конечно пример утрированный, но это сделано для наглядности. Иконки, кстати, могут и не быть.

И конечно же, нельзя контент-ссылки и контролы оформлять одинаково.

Примеры того, как не надо делать:

Раз

Два

Три

Навигация веб-сервисов и социальных сетей

Никита — Tue, 17 Mar 2009 10:10:01 +0000

Меня удивляет непоследовательность разработчиков интерфейсов различных социальных сетей и веб-сервисов в организации навигации. Простая и понятная навигация встречается на очень редких сайтах. Это свидетельствует о том, что в разработке не участвуют специалисты по юзабилити, либо по каким-то техническим, экономическим, амибициозависимым соображениям их рекомендации не берутся во внимание.

Конечно я допускаю мысль о том, что часто изначально разработчики сами не знают какие функции будут доступны в их детище. Разработка циклична и возможно некоторые функциональные особенности будут со временем убраны или реорганизованны.

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

Как правило, социальная сеть состоит из пользователей, и содержимого, которое эти пользователи создают. Поэтому мы можем представить их взаимоотношение такой схемой:

Если раскрыть значение этих блоков, то схема приобретает такой вид:

Фактически мы говорим о том, что изначально пользователь выбирает, чей контент он хочет посмотреть: свой, своих друзей, групп в которых он состоит, или вообще публичный контент (это не всегда бывает). Причём здесь речь идёт только о контенте, который совпадает у всех «Кто?» есть на веб-сервисе.

Ну «со мной» всё понятно: я один и контент будет один. При просмотре контента друзей нужно сначала выбрать друга. Вариант классической «сборной солянки я не рассматриваю», поскольку это фактически является не частью костяка навигации, а всего лишь надстройкой. В группах то же самое — нужно выбрать группу, а потом её контент.

С «публикой» не всё так прозрачно, поскольку не существует универсальных механизмов выбора того пользователя, который нужен. Методов много, от банального поиска, до рейтингов, пузомеров, продвигаемых спонсорских групп и других. Поэтому метод выбора оставим абстрактным.

Что же происходит в различных социальных сетях? А сами посмотрите. Это вам всё для затравочки. Продолжение будет о том, как организована навигация, а в особенности контролы.

Строчная кнопка как кнопка submit

Никита — Sat, 28 Feb 2009 11:17:50 +0000

Требуется создать строчную кнопку submit неопределённой ширины с фоновой картинкой.

Почему это нельзя сделать стандартными средствами? Т. е. мы конечно можем поместить на страницу кнопку

и спокойно её использовать. Но нет, нам же этого мало. Нужно чтобы кнопочка была красивая, градиентная, с закруглёнными уголками.

Стандартным способом мы можем указать фон для кнопки, добавить рамочку и в браузерах FF и Safari добавить закругления. Но проблема в том, что это во-первых не будет работать в IE и Opera, а во вторых, размеры кнопочек, положение текста и отступы везде будут разные.

В FF2 вообще фон вылез за край закруглений.

Можно попробовать поместить кнопку submit в элемент span, чтобы использовать метод Sliding Doors. В этом случае можно будет без проблем поставить в качестве фона картинки как для элемента «span», так и для элемента «input». Но к сожалению и этот способ не подойдёт, поскольку нет возможности адекватно выровнять текст по вертикали.

Поэтому если визуальное представление гораздо важнее чистоты html-кода, то можно воспользоваться следующим методом.

Двойной «span» и элемент «input»

За основу возьмём статью о создании кнопки как ссылки. Поскольку в данном случае ссылка нам не нужна, то мы её заменяем на span, а внутрь второго span-а помещаем кнопку submit:

Кнопка как кнопка

Принцип Sliding Doors сохраняется и картинки кнопки помещаются в эти два span-а. Не забываем и про то, что кнопка должна быть уровня inline-block.

.input-button {
	display: -moz-inline-box; /* только для FF2 */
	display: inline-block;
	height: 20px;
	vertical-align: bottom;
	*vertical-align: middle;	/* только для IE */
	background: #83af31 url(button-r.gif) no-repeat right top;
	cursor: pointer;
}
.input-button span {
	display: block;
	_display: inline-block; /* только для IE6 */
	line-height: 20px;
	padding: 0 10px;
	height: 100%;
	color: #fff;
	background: url(button-l.gif) no-repeat left top;
	overflow: hidden;
	position: relative;
}

С кнопкой submit мы сделаем хитро. Разместим кнопку с абсолютным позиционированием относительно span-а поверх текста и сделаем её прозрачной. В итоге мы получим красивую кнопку с возможностями элемента «submit», ширина которой варьируется относительно текста помещённого внутрь.

Можно сделать размер больше, как изображено на картинке, но можно и 100% высоту и ширину. Код следующий:

.input-button input {
	position: absolute;
	top: 0;
	left: 0;
	height: 100%;
	width: 100%;
	cursor: pointer;
	opacity: 0;
	-moz-opacity: 0; /* видимо для старых версий FF */
	filter: alpha(opacity=0); /* только для IE */
}

Все методы представлены в этом архиве.

Cтрочная кнопка как ссылка

Никита — Mon, 02 Feb 2009 09:08:22 +0000

Урок-инструкция о том, как следует делать кнопки предназначенные для расположения внутри текста. Имеется в виду, что кнопка будет располагаться на базовой линии строки между словами. Вот так:

Если мы располагаем кнопку внутри текста значит ~~это кому-нибудь нужно~~ мы хотим на неё нажать. А для нажатия обычно используются такие виды элементов, как ссылка и кнопки формы.

В случае со ссылкой всё просто: помещаем среди текста ссылку и задаем ей фон. Но чтобы фон отображался и выравнивался корректно, ссылке следует добавить свойство:

.button {
	display: -moz-inline-box; /* только для FF 2 */
	display: inline-block;
}

Т. е. мы превращаем наш строчный элемент в строчно-блочный. Firefox 2 это свойство не поддерживает, поэтому указываем специальное специфичное свойство имитирующее строчный блок. Следующее за ним свойство предназначено для всех остальных браузеров. После этого можно задать фон для кнопки.

Что делать если нужно в качестве фона задать две картинки: левую и правую? Для так называемого эффекта «Sliding Doors», нужно как минимум два элемента.

Сначала я попробовал обойтись без лишнего элемента:

:first-line — не подходит, поскольку предназначен для элементов заведомо блочного уровня, и Опера сразу же переносит все слова в несколько строк и у ссылки пропадает фон.
:first-letter — не подходит, поскольку в Опере работает только для элементов заведомо блочного уровня
:before или :after вместе с content: ” ” — не подходят поскольку внутренний отступ (padding) у строчных элементов по вертикали в браузере Firefox отличается от Opera и Safari, а если превращать вставленный контент в элемент блочного уровня, то Firefox не поддерживает для него плавающий режим (float), а inline-block в Firefox позиционируется со сдвигами по вертикали.

Можно было бы использовать хаки, но кто гарантирует, что в других версиях браузеров они будут доступны? Единственное в чём я уверен, так это в необратимости работы хаков для IE 6 и 7 (Хотя мне недавно приснился сон, что IE 6 обновили, исправили ошибки и добавили табы…)

Псевдо-классы и псевдо-элементы я проверял только в браузерах Safari, Opera и Firefox 3. Если в них не удается правильно спозиционировать всё что я хочу, то в другие браузеры я даже не смотрю.

Итог: придется использовать дополнительный элемент.


…laboris nisi ut aliquip
	Кнопка как ссылка
ex ea commodo consequat…

Решение в CSS:

p{
	line-height: 20px;
}
.button {
	display: -moz-inline-box; /* только для FF 2 */
	display: inline-block;
	background: #83af31 url(button-r.gif) no-repeat right top;
}
.button span {
	display: block; /* нужно для FF 2 */
	display: inline-block; /* для всех кроме FF 2 */
	padding: 0 10px;
	height: 100%;
	background: url(button-l.gif) no-repeat left top;
	cursor: pointer;
}
.button:link span, .button:visited span {
	color: #fff;
	text-decoration: none;
}
.button:hover span, .button:active span {
	color: #dfd;
	text-decoration: none;
}

Некоторые пояснения:

Высота кнопки должна равняться высоте строки в этом тексте. Это обязательно, иначе будут проблемы с позиционированием картинок на фоне. Опять же, для корректного отображения фона в IE 7 следует для span тоже добавить высоту, можно равной высоте кнопки, а можно просто — 100% (Примечание: это не связано с hasLayout)
Для внутреннего элемента, сначала во всех браузерах применится «display: block», а потом, во всех кроме FF 2 сработает свойство «display: inline-block». Первое свойство будет корректно работать в FF 2, а второе — в IE 6, остальным браузерам всё равно.
Добавлено свойство «cursor:pointer», чтобы в IE при наведении на кнопку курсор стал «указующим перстом».

Развиваем тему…

Что если кнопке нужно добавить что-то вроде стрелочки, указующей куда-либо. Например вот так:

Во-первых, если делать для всех браузеров кроме IE, то лишний элемент добавлять не нужно, можно воспользоваться «:after» и вставить стрелочку таким образом:

.button span:after {
	content: " ";
	display: block;
	margin-top: -2px;
	width: 100%;
	height: 8px;
	background: url(button-arrow.png) no-repeat top;
}

Т. е. внутри элемента span, после текста вставляется абстрактный строчный элемент с пробелом в качестве содержимого, превращается в блочный элемент и чуть чуть поднимается вверх.

Схематически это можно изобразить так:

Но поскольку надо сделать так, чтоб работало и в IE тоже, то придется добавить ещё один лишний элемент, а кнопке стоит добавить дополнительный класс:


…laboris nisi ut aliquip
	Кнопка как ссылка
ex ea commodo consequat…

Позиционирование для добавленного элемента уже будет абсолютное и в CSS добавится следующий код:

.button.active {
	height: 20px;
	vertical-align: bottom; /* нужно для Opera */
	*vertical-align: baseline;	/* только для IE */
}
.button.active span {
	position: relative;
}
.button.active span b {
	display: block;
	position: absolute;
	left: 50%;
	top: 18px;
	margin-left: -7.5px;
	width: 13px;
	height: 8px;
	background: url(button-arrow.png) no-repeat top;
}

Итак, что же мы сделали:

Для класса «active» добавили высоту, чтобы высота кнопки не увеличилась за счёт добавленного элемента.
Туда же добавили вертикальное выравнивание по низу, чтобы в Opera из-за дополнительного элемента не возникло сдвигов. Отменили выравнивание по низу для IE с помощью хака. Другим браузерам по барабану.
Для элемента span добавили «position: relative», чтобы абсолютное позиционирование стрелочки было относительно элемента «span».

В готовом примере описание элемента «b» и хаки для IE были вынесены в Conditional Comments. Т. е. код почти валидный, не считая свойства «-moz-inline-box» для Firefox 2.

Вариант с кнопкой «submit» и «button», ждите в следующей статье.