HTML <pre>тег, по-видимому, не учитывает символ Unicode 'LINE SEPARATOR' (U + 2028) как разрыв строки - PullRequest
Новая
       29

HTML <pre>тег, по-видимому, не учитывает символ Unicode 'LINE SEPARATOR' (U + 2028) как разрыв строки

0 голосов
/ 05 июня 2018

Назовите меня доисторическим, но я пытаюсь использовать тип документа XHTML, закодированный на html-странице UTF8, с тегом PRE, содержащим текст с некоторыми переводами строки в юникод u2028.разрыв строки в блоке PRE.Изменение символа на u000D или u000a, кажется, приводит к разрывам строк, которые я ожидаю.(Технически u2028 кодируется в UTF8 как 3-байтовая последовательность, но я предполагаю, что он нормализуется обратно при чтении).Я еще не проверял это с другими браузерами.

Я пытался копаться в документах W3C по HTML, но не смог выяснить из раздела о PRE, какие именно символы рассматриваются как переносы строк.Где глава и стих о том, что именно интерпретируется как разрывы строк в PRE?Считается ли так, что u2028 считается таковым, поскольку Firefox имеет дефекты, или стандарт HTML не позволяет интерпретировать u2028 как разрыв строки при обнаружении в файле Unicode?

Мне кажется довольно странным, что текст (например, источниккод) файл, содержащий Unicode, не будет использовать u2028 в качестве стандарта для разрывов строк (на самом деле у меня есть генератор кода, который производит исходный код, как это, и я пытаюсь отобразить этот код на HTML-странице).Таким образом, размещение такого кода прямо в PRE-блоках, я думаю, приведет к ожидаемому поведению.

1 Ответ

0 голосов
/ 05 июня 2018

Несмотря на то, что может указывать природа элемента PRE, его поведение рендеринга фактически задается в CSS, а не в HTML, поскольку оно относится к рендерингу пробелов.

CSS2 говорит, что U+ 000D и U + 000A считаются новыми строками, и пользовательские агенты могут распознавать и нормализовать другие символы Юникода как таковые.Однако в нем нигде не упоминается U + 2028.

css-text-3 охватывает обработку пробелов и разрыв строки гораздо более полно.Он определяет термин разрыв сегмента следующим образом:

Для обработки CSS каждый определенный в языке документа разрыв сегмента, последовательность CRLF (U + 000D U +000A), возврат каретки (U + 000D) и перевод строки (U + 000A) в тексте обрабатываются как разрыв сегмента , который затем интерпретируется для рендеринга, как указаносвойство white-space.

Как и CSS2, оно не упоминает U + 2028.

Но, в более позднем разделе , оно упоминает принудительноесимволы разрыва (один из которых U + 2028):

При определении разрыва строки:

  • Независимо от значения white-space, строки всегда разбиваются при каждом сохраненном принудительномсимвол разрыва: для всех значений должно учитываться поведение разрыва строки, определенное для классов разрыва строки BK, CR, LF, CM, NL и SG в [UAX14].

Примечаниечто он даже говорит «Независимо от значения white-space»;это означает, что даже вне элемента PRE U + 2028 должен вводить разрыв строки (аналогично элементу BR)!

Что касается реализаций, Internet Explorer и Microsoft EdgeПохоже, что это единственные браузеры, которые отображают U + 2028 как разрыв строки в элементе PRE со значением по умолчанию white-space: pre.Единственное предостережение заключается в том, что они нормализуют его до U + 000A, поэтому в конечном итоге он рассматривается как обычный пробел за пределами элемента PRE (или white-space: pre / pre-line).Это соответствует тому, что css-text-3 говорит о сохраненных принудительных перерывах, но я не уверен, допустим ли сам процесс нормализации U + 2028 до U + 000A, или нарушение спецификации Unicode / CSS.

Chrome в Windows 10 всегда печатает символ, помеченный LSEP, а Firefox всегда печатает символ нулевой ширины.

Независимо от того, является ли документ application / xhtml + xml или text / html, похоже, нетразница в любом из этих случаев.

...