CSS

«Старый» и «новый» Flexbox

От редакции css-live.ru: Flexbox — один из самых ожидаемых «раскладочных» модулей CSS3, но с непростой судьбой. Мы уже писали о нелегких приключениях этой спецификации. В последнее время интерес к этому механизму особенно вырос, благодаря тому, что новый синтаксис уже поддерживается в Chrome 21+ и вот-вот начнет поддерживаться в Опере. Но изменения спецификации привели к огромной путанице как в учебных материалах, так и в справочниках о браузерной поддержке, и разобраться, где о какой редакции идет речь — об актуальной или об устаревшей — очень непросто. Надеемся, что эта статья Криса Койера поможет вам сориентироваться во всей этой путанице.

Перевод статьи “Old” Flexbox and “New” Flexbox с сайта css-tricks.com, автор Крис Койер, переводчик Илья Стрельцын

7 августа 2012 г.

Просто ради того, чтобы прояснить для всех: «Flexbox» (точнее, CSS Flexible Box Layout Module — модуль «гибкой» раскладки) претерпел за последних три года много изменений. Изменений как в спецификации, так и в том, что реализовано в браузерах.

Размытый текст

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

Обзор: Инлайновый контекст форматирования

Эта книга, написанная создателями css-live.ru (Максимом Усачёвым aka psywalker и Ильёй Стрельцыным aka SelenIT), посвящена одной из самых важных и вместе с тем самой загадочной, неизученной, неоднозначной и полной неочевидных сюрпризов стороне действующей спецификации CSS — визуальному форматированию текста.

Эволюция CSS-вёрстки: с 90-х в будущее

Ранее в этом году меня пригласили выступить в Филадельфии на конференции «Новые технологии для предприятия». Я не думала, что смогу рассказать что-то полезное на такой конференции, не будучи практикующим веб-разработчиком, но посмотрев презентацию мероприятия, заинтересовалась; тем более, я знаю, что могу выступить хорошо. В общем, я согласилась. Люблю Филадельфию. :)

По некоторым темам конференции (например, «Как предоставить хороший баг-репорт») я бы могла соорудить несколько слайдов и вскользь упомянуть о них. Но так не годится. Я посвятила много времени подготовке, в течении нескольких недель выписывая мысли на бумагу — я «аналоговый», пишу руками.

После конференции, организаторы выложили скринкаст моего выступления, так что теперь каждый может посмотреть его в сети. Если вы активно интересуетесь эволюцией вёрстки (или если вы любитель видеороликов и предпочитаете аудио чтению), я настоятельно рекомендую вам ознакомиться. Обещаю, будет интересно:)

10 популярных мифов о валидности и валидации

Миф 1. Валидность — некая единая, универсальная характеристика для любого кода

Примеры употребления: «Поменяй доктайп с X на Y, а то невалидно».

Реальность: валидность — понятие конкретное и относительное. Валидность документа на языке разметки означает соответствие определенной схеме. Указанной (напр. DTD в доктайпе) или подразумеваемой (в HTML5). Схемы бывают разные, и требования у них тоже (аналог из жизни: к строительству жилых домов и атомных электростанций применяются разные СНиПы), поэтому документ, валидный по одной схеме, наверняка будет невалидным по другой (хороша была бы АЭС, построенная по нормативам жилого дома!).

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

МаCSSаракш. Размышления о стандартах CSS

Пролог, или Невероятное происшествие в парижском бюро мер и весов

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

Бред? Конечно! Есть же какие-то базовые стандарты, которые не могут так внезапно меняться по прихоти. Да, они могут уточняться и совершенствоваться — но не так, что прежние эталоны вдруг станут полностью негодными, а потом радикально изменят своё значение. Улучшение стандартов — однонаправленный, поступательный процесс исправления мелких неточностей, а не чередование периодов относительной ясности с полосами полной неразберихи, то туда, то обратно. Так требует здравый смысл.

Почему же не менее бредовые истории оказались возможны в вебе?

ИКФ: Горизонтальное выравнивание, часть 3 (13-я публикация цикла “Тайны CSS2.1″)

text-align и новые значения из CSS3

До этого момента мы обсуждали значения text-align, которые, во-первых, принадлежат спецификации CSS2.1, а во-вторых, уже давно существуют и работают во всех известных нам браузерах. Но прогресс не стоит на месте и на пороге уже стремительно вырастает CSS3, который дарит нам новые модули и значения для известных свойств. И здесь он не остался к нам равнодушен, предложив ещё несколько значениий для text-align, которые уже есть в CSS3, но содержатся в черновике.

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

ИКФ: Горизонтальное выравнивание, часть 2 (12-я публикация цикла “Тайны CSS2.1″)

Горизонтальное выравнивание по ширине строки

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

ИКФ: Горизонтальное выравнивание, часть 1 (11-я публикация цикла “Тайны CSS2.1″)

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

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

