Универсальный способ декорирования блоков

В прошлой домашке я предложил читателям придумать способ вёрстки блоков со скругленными уголками и тенью. Если посмотреть на решения, то увидите, что большинство из них очень похожи друг на друга: 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 у абсолютно спозиционированных элементов. Примерный код может выглядеть так:

Если вы откроете пример в любом современном браузере, то увидите, что всё работает замечательно. Но ребята из Редмонда не могли пройти мимо такой халявы и решили усложнить нам жизнь своим продуктом под названием Internet Explorer 6, в котором:

• не работает растягивание с помощью top/bottom и left/right ;
• свойства bottom и right работают не правильно (позиция элемента отсчитывается от чётной ширины/высоты контейнера);
• полупрозрачный PNG нельзя наложить и позиционировать как обычный фон.

В принципе, все эти проблемы легко решаются с помощью 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 стороны. Например, можно плоскую и скучную обложку книги превратить в объёмную, как это сделано на сайте Аймобилко (правда, там используется немного другой способ из-за технических особенностей сайта):

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

Сергей вы как всегда красавец. Спасибо за намек по книгам.

мда… читаю ваши заметки и всё больше убеждаюсь, что веб становится всё уродливее изнутри и неповоротливей снаружи. Странные и изжившие себя стандарты с каждым годом усложняют жизнь тысячам(? может миллионам?) людей, а про рендеринг страниц в стиле «кто как хочет, так и дрочит» среди браузеров — я вообще молчу. И разработчики покорно молчат «ну да, ну не удобно, ну не совместимо, да отказываемся от многого, да тратим время и траффик на избыточны фичи». И вот чтобы сделать такую элементарную фишку как расписно выше — нужно изъеб….ся так, что всё желание разрабатывать сайт отвалится. А тут мало того что новые браузеры не совместимы, так ещё и некромантией надо заниматься для ie6… Тот же HTML5, который всё никак не разродится, тоже не будет решением. Да, он облегчит многое, но опять же не будет панацеей и каждый браузер будет показывать страницы как истинный художник-посмодернист «ниипёт — я так вижу мир, отстаньте от меня». В общем html5 это реактивный двигатель на Запорожце. Неужели нет силы в мире, которая перечеркнёт html на корню и создаст новый, компактный, модульный, расширяемый, быстрый стандарт для вебстраниц и напишет под него клиент с открытым исходным кодом, который станет референсным де-факто? И при этом напишет так, что любое отклонение от стандарта полностью делает страницу неотображаемой, дабы надавать сразу любым корявым рукам? Неужели этого никто не видит и надо раздувать и без того избыточный html код адскими конструкциями для совместимости с некробраузерами? Человек же животное такое — пока не ткнёшь носом «вот новый стандарт — остальное забудь», то будет и на 95й винде сидеть… Еж птица гордая — не пнёшь, не полетит. Так и тут. 🙂 Доколе это будет продолжаться. Ведь страдают как юзеры, так и разработчики.

Лично я проблем в самом HTML/CSS не вижу. Да, отчасти они избыточны, но они очень гибкие в реализации различных сложных интерфейсов. За удобство HTML/CSS говорит еще и то, что многие вендоры сейчас добавляют поддержку веб-стандартов для кастомизации своих продуктов. Например, новый Eclipse — e4 — можно будет расширять с помощью JavaScript, а внешним видом управлять через CSS. Для айфона гораздо проще, быстрее и дешевле сделать интерфейс программы на WebKit (то есть с помощью HTML/CSS/JS), чем через официальный Interface Builder.

А проблема кроется в программах, которые пытаются весь этот код понять (читай, веб-браузеры). И насчет раздувания HTML5 новыми элементами согласен — в этом плане я полностью на стороне Microsoft, который недавно подключился к разработке стандарта и раскритиковал его за обилие неоднозначных элементов. Если бы в мире остался один только WebKit — счастью моему не было бы предела 🙂

Но есть и обратная сторона: человек, который умеет делать грамотные и простые решения для разных браузеров, всегда сможет требовать больше денег за свои услуги 🙂

Кстати, раз уж такая пьянка, то было бы интересно посмотреть на вёрстку типичный балунов для Яндекс или Гугл.Карт. Я когда-то верстал балуны для Яндекса, но использовал там таблицы, поскольку бестабличное решение сильно бажило и было слишком напичкано expression’ами.

Главное условие — увеличение по содежимому от пимпочки (одна буква, одна строка) до целого блока (картинка, много текста), тень в спрайте, а центр позиционирования в правом нижнем углу.

