Repository navigation
[css-text] Question re white space processing rules for U+000D #855
Description
AFAICT from https://drafts.csswg.org/css-text-3/#white-space-processing, a lone CR (U+000D) character should be treated just like a lone LF (U+000A) or a CRLF pair: it is a segment break, which will be transformed to a preserved line feed, removed, or transformed to a space (U+0020), depending on the value of white-space and possibly the context of the segment break.
However, none of the browsers I have tested so far (Firefox, Chrome, Safari, Edge) appear to behave this way; rather, they all discard the lone CR.
Testcase: https://people-mozilla.org/~jkew/tests/cr.html
Am I misunderstanding something here, should the spec be changed to better match actual behavior, or do we expect all the browsers to change to match the spec?
Activity
upsuper commentedon Jan 6, 2017
(cc myself)
fantasai commentedon Apr 19, 2017
Probably we should make the spec match the implementations here.
css-meeting-bot commentedon May 10, 2017
The CSS Working Group just discussed
Question re white space processing rules for U+000D, and agreed to the following resolutions:RESOLVED: Accept the change in https://github.com/w3c/csswg-drafts/issues/855The full IRC log of that discussion
<dael> Topic: Question re white space processing rules for U+000D<dael> Github topic: https://github.com//issues/855
<dael> Rossen: Is dauwhe on?
<dael> fantasai: Rossen can we have WD resolution?
<dael> Rossen: Oh, yes.
<fantasai> TabAtkins, would you mind adding the at-risk thing and pushing to /TR?
<dael> Rossen: Is anyone prepared to talk on this?
<dael> TabAtkins: I can do it based on thread.
<dael> TabAtkins: According to the text spec a lone U-000D is the same as a proper line break.
<dael> TabAtkins: Impl don't do that, they dropit frfom white space processing.
<dael> TabAtkins: There's a test case in the issue. It appears it's consistant. We should prob change spec to match impl.
<dael> Florian: To clarify, is that the one used to be used before OS10?
<dael> TabAtkins: Someone used it at some point.
<dael> fantasai: Yes.
<dael> Florian: So it's not likely something on the rise, it's t he other way around.
<dael> ?? Matching imple i s good idea.
<myles> s/??/myles/
<plinss> s/one used/one macs used/
<dael> dbaron: This is about carrage returns getting to the CSS level. Classic mac could have processed before.
<zcorpan> or textContent = "foo\rbar"
<zcorpan> html parser normalizes
<dael> TabAtkins: I don't think HTML parser does magic.
<dael> gsnedders: It repleaces them with [missed]
<dael> TabAtkins: Nevermind. He's just using entitities in text example.
<gsnedders> s/[missed]/line feed (000A)/
<dael> s/text/test
<myles> s/[missed]/line feeds/
<dael> Florian: Then go for it.
<dbaron> s/carrage/carriage/
<dael> Florian: Make the suggested change to match impl.
<dael> Rossen: Okay. Any objections to accepting the change?
<dael> RESOLVED: Accept the change in https://github.com//issues/855
[css-text-3] Tentative commits for #855.
fantasai commentedon Mar 5, 2018
So, as I was working on this I realized that making a character invisible is underdefined: what effect does it have on surrounding characters? Does it break joining? Afaict, Chrome drops form feeds and carriage returns from rendering entirely, whereas Gecko treats them similar to zwsp.
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%D8%B4%D8%AA%0AVA%3Cbr%3E%0A%D8%B4%26%23x000c%3B%D8%AA%0AV%26%23x000c%3BA%3Cbr%3E%0A%D8%B4%26%23x000d%3B%D8%AA%0AV%26%23x000d%3BA%3Cbr%3E%0A%D8%B4%26%23x200b%3B%D8%AA%0AV%26%23x200b%3BA%0A%0A
What do we want to do here?
css-meeting-bot commentedon Apr 11, 2018
The Working Group just discussed
Lone CRs, and agreed to the following resolutions:RESOLVED: Treat lone CRs as 0 width spacesThe full IRC log of that discussion
<fantasai> Topic: Lone CRs<fantasai> https://drafts.csswg.org/css-text-3/issues-lc-2013#issue-138
<fantasai> github: https://github.com//issues/855
<dael> fantasai: Jonathan Kew reports a long cr is just like a lone line feed and it's a segment break. Browsers discared the carraige returns. If you put them in your source they're transformed. However if you inject it via JS into the dom text content then it disappears.
<dael> fantasai: If they used dthml and not escape it would happen. We accepted the change and then I realized that making a character invisible is under defined.
<dael> myles: Can we pretend it never existed?
<fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%D8%B4%D8%AA%0AVA%3Cbr%3E%0A%D8%B4%26%23x000c%3B%D8%AA%0AV%26%23x000c%3BA%3Cbr%3E%0A%D8%B4%26%23x000d%3B%D8%AA%0AV%26%23x000d%3BA%3Cbr%3E%0A%D8%B4%26%23x200b%3B%D8%AA%0AV%26%23x200b%3BA%0A%0A
<dael> fantasai: Or treat similar to 0 width
<dael> myles: For kerning you want it not to be similar to 0 width
<dael> fantasai: I think this is a weird edge case.
<dael> myles: You're saying because it's an edge case we should do the simple thing.
<dael> fantasai: For pages authored with crs they're taking care of by html parsing algo. This is just people who stick a character inside.
<dael> fantasai: gecko treats like 0 space and chrome drops. Someone help me decide between the 2 behaviors.
<dael> florian: Dropping seems simplier.
<dael> myles: Harder to impl because changes size of data structire
<dael> koji: Difference between drop and 0 width?
<dael> fantasai: There's a test case.
<dael> myles: In an impl where strings are never copied you'd have to removet he character and shift the future to pretend it doesn't happen.
<dael> astearns: We have 1 browser with 0 width and another inclined.
<dael> fantasai: fremy what does edge do?
<dael> fremy: I can't load page.
<dael> eae: We wouldn't object.
<dael> myles: There are other characters treated as 0 width.
<dael> astearns: fremy do you care?
<dael> fremy: I don't know what Edge does.
<dael> fantasai: There's an IRC test case.
<dael> fremy: It's so broken we need to fix it.
<dael> astearns: Prop: Treat lone CRs as 0 width spaces
<dael> RESOLVED: Treat lone CRs as 0 width spaces
46 remaining items
Bug 1497380 [wpt PR 13389] - [css-text] Control characters should be …
Bug 1497380 [wpt PR 13389] - [css-text] Control characters should be …
Bug 1550241 [wpt PR 16443] - [css-test] Handle U+00C0 as other contro…
Bug 1550241 [wpt PR 16443] - [css-test] Handle U+00C0 as other contro…
Bug 1550241 [wpt PR 16443] - [css-test] Handle U+00C0 as other contro…
Don't treat lone CRs as segment breaks.
Bug 1657437 - Don't treat lone CRs as segment breaks. r=jfkthame
Don't treat lone CRs as segment breaks.
Bug 1657437 - Don't treat lone CRs as segment breaks. r=jfkthame
Bug 1657437 - Don't treat lone CRs as segment breaks. r=jfkthame
Bug 1657437 - Don't treat lone CRs as segment breaks. r=jfkthame
Bug 1657437 - Don't treat lone CRs as segment breaks. r=jfkthame
Bug 1497380 [wpt PR 13389] - [css-text] Control characters should be …
Bug 1550241 [wpt PR 16443] - [css-test] Handle U+00C0 as other contro…
Bug 1657437 - Don't treat lone CRs as segment breaks. r=jfkthame