W3C home > Mailing lists > Public > public-css-archive@w3.org > December 2018

Re: [csswg-drafts] [css-text-3] Segment Break Transformation Rules for East Asian Width property of A (#337)

From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
Date: Wed, 12 Dec 2018 17:42:20 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-446677073-1544636539-sysbot+gh@w3.org>
The CSS Working Group just discussed `Segment Break Transformation Rules for East Asian Width property of A`.

<details><summary>The full IRC log of that discussion</summary>
&lt;dael> Topic: Segment Break Transformation Rules for East Asian Width property of A<br>
&lt;dael> github: https://github.com/w3c/csswg-drafts/issues/337<br>
&lt;dael> fantasai: This issue started as being about using [noise issues]<br>
&lt;dael> fantasai: using language information for doing break transformation. As I edited that in I ran into problems around emoji. They're wildly inconsitent about which characters are which east asian width and that's what we use to determine if line break is transformed<br>
&lt;dael> fantasai: To work around that we're taking a subset of emoji with a width of n or w and treating as ambig<br>
&lt;dael> fantasai: This issue is about if it's okay to make that change. If we don't characters like smile face has one behavior around line break and grinning face has a different behavior<br>
&lt;dael> fantasai: Sent email to author of east asian width spec to ask why inconsistent and they said they don't rec this for emojia nd use the emoji property so that's sorta what we're doing<br>
&lt;chris> It sounds like thir spec should be fixed<br>
&lt;dael> astearns: I'm not clear on koji's comments. Seems he's against. His last comment about troubles win over benefit<br>
&lt;dael> myles: Is email to unicode guy public?<br>
&lt;dael> florian: No<br>
&lt;chris> s/thir/Unicode/<br>
&lt;dael> myles: Would love to read<br>
&lt;dael> florian: I'll check with him before forwarding<br>
&lt;fantasai> https://unicode.org/cldr/utility/character.jsp?a=1F600&amp;B1=Show vs https://unicode.org/cldr/utility/character.jsp?a=263A&amp;B1=Show<br>
&lt;dael> florian: Not sure I understand koji either. We need to define somehow. East asian width of unicode is messy so I'm not going to be surprised if we come back. Pushing back means leave undefined or what?<br>
&lt;dael> fantasai: [reads unicode email]<br>
&lt;dael> myles: did we explore emoji related properties?<br>
&lt;dael> fantasai: That's what we did here.<br>
&lt;dael> astearns: Devining koji's intent. "Even though there are cases it looks strange it's interop, right" So is there interop behavior?<br>
&lt;dael> fantasai: Not sure how interop this set of rules are. Mox impl previous line break transformation and not all impl had. I do think case of line break transformation in emoji I don't think we have a web compat problem if we make an exception. I think we get weird results either way.<br>
&lt;dael> fantasai: Purpose of transformation rules is to make it easier to format source code of doc rather then put all text that can't have spaces on one line. If rules are unpredictable that's not helpful. Should treat all smileys same.<br>
&lt;dael> florian: I checked, there is no interop<br>
&lt;dael> florian: And that comment was about processing of line breaks entirely<br>
&lt;dael> astearns: "that comment" being which?<br>
&lt;dael> florian: Supression of space introduced by line break is done by FF and not by Chrome.<br>
&lt;dael> astearns: Given all this I think remaining question is if anyone is interested in impl this change<br>
&lt;dael> Rossen: It sounds like koji is not interested in impl based on comments<br>
&lt;dael> florian: I don't get if he disagrees with impl this feature in this way or if he doesn't want to impl the entire feature.<br>
&lt;dael> florian: Given Chrome doesn't impl feature and I can't tell if he's against implementing...<br>
&lt;dael> myles: I won't impl until I do another pass through spec and try and understand<br>
&lt;dael> Rossen: Try to cover when koji is on?<br>
&lt;dael> florian: Poss. If everyone up to speed on this feature in the first place?<br>
&lt;dael> astearns: I'm not sure a quick summary on the call is right. myles is going to look through spec to get up to speed. Maybe we leave this open. It's in the spec and we have issue with intent to keep in but leave it to review and raise objections.<br>
&lt;dael> astearns: I know we just closed an issue where we left it in thatstate for 6mo but coming back in Jan might let people get up to speed<br>
&lt;dael> fantasai: Or next week<br>
&lt;dael> myles: I could have something to say by next week<br>
&lt;dael> astearns: Let's leave to next week. I'll ping koji to clarify his comments<br>

GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/337#issuecomment-446677073 using your GitHub account
Received on Wednesday, 12 December 2018 17:42:26 UTC

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