ИКФ: Вертикальное выравнивание в строке, часть 3 (10-я публикация цикла “Тайны CSS2.1″)

vertical-align + line-height

Если вы внимательно читали предыдущие статьи, то уже наверняка поняли, как по отдельности работают vertical-align и line-height. Но как эти свойства взаимодействуют между собой? Краткий ответ – практически никак: их работа напрямую не пересекается. Задача vertical-align — сдвигать базовую линию, на сколько велено, а задача line-height (благодаря half-leading'ам) — отталкивать чужие лайн-боксы от этой базовой линии сверх метрик шрифта.

ИКФ: Вертикальное выравнивание в строке, часть 2 (9-я публикация цикла “Тайны CSS2.1″)

top и bottom

Если с вышеупомянутыми значениями было всё достаточно прозрачно, то с top и bottom не всё так просто. У этих значений есть особая черта, которой нет ни у одного другого значения vertical-align. Инлайн-боксы с vertical-align и значениями top или bottom способны отвязывать себя от базовой линии.

Но всё же, давайте по порядку.

Простые подсказки со стрелками на CSS

Очень простые CSS3-подсказки со стрелками. Ключём к созданию этих подсказок являются псевдо-элементы (:after и :before). Псевдо-элемент :after получает текст из атрибута "title" с помощью функции "attr()" в качестве своего контента и соответственно стилизуется так, как нам надо. Чтобы создать сами стрелки, используется псевдо-элемент :before, а треугольнички внизу подсказки делаются с помощью границ.

Подсказки становятся видимыми в тот момент, когда пользователь наводит указатель мыши на ссылку. Здесь мы используем псевдо-класс :hover. В итоге получается классный и полезный эффект.

HTML5: пути WHATWG и W3C опять расходятся?

Как известно, с начала возобновления в W3C работы над новой версией стандарта HTML (известной как HTML5) велись параллельно. WHATWG (самостоятельная рабочая группа по технологиям гипертекстовых веб-приложений, образованная представителями разработчиков браузеров и инициировавшая работу над новой версией HTML) поддерживает и развивает «живой стандарт HTML», а рабочая группа по HTML в W3C периодически выпускает «снимки» (snapshots) спецификации в соответствии с утвержденным W3C рабочим процессом (по которому спецификация постепенно «дозревает», последовательно меняя статус от черновика до окончательной рекомендации). До сих пор главным (и фактически единственным) редактором обеих спецификаций был один и тот же человек — Иэн Хиксон (известный также под ником Hixie).

Со временем между двумя версиями спецификации стали накапливаться расхождения. Сначала W3C попытался разделить спецификацию на несколько отдельных документов (в частности, от основной спецификации были отделены 2D Сanvas API, серверные события и т.п.), что в итоге привело к путанице, и WHATWG вернулись к модели единой большой спецификации. Затем стало понятно, что цели обеих групп тоже расходятся. Как поясняет в своем письме Хиксон, в WHATWG старались создавать «каноническое описание HTML и смежных технологий», исправляя ошибки спецификации по мере их обнаружения и добавляя новинки, как только они оказываются востребованными и пригодными к реализации. Для W3C на первом плане оставались формальные критерии смены статусов, предусмотренные их рабочим процессом. Поэтому руководство рабочей группы HTML в W3C и сам Хиксон решили окончательно разделить работу над спецификацией на два фронта: Хиксон сосредоточится над WHATWG-версиейживым стандартом»), а у W3C-версий (HTML5 и отделившихся от нее спецификаций) появится свой новый редактор.

Таким образом, с данного момента у нас появляются две разных, независимых спецификации HTML5.

К какой из спецификаций будут прислушиваться разработчики браузеров? В IRC-канале Хиксон утверждает, что «надеется, что это будет версия WHATWG», хотя «поживем — увидим». Но он уверяет, что в долгосрочной перспективе версия WHATWG будет отвечать состоянию дел в браузерах (т.е. учитывать состояние реализации тех или иных «фич»). Он также высказывает опасения, что задержка спецификации (отставание ее от реальности) приведет к тому, что браузеры начнут внедрять собственные новинки на свой лад.

Некоторые замечают в нынешней ситуации аналогии с 2004-м годом, когда расхождение в целях между W3C («зацикленным» тогда на XML и XHTML) и разработчиками браузеров как раз привело к возникновению WHATWG и HTML5. Пока трудно сказать, как эта новость скажется на дальнейшем развитии HTML5 и веба вообще. Так что следите за новостями!

ИКФ: Вертикальное выравнивание в строке, часть 1 (8-я публикация цикла “Тайны CSS2.1″)

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

В следующем цикле статей мы постараемся досконально углубиться в работу vertical-align, разобрать поведение этого свойства и способы его влияния на высоту строки.