В условии к домашнему заданию пишете: «…Итак, хороший способ должен работать во всех современных браузерах, включая IE6».

Теперь: «Если вы откроете пример в любом современном браузере, то увидите, что всё работает замечательно. Но ребята из Редмонда не могли пройти мимо такой халявы и решили усложнить нам жизнь своим продуктом под названием Internet Explorer 6».

То ли это такая терминологическая избирательность, то ли 6-й ИЕ перестал быть современным браузером где-то между 7-м и 20-м октября, то ли я чего-то не понимаю.

pepelsbey: кинь ссылку на конкретный пример, подумаем все вместе над решением

bes island: вообще, IE6 я не отношу к современным браузерам. Наверно, правильнее было бы написать «…хороший способ должен работать во всех современных браузерах, а также в IE6».

Сергей, вот пример: http://maps.yandex.ru/. Заходишь, тыкаешь на кнопку «Добавить метку» (вторая справа в ряду кнопок на карте), потом тыкаешь на карту и видишь балун.

Кстати, забыл дать ссылку на свой вариант решения задачи в стиле «а вот как это должно работать на самом деле» — http://pepelsbey.net/pro/misc/border-image/

Вызов принимаю, уже думаю над решением 🙂

хорошее решение, спасибо! про clip , к своему стыду, действительно не знал

pepelsbey, по содержимому это как раз мой пример из последней домашки.

GreLI: всё не так просто, есть нюансы именно в позиционировании блока в нужной точке.

Сергей, то что Вы привели примеры типа эклипса это только подтверждает мои мысли 🙂 Эклипс — прекрасный пример стандартизированной платформы, которая сама в себе и применение html+js в её рамках будет стандартом, который вполне обоснован. Извращаться в её пределах, как веб-девелоперы с браузерами, никто не станет: написал html елемент и он однозначно работает в рамках платформы без выкрутасов. Вот этого и не хватает в вебе, который как бы сам по себе масштабная платформа, но почему-то каждый дрочит… ну вы в курсе 🙂 Чтобы прояснить свою мысль представьте что VisualStudio введёт такую же поддержку html+js у себя и объявит совместимость с эклипсом (о боже!)? И вот тут начнётся ужас, когда разработчик расширения захочет малой кровью сделать плагин и для эклипса и для vs… Это то, что щас в вебе и творится — нет однозначности в реализации при вполне полной однозначности стандартов. И я думаю, что вы должны согласиться — html это язык разметки текста, а не фундамент для UI, RIA и ajax. Покажите мне хоть одного разработчика, который для создания UI и логики в своём софте будет всё лепить в ворде? Правда же нонсенс? Не, ну конечно оно-то можно… но каков результат будет? 🙂 То же и с html — слепить-то можно, но какой ценой и затратами 🙂 Про остальные платформы я так же думаю — пока платформа сама в себе и имеет свои стандарты, то в её рамках допустимы любые извращения html/css, но в рамках целой всемирной инфраструктуры такой бардак — это кошмар. 🙂 И кстати все они юзают html+css только потому, что альтернативы попросту нет 🙂

И тот же CSS более удобнее описывается sass на мой взгляд. Кстати для чего создавались различные фреймворки тима extjs? Xтобы отделить разработчика от трахания с неоднозначностью интрепретирования вебстандартов. B d частности я говорю о новом IBM-ском EGL (не вникал в него, но суть уловил). Значит необходимость всё же есть уйти от обычного html+js? В том же html, к примеру, я попросту ненавижу закрывающие теги. 🙂 нафига они такие избыточные? сколько терабайт по миру можно было бы съэкономить если бы в сайтах не было миллиардов ? Это к вопросу о том, что почему-то JS выглядит не так: , а гараздо лаконичнее function() 🙂 Нафига была эта избыточность? 🙂

Если бы вебкит был де-факто, то мир развивался бы иначе. 🙂 уже в 2000м были бы полноценные RIA c интегрированными svg, canvas и 3d (последнее кстати только в последних сборках вебкита есть уже)…

> сколько терабайт по миру можно было бы съэкономить если бы в сайтах не было миллиардов ? упс. тут html код был порезан 🙂 должно быть так: «сколько терабайт по миру можно было бы съэкономить если бы в сайтах не было миллиардов [/span][/div][/strong]?»

Сергей, обратите внимание на то, что в ИЕ6, если контейнером является таблица, то начинается бардак.

@stunpix интересно как ты себе представляеш без закривающейся конструкций такой код [div] [div] tesxt [/div] [div] yexy yexy [/div] [/div] в лучшем случаи yaml получиться

