CSS-live.ru

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

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

ИКФ

Краткое резюме

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

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

Мы очень рады, что смогли полностью раскрыть одну из тайн CSS 2.1. Обещаем, что не будет останавливаться на достигнутом, а продолжим свои раскопки и дальше.

Скачивайте и изучайте на здоровье! Команда css-live.ru

Скачать .rar
Скачать .zip

P.S. Это тоже может быть интересно:

55 комментариев

  1. А вообще очень хорошая идея, по окончанию цикла статей собрать их в одну книгу, так как блог для подобных вещей не самый удобный вариант. Я это всё по Мейеру ещё изучал, но думаю хороший вариант освежить знания, вдруг что-то новое узнаю…
     
    Думаю вам стоит регулярно выпускать подобные книги по завершению цикла статей! Кстати о чём будете дальше писать? я имею ввиду имено циклы а не одтдельные статьи.

    1. Рады, что вам понравилось! Значит не зря всё это безумые происходит))

      Да, согласен. Идея выпустить книгу в pdf формате, действительно хорошая. Это очень удобно и даёт свои плюсы читателю.

      Дальше мы планируем сделать цикл "Блочный контекст форматирования", что было бы логично:) 

      1. Ну блочный он в принципе проще (вернее такойже просто он в более полном объёме используеться на практике), там самое сложное это поведение флоатов и взаимодействие с ними…
        Но подоводный камень в том что его не получиться описать полностью, придёться делать две части книги, одна по css 2.1, а вторая уже потом как дополненая и переработанная первая, про флекс бокс, грид и .т.д. или растянуть придётся на долгий период пока это всё утрясётся…
        Также мне было бы интересно прочитать подробный мануал про трансформации и анимации (особенно описание всяких математичеких вещей на понятном языке), так как толком инфы по этому вопросу особо нет, есть кусками на разных сайтах но вот так чтоб прямо детально и полностью пока не видел, разве что в спеке (может плохо искал)….

        1. Я бы добавил флексбокс, за которым должно быть будущее блочной разметки.

      2. Я бы лучше книгу в pdf продавал, как делает Илья Кантор со своим учебником по JS. Кто не хочет платить — читает сайт, кому нужен pdf — вознаграждает автора. Я так приобрел у него 2 верси, хоть и не нужны были))

      3. еще планируется Блочный контекст форматирования ? или уже нет? я бы очень хотела почитать) если да то когда?

        1. Добрый день! Да, планируется конечно же. Но пока к сожалению дикая нехватка времени оттягивает эти вещи:(

  2. Спасибо. Серьезная книга на сложную тему которая нигде не разбирается. Можете еще закинуть на http://www.scribd.com/ — это зарубежный сервис для онлай-чтения книг.

  3. Спасибо за книгу, ребята. Сказал поизучать. Строково форматирование — та еще темная лошадка. 

  4. Уведомление: Набор полезностей №15
  5. Подскажите, если вы верстали эту книгу, значит есть где-то исходники.

    Можно ли я сделаю из этих исходников книгу в формате — ePub?

    1. К сожалению книге уже года два и исходников у нас не осталось. Попробуйте переделать этот формат в ePub, и, если удастся, то тогда: 1) Книга должна быть один в один, со всеми авторами, сайтами и т.д. 2) Мы добавим вашу ePub-книгу к себе.

      Оставьте на всякий случай свою почту, если вдруг нам удастся найти исходник, мы с вами свяжемся.

      1. Понимаете, Максим, для того чтобы сделать "конфетку" из PDF в ePub — я потрачу намного больше времени, чем из оригинальных файлов.
        Но я постараюсь. ))
        Безусловно Ваши пожелания будут выполнены. Об другом и речи быть не может.

          1. Можем еще связь держать через skype. Напишу свой скайп-ник в ответе на Ваше письмо.

    2. Спс за книгу. Заметил её только когда новый дизайн появился :) Думал денег потребуете, а оказалось нет! :)

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

        1. А вам спасибо огромное за тёплые слова! Но дело в том, что дядек на самом деле целых две штуки, поскольку писал я книгу не один, а со своим коллегой по цеху — Ильёй (@SelenIT2 — не шутите с его аватаркой:)), т.е. без него эта книга не то, что не появилась бы, она умерла бы уже в зачатке))) Так что я обязательно поделюсь с ним вашими благодарностями, ещё раз спасибо, приходите в гости:)

          1. Вы про сайт :) ? Да, здесь есть что почитать! Пока изучаю потихоньку) Привет второму дяденьке. Аватарка у него и впрямь необычная. :)))

  6. Сейчас читаю: ‘Горизонтальные margin, border и padding между инлайн-боксами учитываются’.
    Но по факту учитывается http://jsfiddle.net/5k6zmd1p/. Может быть речь о вертикальных марджинах? Или я что-то делаю не так?

  7. За книгу спасибо. Интересно будет почитать. А почему формат в pdf? Он же не адаптируется под размеры экрана смартфона.

    1. В принципе, основы остались прежними (не так давно Венсан де Оливейра открывал их заново:), но многие примеры с багами браузеров уже неактуальны. И тогда не было устоявшихся русских переводов многих терминов, нам приходилось выдумывать их на свой страх и риск (особенно для таких вещей, как «line box», «inline box» и «inline block», которые при неаккуратном переводе слишком легко перепутать), сейчас их чаще называют иначе.

  8. Здравствуйте!
    Хочу задать вопрос, который близок к теме ИКФ. Изучаю сейчас редакторский черновик CSS Display Module Level 3 и пытаюсь понять такой термин как text run.
    Во-первых возникает вопрос, как правильно перевести этот термин? Лучшее, что предложил переводчик это «текстовый прогон».
    Во-вторых есть вопрос по данному в спецификации определению. В ней сказано:

    CSS takes a source document, organized as a tree of elements and text nodes, and renders it onto a canvas (such as your screen, a piece of paper, or an audio stream). To do this, it generates an intermediary structure, the box tree, which represents the formatting structure of the rendered document. Each box in the box tree represents its corresponding element (or pseudo-element) in space and/or time on the canvas, while each text run in the box tree likewise represents the contents of its corresponding text nodes.

    CSS берет исходный документ, организованный как дерево элементов и текстовых узлов, и рендерит его на холсте, например, на вашем экране, листе бумаги или в аудио потоке. Для этого он создает промежуточную структуру — дерево боксов, которое представляет собой структуру форматирования отображаемого документа. Каждый бокс в дереве боксов представляет соответствующий ему элемент (или псевдоэлемент), размещенный на холсте в пространстве и/или во времени. В тоже время каждый text run в дереве боксов, также представляет содержимое соответствующих ему текстовых улов.

    Similarly, each contiguous sequence of sibling text nodes generates a text run containing their text contents, which is assigned the same styles as the generating text nodes. If the sequence contains no text, however, it does not generate a text run.

    Подобным образом, каждая непрерывная последовательность находящихся на одном уровне текстовых узлов, генерирует text run, содержащий их текстовый контент, которому назначаются те же стили, что и для породивших его текстовых узлов. Однако, если последовательность не содержит текста, то text run не будет создан.
     
    Долго думал, что же это за родственные текстовые узлы, которые образуют один text run. И пока формулировал этот вопрос, то пришло озарение :) 
    Правильно ли я понял, что представленные ниже фрагменты HTML-разметки будут формировать указанные деревья боксов?
    Пример 1
    <p>text node 1 <span>span 1</span> text node 2</p>

    box: <p>

    text run: «text node1 text node 2»

    box: <span>

    text run: «span 1»

    Пример 2
    <p><span>span 1</span></p>

    box: <p>

    box: <span>

    text run: «span 1»

     
    Заранее спасибо за ответ!

    1. В посте выше слетели списки. Корректирую здесь, надеюсь не слетят.

      Пример 1
      <p>text node 1 <span>span 1</span> text node 2</p>

      box: <p>

      text run: «text node1 text node 2»
      box: <span>

      text run: «span 1»

      Пример 2
      <p><span>span 1</span></p>

      box: <p>

      box: <span>

      text run: «span 1»

    2. Спасибо за хороший вопрос!

      Во втором примере всё верно, но в первом «text node1» и «text node 2» всё-таки будут двумя отдельными text runs (русского эквивалента сходу действительно на ум не приходит… может быть, «отрезки текста»?). И эти text runs не будут «contiguous» (смежными, соприкасающимися), потому что их разделяет элемент.

      Смежные text runs в дереве боксов могут возникать в ситуациях с display: contents: скажем, если в этом же примере 1 у span-а будет стоять display: contents, то в боксе абзаца окажутся три text runs подряд («text node1», «span 1» и «text node 2»), на одном уровне вложенности в дереве боксов, и вот они как раз окажутся смежными. Об этой особенности display: contents у нас есть отдельная небольшая статья.

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

    Итак, из статьи я понял, что text run это «отрезок текста» в инлайн боксе. До появления display: contents инлайн бокс мог содержать только один «отрезок текста», поэтому не было необходимости в понятии text run. Но сейчас оно необходимо, чтобы как-то описывать «отрезки текста» с отличающимися значениями свойств и находящимися в одном инлайн боксе.

    То есть следующий пример приведет к созданию такого дерева боксов:

    span {
    display: contents;
    }
    <div>Раз <span>Два</span></div>

    В дереве боксов получаем получаем:
    — блочный бокс элемента div
    — анонимный инлайн бокс «Раз Два»
    —— text run «Раз»
    —— text run «Два»

    А фрагмент спецификации:

    Similarly, each contiguous sequence of sibling text nodes generates a text run containing their text contents, which is assigned the same styles as the generating text nodes.

    я бы сейчас перевел следующим образом:

    Подобным образом, каждая последовательность смежных (contiguous) родственных (sibling) текстовых узлов (мое прим.: смежных именно в дереве боксов из-за display: contents) создает один «отрезок текста» (a text run), содержащий их текстовый контент, которому назначаются те же стили, что и для создавших его текстовых узлов.

    И, тут, на мой взгляд, идет расхождение. Поскольку судя по тексту (или моему переводу) спеки, смежные текстовые узлы создают ОДИН «отрезок текста». Тогда как исходя из статьи, КАЖДЫЙ смежный текстовый узел создает соответствующий ему «отрезок текста». Можете это прокомментировать?

    1. Спасибо за внимательность! Да, выходит, в комменте выше и в статье я ошибся, по текущей редакции спецификации «text run»-ом считается именно вся сплошная (оказывается, у contiguous бывает и такое значение) последовательность кусков текста из разных текстовых узлов, оказавшихся соседями в дереве боксов. Причем, оказывается, я сам невольно поспособствовал этой путанице (тогда моей задачей было не допустить, чтобы разные text runs становились разными анонимными флекс- или грид-элементами, как предлагал Ориол Брюфо… надо же, я уже и забыл о том обсуждении:). нет, всё-таки там речь о соседних нодах в DOM, см. ниже

      1. Д — Дотошность.

        Илья, возвращаюсь к вам с очередным вопросом-уточнением по text run :)

        Итак, text run — это сущность дерева боксов. С появлением display: contents появились ситуации, когда текстовые узлы могут образовывать в дереве боксов сплошные последовательности текста. В результате появился термин text run, который и описывает такую сплошную последовательность.

        Правильно ли я понимаю, что согласно текущей версии спецификации каждый text run находится в своем инлайн-боксе (обычном или анонимном)? Например, для такого кода:

        HTML:
        <p>textNode1 <span style=»display: contents»>textNode2</span></p>

        CSS:
        p { color: red; }
        span { display: contents; color: green; }

        Будет создано следующее дерево боксов:

        — block box: <p>
        — — anonymous inline box: «textNode1 textNode2»
        — — — text run: «textNode1 textNode2»

        И при такой трактовке у вас и возникает вопрос, от какой сущности должно происходить наследование стилей для «textNode1 » и «textNode2»? Анонимный бокс эту роль уже исполнить не может.

        1. Дотошность – важное качество для разбора спек! :) Еще раз спасибо за хороший вопрос, заставил крепко задуматься!

          По зрелом размышлении, всё-таки правильной была моя первоначальная трактовка: в этом примере будет один anonymous inline box, но два отдельных text runs, каждый со своими стилями. Чтобы получился один text run, текстовые ноды должны быть смежными именно в DOM – такое может получиться, если их по отдельности добавили в один элемент скриптом. Из разметки, наверное, такого получиться не может… хотя надо будет прояснить, будут ли считаться смежными текстовые ноды, разделенные только HTML-комментарием (спросил в ишью:)

          1. Вы были правы, Илья, спецификации могут дать фору любому детективу :)

            Благодаря вашему ишью, был обновлен редакторский черновик CSS Display Module Level 3. Появилось пояснение к термину «дерево элементов»:

            Some source documents start from more complex trees, such as the DOM, which can have comment nodes and other types of things. For the purposes of CSS, all of these additional types of nodes are ignored, as if they didn’t exist.

            CSS стал понятнее.

            А теперь возвращаюсь к нашим text runs, надо же и здесь внести ясность.

            Сегодня в редакторском черновике CSS Flexible Box Layout Module Level 1 нашел следующее предложение (https://drafts.csswg.org/css-flexbox-1/#flex-items):

            Each in-flow child of a flex container becomes a flex item, and each contiguous sequence of child text runs is wrapped in an anonymous block container flex item.

            То есть один text run как бы соответствует одному текстовому узлу (или последовательности текстовых узлов, если было добавление через скрипт).

            А, вот, в CSS Display Module 3 даны такие формулировки:

            Each box in the box tree represents its corresponding element (or pseudo-element) in space and/or time on the canvas, while each text run in the box tree likewise represents the contents of its corresponding text nodes.

            и

            Similarly, each contiguous sequence of sibling text nodes generates a text run containing their text contents, which is assigned the same styles as the generating text nodes.

            Тут text run как бы может соответствовать нескольким текстовым узлам. Да, вы писали, что такое возможно при добавлении текстовых узлов скриптом, но неужели тут пытались описать такую ситуацию?

            Также, выделенный жирным фрагмент, как будто говорит, что в text run каждый узел хранит свои стили.

            Все это наводит меня на мысль, что в CSS Display Module 3, что-то не так с описанием text run. А вы как думаете?

            1. Мне кажется, сейчас с описанием всё нормально:

              То есть один text run как бы соответствует одному текстовому узлу

              По-моему, из цитаты это никак не следует. Она говорит лишь о том, что несколько смежных text runs (что возможно при display:contents) в контексте флексбоксов объединяются в один общий анонимный флекс-элемент. Откуда эти text runs взялись, флексбоксам безразлично.

              такое возможно при добавлении текстовых узлов скриптом, но неужели тут пытались описать такую ситуацию?

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

              выделенный жирным фрагмент, как будто говорит, что в text run каждый узел хранит свои стили

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

               

              1. Да, соглашусь, с определениями все в порядке, бес попутал :)

                К предыдущей переписке хочу добавить следующее.

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

                A block container that contains only inline-level content establishes a new inline formatting context. The element then also generates a root inline box which wraps all of its inline content. Note, this root inline box concept effectively replaces the «anonymous inline element» concept introduced in CSS2§9.2.2.1.

                Во-вторых, во втором параграфе CSS Inline Layout Module Level 3 сказано:

                A block container element that directly contains inline-level content—such as inline boxes, atomic inlines, and text runs — establishes an inline formatting context.

                Здесь можно увидеть, что text run выступает как отдельная сущность, отличная от инлайн-боксов и атомарных инлайнов.

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

                ПРИМЕР 1

                HTML:
                <p>textNode1 <span class=’dc’>textNode2</span></p>

                CSS:
                .dc { display: contents; }

                Box tree:
                — block box: <p>
                — — root inline box:
                — — — text run: ‘textNode1’
                — — — text run: ‘textNode2’

                ПРИМЕР 2

                <p>textNode1 <span>textNode2 <span class=’dc’>textNode3</span></span></p>

                Box tree:
                — block box: <p>
                — — root inline box:
                — — — text run: textNode1
                — — — inline box: <span>
                — — — — text run: textNode2
                — — — — text run: textNode3

                Вроде бы теперь правильно.

                Единственный момент — не смог найти где сейчас описывается наследование стилей text run-ом. В CSS Cascading and Inheritance Level 3 явно про это не написано, и термины text run или run of text мне не встретились. Может вам, Илья, встречался этот момент?

  10. Привет, всем создателям этого уникального сайта!

    Подскажите, правильно ли я понимаю, что термины «раскладка» (layout) и «контекст форматирования» (formatting context) эквивалентны? Если это не так, то можете описать в чем их различие?

     

    1. Они тесно связаны, но всё-таки различны: раскладка – это процесс размещения блоков по определенным правилам, а также результат этого процесса (в этом значении layout часто переводят как «макет»). А контекст форматирования – это «штука, заставляющая CSS делать раскладку» (как буквально было написано в ранних черновиках CSS Display 3), т.е. область, в которой действуют определенные правила этой раскладки.

  11. Здравствуйте! Подскажите актуальна ли сейчас эта книга для начинающего верстальщика? Возможно подскажите еще познавательную литературу по теме html и css?

  12. Большое спасибо за книгу. Хотела пару копеек на кошелёк кинуть, платёж не прошёл.

Добавить комментарий для Мартин Отменить ответ

Ваш e-mail не будет опубликован. Обязательные поля помечены *

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