[css-text] Reconsider the resolution on #855 #5410
Comments
Can you tell me how you tested this? I debugged: |
|
I don't care what we decide here, but if we resolve on making it “invisible” please make sure it's defined exactly what that means. |
Thank you, confirmed that LayoutNG handles lone CR as a collapsible space, in this CL which refers to CSS Text but I can't find the definition any longer. CSS2 has it, so maybe it was removed after we implemented LayoutNG? The I think we can try to change this. Can you and @litherum tell me how you handle it? |
|
Sounds that we have a few options:
As far as I can tell using https://lists.w3.org/Archives/Public/www-archive/2020Sep/att-0001/CR.html:
All in all, it's all over the place, but nobody does what the spec says. I don't think it's terribly important what behavior we pick, but it would be good to converge, and to spec what we do. Personally, I find Chrome's behavior weird, so wouldn't recommend that. Safari+Firefox's 3.b. seems decently sensible, and it is sufficiently web exposed that I don't think there's a big compat risk, so I'd suggest aligning with that. PS: As 3.b might look like the behavior you'd get by putting a zero width space there when using an arabic font that doesn't have zwsp (and therefore falls back to a different font for that glyph, and therefore breaks shaping even tough shaping is supposed to be preserved through zwsp, see #3861), I've checked for that specifically in Firefox and Safari. Even on Fonts where Safari would correctly do Shaping across a zwsp, it still breaks shaping accross the "invisible" CR. As far as I can tell, Firefox never shapes across a zwsp, even though that's not compliant with Unicode. |
|
Personally, I suspect treating it as a visible space is easiest if we want to get interop. There are just way too many ways to make something 'invisible'. |
|
Agenda+ to propose resolving onto making lone CRs be treated as visible spaces, based on the results of #5410 (comment) and subsequent comments. |
|
The CSS Working Group just discussed
The full IRC log of that discussion<dael> Topic: [css-text] Reconsider the resolution on #855<oriol> emilio: Logical values computing as-is was resolved in https://github.com//issues/2821#issuecomment-415092595 <dael> github: https://github.com//issues/5410 <emilio> oriol: great, just wanted to make sure that there was a resolution on that, thanks! <emilio> oriol: a bit odd that it behaves differently from logical props but maybe not too much :) <fantasai> emilio, it would have been necessary for text-align to actually work as expected :) <dael> florian: We resolved control characters are displayed visually. As part of that the CR character, carrage return, is supposed to be the same. Most of the time you can't notice b/c handled by HTML parser. But if you inject it you should see it. No one does it. <emilio> fantasai: fair enough :) <dael> florian: Mostly can't see, Chrome sometimes replaces with ordinary space. Did testing to see what kind of invisible people do. It's all over the place. Everyone does a weird varient <dael> florian: Suggestion is treat as ordinary space. Depending on whitespace property it may be collapsable. Partially matches Chrome. When whitespace is normal Chrome does that. When whitespace is not normal Chrome does different things. <dael> florian: Suggestion is from fantasai and I think it's good. This is kind of an error case <dael> emilio: filed it b/c wikipedia was complaining. Not sure about nobody uses it <dael> florian: Do they want it to do something? <dael> emilio: No, Gecko was doing something more weird. I fixed that more weird but when I looked how to handle it was all over the place as you said. <dael> florian: So I think you for the opportunity to write fun tests. Now that I've had my fun how about we change to a space and move on <dael> s/think/thank <dael> emilio: Okay with that but a change for all engines <dael> florian: Yeah. In main case it's what Chrome does <dael> chrishtr: #2 on yoru option list always? <dael> florian: Yes. It behaves as any space on whitespace:pre <dael> chrishtr: So Chrome just needs whitespace:pre to change? <fantasai> proposed resolution is "treat as U+0020" <dael> florian: Yeah, maybe other non-normal. I don't recall. <dael> smfr: Makes me a little nervious b/c they're more common in mac. <dael> florian: Yeah. Probably not shoing because actual carriage return is handled. It's an explicit escape <dael> smfr: Worried files converted to user entities. <dael> florian: Could. but what happens now is everybody is different <dael> Rossen_: I see soft agreement by koji on issue. Sounds like emilio is fine for Gecko to try. <dael> smfr: I won't object. I think we'd have to try it and see what happens <dael> Rossen_: Let's try and resolve. If we see a lot more information saying this is causing crazy breaks we'll discuss again <dael> florian: I think behavior in safari and FF isn't crazy but i could find so many ways to make something visual that this seemed a lot simpler <dael> florian: Prop: Treat CR as an ordinary space <dael> florian: I'll be more exact in spec <dael> Rossen_: Objections? <dael> RESOLVED: Treat CR as an ordinary space |
…, a=testonly Automatic update from web-platform-tests Test case for the css handling of U+000D (#25830) Relates to w3c/csswg-drafts#5410 -- wpt-commits: 6730dabbcc826e8ccbd6a9ee43d67c65e8626f29 wpt-pr: 25830
…, a=testonly Automatic update from web-platform-tests Test case for the css handling of U+000D (#25830) Relates to w3c/csswg-drafts#5410 -- wpt-commits: 6730dabbcc826e8ccbd6a9ee43d67c65e8626f29 wpt-pr: 25830
In #855 it was resolved that CR gets treated as any other control char, but looking at the history, we had to make it render invisible in https://bugzilla.mozilla.org/show_bug.cgi?id=941940 for compat reasons.
It seems Gecko and WebKit render it invisible, and Blink just treats lone CRs as an space. Probably both behaviors are acceptable compat-wise, but that doesn't match the spec.
cc @jfkthame @litherum @kojiishi
The text was updated successfully, but these errors were encountered: