Re: [csswg-drafts] [css-text-3] Ogham Space Mark needs to disappear at the end of a line (#4893)

The CSS Working Group just discussed `[css-text-3] Ogham Space Mark needs to disappear at the end of a line`, and agreed to the following:

* `RESOLVED: Let editors choose the behavior and mark this at-risk`
* `RESOLVED: Publish new WD of css-text-3`

<details><summary>The full IRC log of that discussion</summary>
&lt;dael> Topic: [css-text-3] Ogham Space Mark needs to disappear at the end of a line<br>
&lt;dael> github: https://github.com/w3c/csswg-drafts/issues/4893<br>
&lt;dael> fantasai: Issue is that there is an ogham space mark. Let me show a pic<br>
&lt;fantasai> https://omniglot.com/writing/ogham.htm<br>
&lt;dael> fantasai: Writte on the line. In paragraphs it's on the line. Character called Ogham space mark<br>
&lt;dael> fantasai: When breaking lines should disappear at end of line.<br>
&lt;dael> fantasai: Wanted to add a rule you should drop final Ogham space mark when trimming<br>
&lt;fantasai> https://github.com/w3c/csswg-drafts/issues/4893#issuecomment-613175286<br>
&lt;dael> fantasai: Question how to do that.<br>
&lt;dael> fantasai: Implication are about what happens when you mix spaces and Ogham space marks<br>
&lt;dael> fantasai: Not likely to happen so it's what's easiest to implementa and we should pick that<br>
&lt;dael> florian: Main alternatives is at end of line you get rid of any mix of reg and Ogham spaces. Or you do in phases. Remove spaces, any Ogham left, you remove those.<br>
&lt;dael> AmeliaBR: Any other characters we treat as trimmable spaces for line wrapping but aren't classified in collapsable?<br>
&lt;dael> fantasai: Not that I know of and this is the only one mentioned in the report<br>
&lt;dael> florian: Tabs have been converted to spaces at that point<br>
&lt;dael> fantasai: Other visible word spacer marks but they don't disappear at end of line<br>
&lt;dael> fantasai: There might be others<br>
&lt;dael> astearns: Any notion which is easiest to implement?<br>
&lt;dael> AmeliaBR: Any cases where the two algorithms have different effects?<br>
&lt;dael> fantasai: Different effects. You can see it in the comment linked above<br>
&lt;dael> florian: I suspect two pass is easier to implement b/c you let unicode do normal and than a second pass rather than hacking to know about Ogham spaces. But I'm not implementing<br>
&lt;dael> fantasai: If no one on the call knows, please comment on issue. If not I'll do whatever Koji says<br>
&lt;dael> fantasai: Spec wording is new and not entirely clear so I'll tighten up a bit so it's clear<br>
&lt;dael> astearns: Any opinions?<br>
&lt;dael> astearns: We could resolve to do what koji says and mark at risk?<br>
&lt;dael> fantasai: Yep. Just say up to editors<br>
&lt;florian> s/you let unicode do/you let ICU do/<br>
&lt;dael> astearns: Prop: Let editors choose the behavior and mark this at-risk<br>
&lt;dael> astearns: Obj?<br>
&lt;dael> RESOLVED: Let editors choose the behavior and mark this at-risk<br>
&lt;dael> astearns: Publication with this change?<br>
&lt;dael> fantasai: Let's just publish to get an updated draft. Some issues left. Can do new WD<br>
&lt;dael> astearns: Does this publication need resolution?<br>
&lt;dael> fantasai: Yes<br>
&lt;dael> astearns: Prop: Publish new WD of css-text-3<br>
&lt;dael> astearns: Not in CR?<br>
&lt;dael> fantasai: Not yet.<br>
&lt;dael> astearns: Should push to CR<br>
&lt;dael> fantasai: That's the goal. I've triaged. A couple of things need comments. There's the whole removing break transformation which we've drafted.<br>
&lt;dael> astearns: Objections?<br>
&lt;fantasai> main open issue for css-text-3 is https://github.com/w3c/csswg-drafts/issues/337#issuecomment-612686124<br>
&lt;dael> RESOLVED: Publish new WD of css-text-3<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4893#issuecomment-614142693 using your GitHub account

Received on Wednesday, 15 April 2020 16:28:42 UTC