Увеличил размер спрайта, теперь должно быть нормально

@Andrii Kasian [div.header.selected: [div: tesxt] [div: yexy [bold: yexy] ] ]

вариантов куча и фантазировать можно долго и идти надо не по принципу «сделать подобие html, но в другом синтаксисе», а полностью избавится от html подобия и сделать что-то удобно сочетающееся с ajax, позиционированием элементов на странице, а текст в угоду интернализации можно опционально вынести вообще из разметки в отдельный модуль аля: [div: @text_ref ]

Только не стоит придираться к этим 3-ём строчкам, что тут так-то не то и это нельзя 🙂 это на вскидку придумано. и спецификации с кандычка так не решаются. 🙂

Кстати вопрос к Сергею как к эксперту, т.к. я долго бился в одном проекте над задачей, но так и не решил. Может есть идеи как граммотно решить? Дано: [div /> [div /> [/div]

позиционировать #b внутри #a таким образом, чтобы #a изменял свои размеры в зависимости от положения #b. т.е. #a как-бы резиновый и его размеры зависят от положения и размеров #b…

элегантного способа без js не нашёл… 🙁 как только #b объявляю position:absolute — #a тут же «схлопывается»… 🙁

забыл добавить… 🙂 кроме #b конечно внутри #a так же могут быть элементы влияющие на размер #a как и #b 🙂

Сергей, позиционирование в правой нижней точке можно сделать через врэппер с допустимой (максимальной) шириной и таким же отрицательным левым отступом, а затем позиционируя сам блок относительно врэппера: < bottom: 0; right: -45px >(значения подбираются).

Как я понял, проблема выставления блокам 1 и 2 нужной высоты в ИЕ решается тем, что там просто задана очень большая высота, и overflow:hidden на враппере? Интересное решение, я то пытался через одноразовый expression + обработчик onresize вычислять 🙁

И на .d-shadow стоит поставить background: white, чтобы все нормально отображалось без картинок.

А действительно ли использование одного огромного спрайта является лучшим в данной ситуации? Может быть, лучше использовать 2-3 маленьких спрайта?

Спрайт занимает от силы килобайт 10, и даже на модеме грузится 2–3 секунды, что сравнимо со временем четырёх запросов файлов (в сумме большего размера). А IE до 7 может делать только два запроса одновременно. На более быстром соединении выгода спрайта очевидна: один запрос — картинка мигом загрузилась. Только на сверхбыстром соединении с браузером и сервером, позволяющим много запросов будет всё равно. То есть практически только на локальном компьютере, ведь мы живём в реальном мире

И я думаю, что вы должны согласиться — html это язык разметки текста, а не фундамент для UI, RIA и ajax. Покажите мне хоть одного разработчика, который для создания UI и логики в своём софте будет всё лепить в ворде? Правда же нонсенс? Не, ну конечно оно-то можно… но каков результат будет? То же и с html — слепить-то можно, но какой ценой и затратами

Вот, кстати, хороший пример. У меня есть программеры, который пишут под айфон. Там в плане создания интерфейса всё очень просто: есть только два возможных размера окна — портретный и ландшафтный. То есть слепил один раз интерфейс и забыл. Сейчас они начинают писать под Андроид, и тут началась веселуха: устройств много, размеры экрана абсолютно разные. Они сейчас открывают для себя такую вещь как «резиновые макеты» 🙂 Да, у веб-разработчика это вызывает ухмылку, но для программеров это проблема, потому что нет нормального и просто инструмента для реализации такого интерфейса. И именно поэтому связка HTML/CSS очень выгодна и проста в реализации. Именно поэтому всё больше и больше вендоров начинают внедрять браузерные движки в свои продукты, потому быстрее и проще.

сколько терабайт по миру можно было бы съэкономить если бы в сайтах не было миллиардов [/span][/div][/strong]?

Мне кажется, что ещё больше терабайт можно сэкономить, если запретить торренты и прочий файлообмен 🙂 Но ведь это не повод их запрещать, не так ли? Так и в вебе: есть масса способов сэкономить на объёме сайт, но почти никто этого не делает. И проблема явно не в избыточности html.

позиционировать #b внутри #a таким образом, чтобы #a изменял свои размеры в зависимости от положения #b. т.е. #a как-бы резиновый и его размеры зависят от положения и размеров #b…

Я вот так сходу сказать не могу, если не увижу, что именно нужно сделать на макете.

Спрайт занимает от силы килобайт 10, и даже на модеме грузится 2–3 секунды, что сравнимо со временем четырёх запросов файлов (в сумме большего размера).