W3C home > Mailing lists > Public > public-css-archive@w3.org > September 2020

Re: [csswg-drafts] [css-text] Reconsider the resolution on #855 (#5410)

From: Florian Rivoal via GitHub <sysbot+gh@w3.org>
Date: Thu, 03 Sep 2020 13:42:56 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-686501195-1599140575-sysbot+gh@w3.org>
Sounds that we have a few options:
1. treat it as a control character and make it visible, as a hex box or something like this. (what the spec says)
2. treat as a collapsible space
3. treat as invisible, which can have variants
    a. treat it as if it was nothing there (no impact shaping, no wrapping opportunity)
    b. treat as if there was something left behind that breaks shaping and introduces a wrapping opportunity
    c. treat as if there was something left behind that preserves shaping but introduces a wrapping opportunity
        i. when the line is wrapped, shaping is preserved across the line break
        ii. when the line is wrapped, shaping is not preserved across the line break
    d. treat as if there was something left behind that breaks shaping but does not introduces a wrapping opportunity

As far as I can tell using https://lists.w3.org/Archives/Public/www-archive/2020Sep/att-0001/CR.html:

* Firefox 80 and Safari 14 do 3.b.
* Chrome 84 does 2. when `white-space` is `normal`, but 3.d. when `white-space` is `pre-wrap`
* Edge 18 (non-chromium) does 3.c.ii.
* Prince 13.4 does 3.d.
* Vivliostyle 2.1.1 does 3.c.ii.

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 https://github.com/w3c/csswg-drafts/issues/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.

GitHub Notification of comment by frivoal
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5410#issuecomment-686501195 using your GitHub account

Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 3 September 2020 13:42:57 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:42:15 UTC