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

> Are you OK with this, or would you prefer to revert it?

Sorry it seems I wasn't clear enough. By "revert" do you mean there was already a resolution? I guess I missed it then.

In short, I'm not interested in implementing it and rather negative, but if other impls are interested in or if there was already a resolution, I would not object.

Longer version; IIUC this issue contains two related but separate issues; EAW=A and Emoji.

Blink currently implements segment transformation rules including CJK cases in LayoutNG, and IIUC it makes Blink interoperable with Gecko. I think that it will not get updated further for the first phase of LayoutNG.

For EAW=A,  I'm neutral on this. If other implementers ship it, I may consider in future. fantasai and I discussed this several years ago, and she was negative at that point, because it can solve some cases but never can solve all cases, leaving inconsistency. Now it looks like she wants to try to solve some cases. It's still inconsistent and rules is probably not clear to authors, but solving some non-rare cases maybe a win.

For Emoji, I'm rather negative. I'm not interested in implementing it, probably in a foreseeable future. I'm not sure how far we plan to go on this feature, but as I understand from the motivations, what we really want is the consistency for color Emoji, correct? Then what we need is the logic to determine color Emoji, because both U+263A SMILING FACE and VS16 U+0030 DIGIT ZERO should look like Emoji. We will also need to take CSS Fonts properties we define to switch between text and color Emoji. Blink currently determines the used font in the shaping phase, and we don't want to shape during the white-space collapsing.

If we were to give up at some point, it will be implementable, but it means we will accept to live with inconsistencies at some point, so the benefit is limited. The user cost still exists, since ASCII range is included, the logic for every line end runs on every page of every user, consuming loading time, batteries, etc. Current other rules can be optimized out for plane 0 (U+0000-U+00FF) content.

So the question to me is that, assuming we will accept inconsistencies at some point, is improving the inconsistency a little more worth the user cost? It may depend on where we will give up, but I prefer saving user cost, because I think authors can figure it out if the rules are interoperable across all browsers.

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

Received on Thursday, 13 December 2018 04:51:41 UTC