1467395 - Nothing shown for u2028 (Line Separator) and u2029 (Paragraph Separator)

Status: UNCONFIRMED

(Core :: Layout: Text and Fonts, defect, P3)

Description

[Siarhei Kuchuk]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.181 Safari/537.36

Steps to reproduce:

Please open in Chrome and Firefox the same page
https://unicode-table.com/ru/2029/


Actual results:

Firefox does not show that characters.


Expected results:

Firefox shows that char as Chrome and other browsers do.

Comment 1

[Siarhei Kuchuk]

Probably related issue: https://bugzilla.mozilla.org/show_bug.cgi?id=485563

Comment 2

[Gingerbread Man]

(In reply to Siarhei Kuchuk from comment #0)
> Firefox shows that char as Chrome and other browsers do.

What other browsers? IE and Edge don't show anything either.
Unless the site does something that I'm missing, it seems normal to me not to display anything for line terminator characters.

Comment 3

[Siarhei Kuchuk]

We have OnlyOffice and firefox crashes JS execution when data with such chars goes as JSON object. Other browsers aren't. Probably to insert at least char without space, i don't know.

Comment 4

[Jonathan Kew [:jfkthame]]

As per comment 2, it seems reasonable that line- and paragraph-separator characters should not display anything.

Do the HTML or CSS specifications have anything to say about how these characters should be processed?

Comment 5

[Gô Shoemake]

This is an old issue, but per CSS Text 3 (currently an Editor's Draft), CSS whitespace processing only affects spaces, tabs, and segment breaks, which include the Line Feed (always) and document-defined segment breaks (which in HTML includes CRLF).

It does not, for HTML or XML 1.0 documents, affect either U+2028 LINE SEPARATOR or U+2029 PARAGRAPH SEPARATOR. This means that these characters should not be collapsed and their semantics should be preserved.

Given Unicode line breaking rules, this would imply that a U+2028 and U+2029 in the source code of an HTML document should be rendered as a “hard” line break unaffected by the white-space property; e.g., similarly to a BR tag.

CSS Text 3 specifically calls this out:

Regardless of the white-space value, lines always break at each preserved forced break character: thus for all values, line-breaking behavior defined for the BK and NL line breaking classes in [UAX14] must be honored.

However, as best as I can tell (on macOS at least), Firefox currently does not render a line break for any of the characters in the BK line breaking class (note, though, that U+000C is HTML ASCII whitespace and so may not be preserved). This appears to me to be a bug.