W3C home > Mailing lists > Public > public-css-archive@w3.org > March 2019

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, 13 Mar 2019 16:59:24 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-472512939-1552496362-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: Leftover from F2F so prob get rid of<br>
&lt;dael> astearns: This is def a better int he room discussion. DOn't know if we want to wait 3 months<br>
&lt;dael> fantasai: I'd like to get text to CR before that but this is main issue blocking CR<br>
&lt;dael> astearns: How do we get to resolution<br>
&lt;dael> fantasai: I think current text is fine. I don't know if anyone has issues. I think myles not happy<br>
&lt;dael> myles: Yep<br>
&lt;dael> fantasai: Dunno where to go from there<br>
&lt;dael> florian: Support current text<br>
&lt;dael> astearns: myles do you have a suggestion to improve<br>
&lt;dael> myles: Not concretely but using a solution from unicode where experts agree won't work well and doesn't have symantic meaning seems wrong direction. WE would work with unicode to come up with classes we need<br>
&lt;dael> florian: We're the only user of that thing b/c relates to how css and html wrap lines or source code. So if we're not doing effort they'r enot either. Solving this usefully for most cases is sufficient to be useful. I hear what you're saying but it seems like this is the perfect as the enemy of the good<br>
&lt;dael> myles: We're using this to determine where to unbreak lines. Knowing if char or parts of scripts use spaces is useful for any text editor. And I think that, you're right that perfect enemy of good is not the best way to create the web but I'm worried we'll come up with a busted solution and be stuck forever<br>
&lt;dael> florian: Not too worried because we're not trying to solve netire problem but instead a useful chunk. I think the defined part is safe. If we look for areas of unicode we can find where we should have used more but we're using a safe subset. If unicode does better in the future it will include what we defined<br>
&lt;dael> myles: If we encourage authors in cjk to add new lines in source code we need interop<br>
&lt;dael> florian: Oh yeah, we do. The part we have is safe to get interop on. What I mean is that I don't forsee given the subset we're defining I don't see us having to remove from it. Having to add to it maybe, but not remove.<br>
&lt;dael> myles: If we're considering this solved and say to authors add line breaks where you want it will be wrong in many places and those in the future will change when we have better solution<br>
&lt;dael> florian: That's the thing I think will not happen. If we later expand we will create new places where they can break, but the places we're offering here will stay. If you find such a thing please call it out. I think we will find other places in unicode where we can add breaks, but I don't think we'll remove from the current list. So there's no risk in that sense<br>
&lt;dael> astearns: Risk is limited to if the current attempt at fixing a subset is a true subset of the eventual good solution or not<br>
&lt;dael> astearns: I don't have a way of evaluating if what we have now is a true subset<br>
&lt;dael> astearns: One question - does anyone know if current prop rules are enough for a native Japanese author who has no idea of anything to do with unicode and they're just writing Japanese is there a set of rules for this author that would make sense? Can we tell them you can put line breaks where you want or is it complicated?<br>
&lt;dael> florian: For Japanese it's mostly straightfoward when writing text. If you're doing dingbats in the middle it gets weird. In text it's fine. Dingbats isn't Japanese specific, they just get weird.<br>
&lt;dael> astearns: I have not read whole thread, it is long. Have we had anyone from unicode give a thumbs up that this is a safe subset?<br>
&lt;dael> florian: Had conversation with unicode but mostly off topic because they didn't understand what we were trying to do<br>
&lt;dael> myles: That convo the expert didn't comment about the specific modification in the spec right now, but said prop these modifications are based off of....I don't want to put words in mouth but said it was fairly broken<br>
&lt;dael> fantasai: And they broke it even more recently<br>
&lt;dael> myles: Seems like the wrong thing to base on<br>
&lt;dael> fantasai: We're working around that by ignoring a subset of characters they decided to change<br>
&lt;dael> fantasai: If we're gonna do anything like this this is the set of properties. Alternative is ask unicode for a new prop which seems unlikely<br>
&lt;dael> myles: Not nec just this purpose. Knowing if char are part of a script that uses space as line breaks is useful Spec says [reads]<br>
&lt;dael> myles: It jsut seems like we're patchign abroken system and we should try and solve properly<br>
&lt;dael> florian: Not jsut special cases. A large chunk of the text is the necessary conditionals to make sure we're in the right language. THis new fabled unicode thing wouldn't know what lang you're in. THat part would stay in CSS. If we're keying off [missed] it could be better from unicode, but keying from language cannot<br>
&lt;dael> astearns: Agree with myles that I'm a bit worried about referring to a thing in unicode that they want deprecated and don't care enough to prevent it from having changes. If this is something unicode is not interested in keeping stable we shouldn't reference it<br>
&lt;dael> florian: Therefore we don't solve?<br>
&lt;dael> astearns: We work with unicode to come up with something they want to maintin and contribute expertese so we can come up with better handling that's maintained and can rely on<br>
&lt;dael> florian: It's not marked as deprecated. It's in the spec they're theoretically maintained and they're doing a bad job of it. We cna start paying attention and raise issues. Their opinion is that in current shape it's not useful, but it's still in the spec<br>
&lt;dael> astearns: This will need to kick back to the issue for discussion. I'll see if we can get Ken to engage on the particular problem we're trying to resolve<br>
&lt;dael> fantasai: Maybe reach out to other unicode people too<br>
&lt;dael> astearns: Suggestions on who?<br>
&lt;dael> fantasai: myles had Apple's contact. We've got other people from unicode. I'll try and reach out<br>
&lt;dael> astearns: I think that's where we'll leave this<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/337#issuecomment-472512939 using your GitHub account
Received on Wednesday, 13 March 2019 16:59:25 UTC

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