Евгений Резниченко - Спецификация CSS2 Страница 25

Спецификация HTML 4.0 ( [HTML40] , раздел 8.2) определяет двунаправленное поведение для элементов HTML. Соответствующие HTML ПАгенты могут поэтому игнорировать свойства 'direction' и 'unicode-bidi' в авторских и пользовательских таблицах стилей. Правила таблиц стилей, которые необходимо применять для bidi-поведения и которые специфицированы в [HTML40] , даны в примере таблицы стилей. Спецификация HTML 4.0 содержит также дополнительную информацию о вопросах двунаправленности.

'direction'

Значение: ltr | rtl | inherit

Начальное: ltr

Применяется: ко всем элементам, но см. текст

Наследуется: да

Процентное: N/A

Носитель: визуальный

Это свойство специфицирует базовое направление письма блоков и направление внедрений и переопределений (см. 'unicode-bidi') для двунаправленного алгоритма Unicode. Дополнительно оно специфицирует направление для столбца таблицы, направление горизонтального переполнения и позицию неполной последней строки блока в том случае, если 'text-align: justify'.

Значения этого свойства имеют следующий смысл:

ltr

Направление слева направо.

rtl

Справа налево.

Чтобы свойство 'direction' работало в элементах инлайн-уровня, значение свойства 'unicode-bidi' обязано быть 'embed' или 'override'.

Примечание. Свойство 'direction', специфицированное для элементов столбца таблицы, не наследуется ячейками столбца, поскольку столбцы не существуют в дереве документа. Таким образом, CSS не может использовать правила наследования атрибута "dir", описанные в [HTML40] , в разделе 11.3.2.1.

'unicode-bidi'

Значение: normal | embed | bidi-override | inherit

Начальное: normal

Применяется: ко всем элементам, но см. текст

Наследуется: нет

Процентное: N/A

Носитель: визуальный

Значения этого свойства имеют следующий смысл:

normal

Элемент не открывает дополнительный уровень внедрения относительно двунаправленного алгоритма. Для элементов инлайн-уровня неявное переупорядочивание работает вне границ элемента.

embed

Если элемент - инлайн-уровня, это значение открывает дополнительный уровень внедрения относительно двунаправленного алгоритма. Направление в этом уровне внедрения задаётся свойством 'direction'. Внутри элемента переупорядочивание выполняется неявно. Это соответствует дополнению LRE (U+202A; для 'direction: ltr') или RLE (U+202B; для 'direction: rtl') в начале элемента и PDF (U+202C) в конце элемента.

bidi-override

Если элемент - уровня блока или инлайн и содержит только элементы инлайн-уровня, это значение создаёт переопределение. Это означает, что внутри элемента переупорядочивание выполняется строго в соответствии со свойством 'direction'; неявная часть двунаправленного алгоритма игнорируется. Это соответствует дополнению LRO (U+202D; для 'direction: ltr') или RLO (U+202E; для 'direction: rtl') в начале элемента и a PDF (U+202C) в конце элемента.

Окончательный порядок символов в каждом элементе уровня блока - такой, как если бы bidi-код управления был добавлен так, как описано выше, разметка была бы вырезана, а результирующая последовательность символов - передана в двунаправленный алгоритм Unicode в обычный текст, который производил бы те же самые разрывы строк, что и стилизованный текст. В этом процессе нетекстуальные объекты, такие как изображения, рассматриваются как нейтральные символы, если только их свойство 'unicode-bidi' не имеет значений, отличных от 'normal', тогда они рассматриваются как полужирные (strong) символы в 'direction', специфицированном для элемента.

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

Поскольку алгоритм Unicode имеет предел - 15 уровней внедрения, лучше не использовать 'unicode-bidi' со значениями, отличными от 'normal', если отсутствуют подходящие. Значение 'inherit' должно использоваться особенно осторожно. Однако для элементов, которые обычно предполагается отображать как блоки, установка 'unicode-bidi: embed' предпочтительнее для удержания элементов вместе в том случае, когда дисплей изменяется на инлайн (см. пример ниже).

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

Здесь буквы нижнего регистра присущи символам слева-направо, а буквы верхнего регистра - символам справа-налево:

<HEBREW> <PAR>HEBREW1 HEBREW2 english3 HEBREW4 HEBREW5</PAR> <PAR>HEBREW6 <EMPH>HEBREW7</EMPH> HEBREW8</PAR> </HEBREW> <ENGLISH> <PAR>english9 english10 english11 HEBREW12 HEBREW13</PAR> <PAR>english14 english15 english16</PAR> <PAR>english17 <HE-QUO>HEBREW18 english19 HEBREW20</HE-QUO></PAR> </ENGLISH>

Поскольку это - XML, таблица стилей отвечает за направление письма. Это таблица стилей:

/* Правила для bidi */ HEBREW, HE-QUO {direction: rtl; unicode-bidi: embed} ENGLISH {direction: ltr; unicode-bidi: embed} /* Правила для представления */ HEBREW, ENGLISH, PAR {display: block} EMPH {font-weight: bold}

Элемент HEBREW это блок с базовым направлением справа-налево, элемент ENGLISH это блок с базовым направлением слева-направо. PARы - это блоки, наследующие базовое направление от своих родителей. Таким образом, первые два PARа готовы начаться справа сверху, а последние три готовы начаться слева сверху. Обратите внимание, пожалуйста, что HEBREW и ENGLISH выбраны как имена элементов лишь для ясности; обычно имена элементов должны относиться к структуре, без ссылок на языки.

Элемент EMPH - уровня инлайн, и, поскольку его значение для 'unicode-bidi' - 'normal' (начальное значение), он не оказывает воздействия на порядок расположения текста. Элемент HE-QUO, напротив, создаёт внедрение.

Если длина строки достаточно большая, форматирование текста может выглядеть примерно так:

5WERBEH 4WERBEH english3 2WERBEH 1WERBEH 8WERBEH 7WERBEH 6WERBEH english9 english10 english11 13WERBEH 12WERBEH english14 english15 english16 english17 20WERBEH english19 18WERBEH

Заметьте, что внедрение HE-QUO заставляет HEBREW18 находиться справа от english19.

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

2WERBEH 1WERBEH -EH 4WERBEH english3 5WERB -EH 7WERBEH 6WERBEH 8WERB english9 english10 en- glish11 12WERBEH 13WERBEH english14 english15 english16 english17 18WERBEH 20WERBEH english19

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

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

Лекция 10. Модель визуального форматирования. Детали

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

Содержащий блок элемента определяется так:

1Содержащий блок (называемый начальным содержащим блоком), в котором находится корневой элемент, выбирается пользовательским агентом (ПА).

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

3Если элемент имеет 'position: fixed', то Содержащий блок устанавливается портом просмотра.

4

Если элемент имеет 'position: absolute', то Содержащий блок устанавливается ближайшим предком с 'position', отличным от 'static', следующим образом:

1Если предок - уровня блока, Содержащий блок формируется краем заполнения предка.

2Если предок - инлайн-уровня, Содержащий блок зависит от свойства 'direction' предка:

1Если 'direction' - 'ltr', верхний и левый края содержащего блока являются верхним и левым краями первого бокса, генерируемого предком, а нижний и правый края являются нижним и правым краями содержимого последнего бокса предка.

2Если 'direction' - 'rtl', верхний и правый края содержащего блока являются верхним и правым краями первого бокса, генерируемого предком, а нижний и левый края являются нижним и левым краями содержимого последнего бокса предка.

Если такого предка нет, край содержимого бокса корневого элемента устанавливает Содержащий блок.

Содержащие блоки (СБ) без позиционирования в этом документе: