веб-разработчик
Мы потихоньку переходим на Хабр с корпоративным блогом Аймобилко, где я и мои коллеги будем рассказывать о том, как создавались наши сервисы. Первая статья: рассказ про создание движка онлайн-читалки booq (так называется движок, сам сервис называется Айчиталка).
Пока пишу с корпоративного аккаунта, а если суппорт Хабра таки отдуплится и поправит баги, то буду писать со своего.
Одно из модных направлений веб-дизайна последних лет — оформление заголовков контрастным фоном. Например, вот так:
Простая, на первый взгляд, задача решается не так уж и просто: первая же мысль «добавить padding» натыкается на то, что отступ добавляется исключительно в начале и в конце текста, игнорируя переносы:
Ближе всех к решению задачи когда-то подошёл akella, добавив border у родительского элемента. Но проблема не решена на 100%: в конце первой строки (место, где переносятся слова) всё равно нет отступа. Решения остальных ребят, которые присылались мне в твиттер, грешили одной и той же проблемой: нужно точно указать место разрыва строк.
В простейшем случае, когда нужно добавить небольшой отступ, решение оказалось до боли простым. Есть одно «паразитное» CSS-свойство, от которого кодеры обычно избавляются — это свойство outline. Его особенность заключается в том, что во всех браузерах (по крайней мере в тех, в которых я проверял: Safari 4, Firefox 3.5, Opera 10, IE8) контур outline точно повторяет границы текстового элемента. Соответственно, эта строчка кода полностью решает нашу проблему:
span.uniform-bg {
outline: red solid 0.3em;
}
Не обошлось без ложки дёгтя: в данном случае «плохим мальчиком» оказался Firefox. Во-первых, он иногда рисует контур с небольшим отступом от границ текста, а во-вторых — прочерчивает его между строками, перекрывая текст:
Первая проблема решается довольно просто: достаточно немного «втянуть» контур с помощью CSS-свойства outline-offset (либо -moz-outline-offset, эксклюзивно для Firefox), вторая — добавлением ещё одной обёртки с position:relative, чтобы поднять текст над контуром.
Итоговое решение выглядит так:
<style type="text/css">
.uniform-bg {
background:red;
position:relative;
outline: red solid 0.3em;
-moz-outline-offset:-0.04em;
}
.uniform-bg span {
position:relative;
}
</style>
<h2><span class="uniform-bg"><span>Hello everyone</span></span></h2>
Оно не работает в IE6—7, в них не поддерживается свойство outline. Но, так как это исключительно декоративная задача, можно объединить её с решением от akella и получить почти идеальное решение.
UPD: читатель Roman указал на баг в отрисовке фона в месте переноса строк в IE6—7. Немножко доработать напильником — и получится вполне приличное решение (обновил пример).
Лично меня такой способ полностью не устраивает, так как есть ограничения на высоту строки (при больших значениях появляются проблемы между строками) и толщину контура (слишком толстый контур выглядит очень некрасиво). Предлагаю читателям подумать вместе со мной над более гибким решением, а также — совсем крутота — как такое же провернуть с фоном-картинкой.
Тот же читатель Roman предложил ещё один способ решения задачи. Он основан на смещении трех слоёв относительно друг друга: например, если отступ равен x, то второй слой смещается на 2x вправо, а третий на –x, влево:
Его можно немного упростить, убрав один слой и добавив левый border у контейнера. Способ более гибкий, чем с outline (который, как выяснилось, не очень дружит с Opera). На основе него я хотел сделать решение с фоновой картинкой, но столкнулся проблемой: вместе с переносом строк переносится и фон, то есть во второй строке фон начинается там же, где заканчивается в первой:
Решил я для очередного своего проекта воспользоваться модным CSS-свойством content, чтобы немного облегчить страницу и сделать настройку внешнего вида более гибкой. Так как проект ориентирован на веб-разработчиков, об обратной совместимости со старыми браузерами (IE6—7) можно было не беспокоится. Но, к сожалению, меня ожидало большое разочарование от использования этого свойства. Нет, всё отображалось правильно, но конечному пользователю было бы неудобно пользоваться результатом.
contentКому ещё не удалось познакомиться с этим замечательным свойством, кратко расскажу о нём. Само название этого свойства говорит о том, что оно управляет неким содержимым. Согласно спецификации CSS2 это свойство применяется только к псевдо-элементам :before и :after, а с версии CSS3 станет доступно и для обычных элементов (небольшой реверанс в сторону Opera, которая это уже поддерживает).
С помощью свойства content мы можем через CSS задавать текстовое содержимое для (псевдо-)элементов. Классический пример применения этого свойства — вывод содержимого ссылки рядом с элементом в версии сайта для печати:
<style type="text/css">
a:after {
content: ' (' attr(href) ')';
}
</style>
<p>В нашем <a href="/catalog/">каталоге</a> вы найдёте много чего интересного.</p>
С помощью псевдо-элемента :after мы задали некое содержимое после тэга <a>. Этим содержимым является результат конкатенации строк и функции attr(), которая выводит содержимое атрибута контекстного элемента. Браузер, полностью поддерживающий CSS2, изобразит этот код примерно так:
Интересующиеся могут подробнее почитать об этом свойстве в интернетах, мы же перейдём к сути проблемы его использования.
Так как для конечного пользователя результат работы свойства content выглядит как обычный текст, возникает вопрос: а может ли пользователь выделить и скопировать такой текст?
Проект, который я сейчас делаю, является инструментом для удобной работы с XML-документами. Для вывода раскрашенного дерева элементов я и решил воспользоваться вышеозначенным свойством:
<style type="text/css">
.tag:before {
content:'<';
}
.tag:after {
content:'>';
}
.attr-value {
quotes:'"' '"';
}
.attr-value:before {
content:open-quote;
}
.attr-value:after {
content:close-quote;
}
</style>
<div class="tag">div <span class="attr-name">class</span>=<q class="attr-value">demo</q></div>
Плюсы такого подхода: потребуется гораздо меньше элементов для раскраски тэгов (через псевдо-элементы :before и :after я могу задать произвольный цвет у угловых скобок). Для значений атрибутов я воспользовался тэгом <q> и CSS-свойством quotes, через которое определяются открывающие и закрывающие кавычки. Кому-то нравится использовать двойные кавычки в коде, кому-то — ординарные, при таком подходе их можно на лету поменять у всего документа. Как оказалось, выбор этого тэга и CSS-свойства стал важной частью эксперимента.
В браузерах этот код выглядит замечательно:
Но XML-документ должен не только красиво выглядеть, но и правильно работать: пользователь имеет право без проблем выделить и скопировать фрагмента документа, чтобы воспользоваться им, например, в своём любимом редакторе. И тут меня ожидало полное разочарование от использования свойства content. Я проверил результат копирования в своих браузерах — Safari 4, Opera 10, Firefox 3.5, IE8 — и получил вот такой результат:
div class=demo<div class="demo">div class="demo"<div class="demo">Как видите, все скопировали текст по-разному: Safari не скопировал content-данные в принципе, Opera и IE8 скопировали всё, а Firefox скопировал только кавычки вокруг атрибута.
Затем я решил вместо вместо элемента <q> написать обычный <span>, и получил вот такой результат:
div class=demo<div class="demo">div class=demo<div class="demo">Всё то же самое, но Firefox уже не скопировал кавычки.
Из этого небольшого эксперимента я сделал для себя следующие выводы:
quotes. То, что браузер отобразил кавычки вокруг <q> элемента — исключительно стандартная реакция на него. Кавычки нельзя будет поменять через свойство quotes, например, на ординарные — они так и останутся двойными. А если элемент переименовать в <span>, то и вовсе пропадут.<q> — кавычки скопируются, для другого элемента получите пустоту.<q>, даже если вы измените их на что-нибудь другое (на «ёлочки», например). То есть сделать трюк с управлением копирования символов у вас не получится. Либо двойные кавычки, либо ничего.display: list-item, то скопируется буллит (хотя на странице он не будет отображаться).В общем, выводы далеко не самые приятные. С помощью свойства content я не смогу сделать кроссбраузерное решение: и когда нужно копировать эти данные, и когда не нужно (например, нумерация строк в листинге кода). Как это часто бывает, радостные вопли неискушённых кодеров и красивые демонстрации маркетологов ломаются в момент «боевого» применения, когда нужно вкладывать смысл в свою работу, а не просто следовать модным тенденциям. Поэтому до сих пор приходится делать всё по-старинке.
В этой статье я поделюсь способом вёрстки растягивающихся сайтов (а других, как оказалось, я верстать не умею), которым пользуюсь последние 2—3 года. Этот способ применяется для сложных модульных сеток; он лёгок в применении, но сложен в понимании и у него есть ряд недостатков. В целом, представленная здесь информация пригодится и веб-дизайнерам, так как сам макет сайта должен быть правильно подготовлен.
Начнём с простого. Предположим, у нас есть вот такой макет растягивающегося сайт:
На первый взгляд всё довольно просто: типовая трёхколоночная сетка (ширина колонки — 25%), одна колонка — меню, две колонки — контент, и всё это располагается по центру. Типовая вёрсткой такого макета может быть следующей: заключаем оба блока в контейнер шириной 75%; меню в этом случае будет шириной 33%, контент — 67%. Саму обёртку выравниваем по центру с помощью margin: 0 auto, либо просто смещаем влево. Первый способ предпочтительнее, так как ведёт себя адекватно, если мы ограничим минимальную ширину обёртки. Визуализация этого решения:
Казалось бы, ничего сверхъестественного, задача решена. Но вот дизайнер вдруг захотел красиво оформить информацию в одном из разделов сайта, нарисовав выносной блок за пределами контента:
Причём дизайнер хочет, чтобы левая граница этого блока пиксель-в-пиксель совпадала с левой границей меню (оставим в стороне дебаты «кому это нужно» и «никто не заметит, если на пару пикселей…» в стороне, мы решаем конкретную задачу).
Тут мы приходим к самому главному правилу верстки макетов: контент должен находиться в едином потоке. Я не раз замечал, что ребята начинают верстать новые макеты, если контент вдруг становится многоколоночным или многоблочным. Начинают выделять новые информационные поля в админке, которые обязательно должны быть заполнены, чтобы страница получилось такой, какой была задумана. А если эти блоки вдруг располагаются в другом порядке — делают новые макеты и поля в админке, превращая сайт в помойку ещё до его выпуска.
Чтобы такого не получилось, нужно уделять максимальное внимание модульной сетке ещё на этапе создания первого макета. Считайте, что вы закладываете фундамент, от которого зависит, переживёт ли здание землетрясение, либо провалится после первого дождя. И обязательно добейтесь того, чтобы весь контент располагался в одном блоке, а не был размазан по всему макету: под меню, над футером, после шапки и так далее. Добьётесь этого — и стилизация контента станет минутным делом: в одном и том же макете собираете, как из конструктора, разные блоки в разном порядке, дописываете дополнительные стили и страница готова.
Но вернёмся к нашей задачке: как же расположить оранжевый блок так, чтобы его левая граница совпадала с левой границей меню? Мы уже решили, что этот блок должен быть частью контента, а не модульной сетки. Тем более, что блок контекстный (то есть привязан к какому-то определённому фрагменту текста, а не просто болтается где-то слева).
Ширина контента — 67%, меню — 33%. Чтобы блок встал ровно, его нужно сместить на 49.25% (33 / 67 * 100 ≈ 49.25). Во-первых, наш результат получился приблизительным, во-вторых, все браузеры (кроме Firefox 3) довольно своеобразно работают с дробными процентами (да и с процентами вообще), а некоторые вообще их не воспринимают. В итоге получается, что у нас нет кросс-браузерного способа совместить эти блоки при выбранной разметке.
Решением этой проблемы, как вы уже догадались, будет выбор другого способа разметки модульной сетки, который позволит нам вытворят такие (и не только) трюки. Посмотрим внимательнее на сам макет:
Внимательный читатель обратит внимание на то, что ширина меню ровно в 2 раза меньше ширины контента (50 / 25 = 2). Деление получается целочисленным (нет дробей), а значит мы можем создать кросс-браузерное и — самое главное — точное решение проблемы.
Поступим следующим образом. Завернём оба блока в контейнер, ширина которого будет не 75%, как раньше, а 50% (то есть равна ширине контента). Сам контент будет шириной 100%, а меню — 50%, при этом смещено влево на свою ширину.
Приблизительный код этого примера:
<style type="text/css">
#page {
position:relative;
margin:0 auto;
width:50%;
left:10%;
}
#menu {
width:50%;
margin-right:-50%; /* чтобы правильно в IE работало */
position:relative;
left:-50%;
float:left;
}
#content {
width:100%;
float:left; /* Новый контекст форматирования */
}
</style>
<div id="page">
<div id="menu"></div>
<div id="content"></div>
</div>
С помощью такой разметки мы можем легко решить нашу задачу с выносным блоком: делаем его шириной 50% и на эту же величину смещаем влево. Более того, с помощью такой разметки можно сделать более интересную вёрстку с выравниванием по основным трём колонкам:
Этот очень простой пример должен обратить внимание два ключевых момента такого способа вёрстки: выбор размера базовой колонки и выбор размера контейнера (точка отсчёта). Рассмотрим эти параметры чуть подробнее.
Чтобы лучше раскрыть потенциал этого способа, попробуем сверстать шестиколоночный макет:
Проблема в том, что 100 не делится на 6 без остатка (100 / 6 ≈ 16.66666), а дизайнер по-прежнему хочет выравнивать контентные блоки по границам основных колонок.
Одним из решений этой проблемы может быть следующее: сделаем размер контейнера равным ширине двух колонок. Размер внутреннего блока в этом случае будет равен 50%, что соответствует размеру основной колонки. А указав этому блоку margin-right:-50% мы уберём его влияние на поток по горизонтали: это позволит нам создать сколько угодно блоков в контейнере, каждый из которых будет влиять на его высоту, но не на ширину.
С такой разметкой мы получили равномерное распределение колонок, которое позволяет сосредоточить весь контент в одном блоке и точно позиционировать выносные блоки внутри него.
Если в предыдущем примере поиграться с размером окна браузера, то можно заметить, что во всех браузерах, кроме Firefox 3, появляются однопиксельные зазоры между некоторыми блоками:
Связано это с тем, как браузеры рассчитывают размеры процентных значений. Если вам нужна высокая точность в позиции и размерах блоков (например, когда они имеют чёткие границы), нужно разобраться, почему так происходит и как от этого можно избавиться.
Проценты — это относительная величина, которая пересчитывается в абсолютную — пиксели (ну хорошо, пиксели — это тоже относительная величина, которая зависит, например, от DPI экрана). То есть когда браузер видит, например, процентную ширину у блока, он должен рассчитать значение в пикселях относительно контейнера этого блока. Предположим, ширина контейнера равна 60 пикселям, а внутреннего блока — 50%. Ширина в пикселях этого блока будет равна: 60 × 0.5 = 30px. Значения красиво умножились/поделились. Но что будет, если ширина контейнера равна 61px? 61 × 0.5 = 30.5px — браузер не может отрисовать половину пикселя, поэтому он округляет это значение в меньшую или большую сторону.
На самом деле алгоритм гораздо сложнее: например, 4 блока подряд шириной 25% в современном браузере должны занимать 100% ширины контейнера; какие-то блоки будут меньше, какие-то больше. Мы же рассматриваем самый простой случай.
Итак, ширина блока получилась 30.5px, браузер для себя округляет её до 30px. Что будет, если в этот блок мы вложим ещё один, шириной 200%? По идее его ширина должна быть равна ширине контейнера, то есть 61px. Но так не получится, потому что абсолютная ширина промежуточного блока равна 30px, соответственно: 30 × 2 = 60px. Получили расхождение в 1 пиксель. Из всех современных браузеров правильное значение даст только Firefox 3: судя по всему, он где-то внутри хранит истинное значение ширины, от которого делает все расчёты.
Но! Обратите внимание, что абсолютная ширина нашего нового внутреннего блока всегда будет чётной. Например, если ширина промежуточного блока будет рассчитана как 31px, то внутренний блок будет шириной 31 × 2 = 62px. А чётные числа, как известно, делятся на 2 без остатка.
Соответственно, решением нашей проблемы с зазорами в шестиколоночном макете будет создание ещё одной обёртки, шириной в одну колонку, а внутренней обёртке задать ширину в 200%, чтобы получилась чётная абсолютная ширина у контейнера. Убеждаемся, что всё работает правильно.
Думаю, на данном этапе должна быть примерно понятна суть такого способа вёрстки. Ничего страшного, если сразу не получилось в нём разобраться: я несколько месяцев сам для себя не мог сформулировать его принципы. Кратко пройдёмся по основным моментам:
Самое сложное в этом способе — определить правильный размер колонки и точки отсчёта. Чтобы нагляднее продемонстрировать преимущества этого способа, покажу несколько примеров его применения:
Куда же без них. Самый главный — способ совершенно не подходит для макетов, которые должны растягиваться на всю ширину окна браузера. Из-за тех самых округлений процентных значений есть большой риск того, что какой-нибудь блок выйдет на 1px за пределы окна, создав тем самым горизонтальный скролл. Ещё кому-то может может показаться недостатком то, что размеры блоков меняются с шагом, больше одного пикселя. Ну и не забываем, что дизайнер тоже должен включить мозг перед тем, как что-то нарисовать. Хотя, конечно, если постараться, то можно сверстать и совсем экзотические варианты, выбрав размер колонки по-меньше (например, 10%).
PS: не стоит относиться к этому способу как к решению всех бед. Если есть паттерны программирования, придуманные для решения определённого круга задач, то описанный способ — паттерн проектирования, также направленный на решение определённого круга задач.
Представляю первую бета-версию плагина, который позволяет использовать мощь Zen Coding у себя на сайте без всяких плясок с бубном: Zen Coding for <textarea>. Название говорит само за себя: ZC работает прямо в <textarea>. Для работы достаточно подключить всего один JS-файл к себе на сайт.
Плагин использует технику под названием event delegation: вешаются события по отлову нажатий клавиш на родительский документ; когда пользователь пытается вызвать какую-нибудь команду (например, Expand Abbreviation), плагин проверяет, какой элемент является источником. Если это <textarea> — отрабатываем команду, если нет — просто пропускаем событие. Таким образом, никакой дополнительной настройки для работы плагина не требуется: подключаем файл и радуемся жизни.
Испытать плагин можно прямо на это странице в форме добавления комментария. Чтобы узнать допустимые сочетания клавиш достаточно кликнуть на иконке «Powered by Zen Coding» рядом с полем ввода.
Помимо основных возможностей Zen Coding плагин позволяет сделать написание кода в <textarea> гораздо более приятным занятием. Во-первых, можно задействовать клавишу Tab для разворачивания аббревиатур. Если аббревиатуру не получается развернуть, то добавляется символ табуляции (то есть просто делается отступ, как в обычных редакторах). Во-вторых, можно включить форматирование кода при добавлении переводов строк (нажатие на Enter). Новая строка будет добавлена вместе с отступом предыдущей строки, а если каретка находилась как раз между открывающим и закрывающим тэгом — будет добавлено дополнительное форматирование.
По умолчанию эти опции отключены, их можно включить одним из доступных способов.
У плагина есть ряд базовых настроек, которые можно в любой момент перекрыть. Все эти настройки записаны в переменной default_options файла manager.js:
'xhtml', доступны также 'plain', 'html', 'xml'.'html', доступно также 'css', 'xml', 'xsl'. Можно создавать свой синтаксис (см. zen_settings.js).Изменить настройки можно как глобально (применяются ко всем полям ввода), так и локально (применяются к конкретному полю).
Для глобального изменения настроек нужно вызвать функцию zen_textarea.setup(), передав ей параметры, которые нужно изменить. Например, для того, чтобы глобально включить использование клавиши Tab и форматирование переносов строк, нужно вызвать такой код:
zen_textarea.setup({
use_tab: true,
pretty_break: true
});
Для того, чтобы указать локальные настройки для конкретного поля достаточно указать ему класс вида zc-{название параметра}-{значение}. Например, для того, чтобы указать, что в данном поле нужно использовать синтаксис XSL, а также включить форматирование переносов строк, пишем вот такие классы:
<textarea class="zc-syntax-xsl zc-pretty_break-true"></textarea>
Также можно переназначить сочетания клавиш на более привычные, для этого есть методы zen_textarea.shortcut(keystroke, action_name) и zen_textarea.unbindShortcut(keystroke). В качестве аргумента keystroke отдаем текстовое описание сочетания клавиш, например Shift+Alt+D, в качестве аргумента action_name — название действия, которое нужно выполнить.
Для создания шорткатов можно использовать клавишу Meta: на Маке это будет означать Command, на PC — Ctrl. Полный список доступных действий и их шорткаты:
addShortcut('Meta+E', 'Expand Abbreviation');
addShortcut('Tab', 'Expand Abbreviation');
addShortcut('Meta+D', 'Balance Tag Outward');
addShortcut('Shift+Meta+D', 'Balance Tag inward');
addShortcut('Shift+Meta+A', 'Wrap with Abbreviation');
addShortcut('Ctrl+Alt+RIGHT', 'Next Edit Point');
addShortcut('Ctrl+Alt+LEFT', 'Previous Edit Point');
addShortcut('Meta+L', 'Select Line');
addShortcut('Enter', 'Format Line Break');
Как, наверно, многие догадались по постам на Smashing Magazine, Ajaxian и Хабре, вышел Zen Coding v0.5. Видео, описывающие прелести нового ядра:
Все видимые нововведения описаны на смашинге, посмотрим, что изменилось «под капотом»:
'img': '<img src="" alt=""/>'. Во время первого запуска парсер читает настройки и преобразовывает их в специальные объекты для быстрой работы. В данном случае важен синтаксис тэга: например, /> в конце определения означает, что тэг одиночный и не может содержать потомков. variables, в которой определяются переменные, подставляемые в аббревиатуры. Переменные подставляются как ${variable}, но есть ряд предопределённых элементов, которые имеют особые значения: ${id}, ${class}, ${child}. Переменные нужны для того, чтобы можно было быстро менять некоторые стандарнтные значения в аббревиатурах и сниппетах (например, язык). В дальнейшем планируется задавать свои переменные для отдельных проектов.id и class. Это можно увидеть на видео в самом конце, в примере с Django блоком. В сниппете можно указать, куда должно подставляться значение атрибутов id и class — получаем, таким образом, легко расширяемые сниппеты.extends, указывая через запятую языки:
'xsl': {
'extends': 'css,html',
'abbreviations': {
...
}
}
Буквально сегодня утром сделал объединил свою ветку разработки с транком, так что там теперь лежит последняя версия. Больше информации о Zen Coding (ну и на меня — красивого — посмотреть :)) можно увидеть в моём докладе на 404fest.
И, пожалуй, отвечу на самые горячие вопросы, от которых сегодня весь день отбивался.
Все очень хотят поддержку этого редактора, но проблема в том, что у него нет возможности добавить расширения через скрипты. Единственный известный мне способ расширить NP++ — написать плагин на C++, используя API редактора. На сях я не пишу, приложения под винду никогда не создавал, поэтому нужна помощь человека, который в этом разбирается. В идеале: нужно написать мост WSH-C++, который позволит писать расширения на JavaScript для NP++. Как минимум: предоставить простой API на JavaScript специально для Zen Coding, который я буду дёргать и говорить, что нужно сделать (опять же, с помощью WSH).
Да, в TextMate пока работает только разворачивание аббревиатур. Обёртывание аббревиатурами и выделение тэгов не работают — опять же, из-за ограничений API редактора. Но есть уже некоторые наброски решений этой проблемы (спасибо Антону Полещуку).
В прошлой домашке я предложил читателям придумать способ вёрстки блоков со скругленными уголками и тенью. Если посмотреть на решения, то увидите, что большинство из них очень похожи друг на друга: 4 элемента, разбросанных по углам, одинаково «необычный» вид картинки, небольшие различия в наложении блоков. Давайте рассмотрим подробнее, за счет чего работают эти способы, а также почему эта статья не называется «Создание скруглённых блоков с тенью».
Начать, в первую очередь, стоит с определения проблемы, которую нужно решить. Предположим, у нас есть блок со скруглёнными уголками и тенью:
Внутри блока есть контент неопределенной ширины и высоты, тень полупрозрачная; сам блок может иметь как заданную ширину (пиксели, проценты), так и автоматическую (width: auto). Наша задача: найти наиболее оптимальный способ вёрстки подобных блоков. Под оптимальностью я подразумеваю наименьшее количество элементов, наименьшее количество графических файлов, работа во всех современных браузерах, минимальное количество правок под конкретный браузер. Все эти принципы так или иначе влияют на производительность и надёжность нашего решения, особенно на крупных проектах.
Справедливости ради стоит отметить, что мы будем рассматривать неопределенность габаритов контента в каком-то определенном диапазоне, например, 1000×1000 пикселей. То есть я буду рассказывать про какие-то небольшие контекстные всплывающие блоки, которыми сейчас переполнены различные сайты. Если вам нужно будет, например, сделать тень у блока, в котором содержится основной контент сайта, то лучше выбрать другой способ.
Если присмотреться внимательно на пример выше, то можно сразу же найти простое и оптимальное решение: мы разделим наши декорации на 4 зоны, в каждой из которых покажем определенный фрагмент одной фоновой картинки:
background-position: top left;background-position: top right;background-position: bottom left;background-position: bottom right.Реализовать такую конструкцию — проще простого, но есть один нюанс: блоки должны растягиваться не на всю ширину контейнера, а на ширину контейнера минус ширина бокового блока (в данном случае это 2 и 4). То же самое касается высоты. Решается эта задача довольно просто. Не каждый знает, что задавать размеры блокам можно не только с помощью CSS-свойств width и height , но и с помощью комбинаций left/right и top/bottom у абсолютно спозиционированных элементов. Примерный код может выглядеть так:
<style type="text/css">
.shadowed {
position: relative;
left: 200px;
top: 100px;
padding: 10px;
width: 30%;
max-width: 450px;
}
.sh {
position: absolute;
background: url(./shadow.png) no-repeat;
z-index: -1;
}
.tl {
/* задаем высоту */
top: -6px;
bottom: 12px;
/* задаем ширину */
left: -11px;
right: 14px;
}
.tr {
width: 25px;
top: -6px;
bottom: 12px;
right: -11px;
background-position: top right;
}
.bl {
left: -11px;
right: 14px;
bottom: -16px;
height: 28px;
background-position: bottom left;
}
.br {
width: 25px;
height: 28px;
right: -11px;
bottom: -16px;
background-position: bottom right;
}
</style>
<div class="shadowed">
Hello world
<div class="sh tl"></div>
<div class="sh tr"></div>
<div class="sh bl"></div>
<div class="sh br"></div>
</div>
Если вы откроете пример в любом современном браузере, то увидите, что всё работает замечательно. Но ребята из Редмонда не могли пройти мимо такой халявы и решили усложнить нам жизнь своим продуктом под названием Internet Explorer 6, в котором:
top/bottom и left/right;bottom и right работают не правильно (позиция элемента отсчитывается от чётной ширины/высоты контейнера);В принципе, все эти проблемы легко решаются с помощью expressions и DD_belatedPNG, однако это слишком тяжеловесное решение для старичка IE6, особенно если таких блоков у вас будет несколько на странице. Попробуем найти другое решение этих проблем, заодно разомнём мозг.
Начнем с того, что придумаем другой способ растягивания блока по горизонтали. Попробуем задать первому блоку ширину в 100%. Получим вполне ожидаемый результат: блок растягивается на всю ширину контейнера.
Если же этот блок сместить влево на ширину декорации справа, то мы как раз освободим место для блока номер 2. А если родителю указать overflow: hidden, то выпирающий слева кусок первого блока не будет виден. Это именно то, что нам нужно: при растягивании контейнера оба блока будут занимать всю доступную ширину и нормально стыковаться друг с другом:
В примере выше есть одно упрощение: контейнер начинается там же, где начинается тень. На самом деле тень должна выходить за границы блока, и в данном случае это проблема: overflow отрежет саму тень:
Решить эту проблему, опять же, довольно просто: обрамим первый и второй блок еще одним блоком, которому выставим width:100%; overflow: hidden и верхний и боковые паддинги по размеру тени. Так как мы задали ширину, то боковые паддинги увеличат размер блока до нужных значений и наша тень будет полностью отображаться. А overflow: hidden с основного контейнера можно убрать, и это даст нам дополнительное преимущество: мы сможем разместить внутренний элемент за границами контейнера (например, кнопку закрытия).
Добавив padding у внутреннего контейнера, мы столкнёмся с тем, что первый блок будет меньшего размера, чем нам нужно. Но, опять же, так как у него задана ширина, мы можем «добить» ширину до нужного значения с помощью свойства padding-right:
Как вы знаете, полупрозрачные PNG в IE6 нельзя наложить в качестве фона, для этих целей используется фильтр AlphaImageLoader, который, к сожалению, нельзя позиционировать как фон. Но так совпали звёзды, что наше «необычное» растягивание блока из предыдущего шага поможет нам решить эту проблему. Первый блок мы сместили влево на ширину правой декорации, её же мы и отсекли. Соответственно, если мы перенесём правую декорацию в самое начало нашего спрайта, то мы сможем наложить одну и ту же картинку на оба блока:
Правая декорация у первого блока будет скрыта overflow:hidden контейнера, а ширина второго блока равна ширине правой декорации и покажет только её. А если перенести вверх еще и нижнюю часть, то мы сможем наложить один и тот же спрайт на все 4 блока:
Конечно же, первый и второй блок нужно будет сместить вверх на высоту нижней декорации.
Как я уже отметил, в IE6 неправильно работают CSS-свойства right и bottom, и для нас это проблема, так как мы имеем дело с полупрозрачными элементами. Любая нестыковка блоков даже в 1 пиксель будет сразу бросаться в глаза.
Свойство right исправить очень просто: достаточно вместо него воспользоваться margin-left:100% — это разместит блок ровно у правого края, а с помощью left можно подтянуть блок в нужное место. С bottom немного сложнее: я не знаю альтернативных путей, кроме как позволить самому контенту опустить этот блок до нужного уровня. На предыдущем шаге мы добавили обёртку с двумя блоками внутри, туда же мы добавим и контент. Под обёрткой разместим наши нижние блоки.
Эта обёртка и будет определять, на какой высоте окажутся блоки 3 и 4. Согласно спецификации CSS, элемент с position: absolute, у которого не указаны позиционирующие свойства — top/right/bottom/left — должен размещаться в том месте потока документа, где размещался бы статический элемент. Это очень удобно, так как благодаря этому можно делать различные трюки в виде выносных блоков, привязанных к определённому слову в тексте (например, смотрите выноску про Hyatt Hotel на сайте Башни Федерации).
У этой обёртки задан overflow: hidden, который выполняет 2 функции: скрывает ненужные куски внутренних декоративных блоков и задает контекст форматирования. Это значит, что никакие марджины внутри не будут выпирать наружу, что гарантирует нам точную позицию нижних блоков.
Если помните, мы убрали overflow: hidden у самого контейнера. Поэтому, чтобы растянуть блоки 3, 4 так же, как и 1, 2, нам, похоже, придется добавить еще одну обёртку. Однако есть одно CSS-свойство, о котором кодеры часто забывают — это свойство clip. С помощью него мы и скроем выпирающий левый край.
Надеюсь, вы поняли саму идею, за счет чего работает большинство решений, присланных пользователями. Кратко подведу итог: для верстки декорированных блоков понадобится 5 элементов и одна картинка. Элементы располагаются следующим образом: одна обёртка, в которой находятся левый верхний и правый верхний углы, а также контент. У этой обёртки выставлен overflow: hidden, который скрывает выпирающие части у декоративных блоков, а также задает контекст форматирования. Эта же обёртка определяет позицию двух нижних блоков по вертикали. Выпирающая левая часть у левого нижнего блока отрезана с помощью clip. Спрайт мы подогнали таким образом, чтобы нам не нужно было указывать background-position, который всё равно не сработает в IE6, так как там мы воспользуемся фильтрами. В этом спрайте мы как бы вывернули блок наизнанку, переместив нижнюю часть вверх, а правую — влево.
А вот и моё решение. Как видно из примера, решение полностью кроссбраузерное, для IE6 понадобилось всего лишь добавить padding у некоторых блоков (это можно сделать и с помощью одноразового expression).
С помощью этого способа можно декорировать любой блок, где надо равномерно покрыть все 4 стороны. Например, можно плоскую и скучную обложку книги превратить в объёмную, как это сделано на сайте Аймобилко (правда, там используется немного другой способ из-за технических особенностей сайта):
Единственный минус этого способа — сложность расчета паддингов у элементов: где-то нужно брать размер всей декорации, где-то только её часть. Но все эти расчеты очень легко алгоритмизируются, как бы намекая на то, что можно сделать удобный онлайн-сервис для быстрого создания декораций.
Во второй домашке приняло участие 11 человек, поэтому можно сделать мини-рецензии по каждому участнику. На этот раз победителя нет, так как большинство участников прекрасно справились с задачей (честно признаюсь, не ожидал такого) и каждый должен сам для себя выбрать оптимальный способ, исходя из своих отношений к IE6, который является главной головной болью при решении подобных задач. Всё-таки, его доля на рынке с каждым днём становится все меньше и меньше. Если чьё-то решение пропустил — пишите в комментарии, обязательно добавлю.
Результат домашки состоит из двух частей, вторую размещу завтра/послезавтра.
http://stanut.by/_/dz02/quad/ — 5 элементов, 1 спрайт, 1 expression для IE6
Хорошее решение, однако без одного expression не обошлось. Хоть он и кэширующий, даже простое обращение к свойствам DOM-элемента обходится довольно дорого.
http://stepan-reznikov.appspot.com/static/homework2-decor/index.html — 10 элементов, 1 спрайт
Решение получилось совсем без хаков для IE6 (фильтр AlphaImageLoader не считается), но смущает количество декоративных элементов — целых 10 штук.
http://chikuyonok.ru/u/hw2/daer/templates/round.html — 8 элементов, 2 спрайта, DD_belatedPNG для IE6, не зависит от высоты контента
Чем-то похоже на решение Стёпы, только элементов 8, а не 10, и используется два спрайта вместо одного. Однако это решение не ограничено по высоте, что является плюсом. Очень некрасиво моргает при ресайзе в IE6, требует много времени на инициализацию из-за DD_belatedPNG.
http://chikuyonok.ru/u/hw2/greli/homework2.html — 6 элементов, 1 спрайт, очень много исправлений для IE
Решение, в целом, неплохое, но очень сильно смущает обилие исправлений для IE — то, чего изначально нужно было избежать. Поддерживать такой код довольно сложно и трудоёмко. Однако решение интересно прежде всего тем, что GreLI виртуозно воспользовался багом IE для достижения необходимого результата:
В моём примере кстати вообще нет overflow. Для обрезания в IE6 используется то, что за пределами элемента с hasLayout отображаются только блоки с
position:relative. Ну или абсолютно позиционированные. Декоративные же либо позиционируются абсолютно с клипингом, либо проставленposition:static. Такое вот полезное применение бага.
Отсутствие overflow означает, что в блок можно поместить элемент, который будет отображаться за его пределами (например, кнопка закрытия окошка). Отдельный плюс GreLI за подробное комментирование кода.
http://test.kizu.ru/crnrz/var-1001.html — 6 элементов, 1 спрайт, много исправлений для IE
http://test.kizu.ru/crnrz/var-2002.html — 7 элементов, 1 спрайт, 1 expression для IE, много исправлений для IE, не зависит от высоты контента
Скептически настроенный kizu прислал целых два очень неплохих варианта, один из которых не зависит от высоты контента, что обошлось ему в один дополнительный элемент и expression для IE. Ну а само решение грешит теми же проблемами, что и у GreLI: большое количество исправлений для IE.
http://epoint-group.ru/css-work/round-corners/ и http://epoint-group.ru/css-work/round-corners-v2/ — 4 элемента, 1 спрайт, очень тяжеловесное решение для IE6, проблемы в Opera 10
Рекордсменом по экономии декоративных элементов стал frozenbear: его решение использует всего 4 элемента. Что вышло боком для IE6: мой бедный ослик сначала долго думал, открывать ли ему эту страницу, а после 2—3 минут раздумий таки очухался и показал решение во всей красе. А все из-за специального скрипта, который генерирует кучу блоков с фильтрами, тем самым сильно нагружая IE6. Кроме того, есть проблемы в браузере Opera с отображением инлайнового блока. Вывод: для Opera верстать сложнее, чем для IE6 
Но больше всего мне понравился подход к созданию спрайта. В первом случае у части изображения отсутствовала тень, что позволило наложить друг на друга две половинки одной картинки без ненужных перехлёстов полупрозрачных областей. Но у такого подхода есть один недостаток — максимальный размер блока ограничен только половиной размера изображения. Этот недостаток был исправлен во втором примере тоже довольно необычным способом: прозрачность тени была увеличена в 2 раза. При наложении друг на друга двух половинок спрайта тень получалась именно такой, какой была в макете.
http://chikuyonok.ru/u/hw2/ap/ — 6/5 элементов, 1 спрайт
Очень хорошее решение: минимум исправлений для IE6 (вместо height: 1%; можно было бы написать zoom: 1 в основном CSS), нет expressions. Практически полностью повторяет моё решение
http://chikuyonok.ru/u/hw2/vii/ — 5 элементов, 1 спрайт
Решение очень хорошее, особенно понравилось то, что декоративные элементы находятся рядом, а не разбросаны по всему блоку. Но маленький недостаток всё-таки есть: это необходимость указать отдельно для IE6 свойство clip.
http://rg-jam.ru/revers/block_shadow.html — 5 элементов, 1 спрайт, проблемы в Opera
Тут особо нечего сказать: минимум элементов, минимум правок для IE6. Очень хорошее решение. Но есть проблемы в Opera при отображении инлайнового блока.
http://chikuyonok.ru/u/hw2/sloter/ — 7 элементов, 1 спрайт, тяжелое решение для IE6 (VML, expression)
Для IE6 решение получилось чересчур громоздким: некэшируемые expressions для размеров блока, VML для отрисовки PNG. Всё это отрицательно сказывается на производительности.
http://olegkorovin.spb.ru/magicframe/ — 6 элементов, 1 спрайт
В сравнении с другими решениями, у Олега для декоративных элементов не используется position: absolute. У этих блоков относительное позиционирование, а нужного расположения блоков Олег добивается с помощью отрицательных марджинов. Довольно интересный подход, стоит обратить на него внимание.
Только в IE6 все довольно плохо: при ресайзе окна начинают пропадать блоки, не работает инлайн.
На этот раз домашка получилась именно такой, какой задумывалась изначально, а именно: обмен опытом при решении одной и той же задачи разными людьми. Лично я уже взял на вооружение некоторые приёмы, предложенные читателями. Большинство работ я комментировал очень кратко — всё потому, что у них используется одна и та же идея для организации элементов и спрайта, подробное описание которой — в следующем посте.
Из 27 присланных работ результаты разделились следующим образом:
В «Холодно» автоматически отправились все работы, где логотип находился между первым и вторым пунктом меню в HTML. Во-первых, это слишком просто и не интересно. Во-вторых — как правильно и своевременно заметил DeMx — такую конструкцию достаточно сложно сгенерировать на стороне сервера. Дело в том, что далеко не каждая CMS позволяет настолько легко вмешаться в генерацию стандартных компонентов. То есть упрощая себе работу на клиенте, сильно усложняем ее на сервере. Более того, в этом случае происходит смешивание данных и представления, а это вряд ли закончится чем-то хорошим. И если в контексте меню с логотипом особых проблем не видно, то в других ситуациях, когда дело будет касаться, например, контента и бокового меню — проблемы точно возникнут, в основном со стороны администрирования простым пользователем.
Соответственно, правильным решением было отделить меню от логотипа, что и сделали другие 7 участников. Практически все они поступили одинаково: сместили первый пункт влево с помощью right: 100%; margin-right: 5%, тем самым выполнив условие с одинаковым расстоянием между пунктами меню. Однако засыпались на условии соблюдения выравнивания логотипа по базовой линии. Большинство «на глаз» подобрало значение смещения в em’ах, однако это не дает точного результата на разных ОС и при произвольном размере шрифта.
Но два горячих парня — Ante и scorpix — решили поступить немного иначе. Правильно решив, что высокая картинка будет ровно стоять только на сплошной текстовой строке, они сделали все элементы инлайновыми. Scorpix просто написал все span’ами, а вот Ante сделал красивую и логичную HTML-конструкцию (которая совсем не понравилась IE и Fx2), превратив элементы в инлайн-блоки. Он и получает приз чикуёнковской симпатии.
Я в своем решении поступил точно так же, как и ребята из категории «Тепло» — сместил первый пункт меню с помощью right: 100%; margin-right: 5%, разместив логотип абсолютом поверх меню. До первого пункта меню можно добраться двумя способами: через селектор :first-child и одноразовый expression для IE, либо указав этому элементу особый класс (что я и сделал). Естественно, я столкнулся с проблемой выравнивания логотипа по базовой линии. Можно было просто указать приблизительное смещение элемента в em’ах, чтобы выровнять логотип по тексту, а все нестыковки при изменении размера шрифта назвать придирками. Но если вы хотите заставить вашего дизайнера биться в экстазе, я покажу вам простой трюк, который позволит точно выровнять логотип по тексту.
Так как логотип у нас находится в блоке и абсолютно спозиционирован, он никак не связан с текстом меню. Вы должны были заметить одну особенность: если достаточно высокую картинку разместить где-нибудь в середине текста, то она раздвинет строку по своей высоте.
Это не совсем то, что нам нужно: размер строки должен зависеть только от размера шрифта. Поэтому мы просто избавляемся от влиния высоты элемента с помощью отрицательного марджина (в качестве значения указываем высоту картинки):
Осталось, чтобы в нашем блоке с логотипом (он абсолютно спозиционирован, помните?) появилась полноценная строка. Для этого достаточно просто поставить пробел после картинки Смотрим, что получилось в итоге.
Скоро будет второе задание, на этот раз создадим что-нибудь полезное для общества.
Ну что, начнем делать домашки потихоньку?
Я сейчас делаю проект, в котором есть вот такое меню:
Вроде все стандартное, но за одним исключением: после первого пункта меню стоит логотип компании. Само меню набрано обычным шрифтом (Arial), а логотип — фирменным, поэтому вставляется картинкой. Дизайнер хочет, чтобы меню работало вот так:
Расстояние между пунктами — 5% от ширины контейнера, все выравнивается по базовой линии. Как бы вы это сверстали? Даю наводку: крутое решение должно выдерживать любое (в разумных пределах) изменение размера шрифта и требовать минимального вмешательства в серверную часть, которое все это генерирует.
Свое решение нужно выложить где-нибудь на сервер и запостить ссылку в комментариях (никаких архивов, ссылка прямиком на сверстанную страницу). Если выкладывать некуда — постите коммент и высылайте мне архив, я размещу у себя на сервере и поставлю ссылку. Итоги будут подведены через неделю, 4 сентября в понедельник, 31 августа.
Домашние задания даются, в первую очередь, для стимулирования работы мозга, поиска нестандартных решений простых, на первый взгляд, задач и повышения собственной квалификации. Тут нет никаких голосований, никаких накруток голосов, никаких оценок. Можно подсматривать решения у других ребят и дополнять их собственными мыслями. Не исключено, что одна и та же мысль может прийти в голову двум разным людям. Помните, что домашка делается для самого себя. Самые интересные решения будут рецензироваться.
Все публикуемые задачи на 100% решаемы — это значит, что у меня либо есть готовое решение, либо я знаю, как это сделать.