Re: [csswg-drafts] [css-text-decor] Clarifying skip-ink:auto behavior in relation to CJK text (#4276)

The CSS Working Group just discussed `[css-text-decor] Clarifying skip-ink:auto behavior in relation to CJK text`, and agreed to the following:

* `RESOLVED: fully specify an algorithm that specifies ink skipping that references other specifications that isn't codepoint-by-codepoint`

<details><summary>The full IRC log of that discussion</summary>
&lt;Rossen__> Topic: [css-text-decor] Clarifying skip-ink:auto behavior in relation to CJK text<br>
&lt;astearns> github: https://github.com/w3c/csswg-drafts/issues/4276<br>
&lt;faceless> jkewL the issue is that text-decoration-skip-ink, browser have chosen generally not to apply this to CJK text because in practice it clases with most of the glyphs and looks terrible.<br>
&lt;faceless> s/jkewL/jkew<br>
&lt;faceless> jkew: what troubles me is that the webkit/chrome have chosen to skip this for a particular set of glyphs, but there's a disconnect as to which glyphs are skipped. In particular Blink has chosen to skip a number of punctuation chararacters<br>
&lt;faceless> jkew: I was hoping to the spec could pin this down to work on a sequence of script characters, so that punctuation surrounded by CJK is CJK.<br>
&lt;faceless> jkew: I'd like to settle on what we do in Firefox, which is better. At the moment the spec doesn't define it<br>
&lt;Rossen__> q?<br>
&lt;faceless> myles: consistancy is good but what the motivation? bug reports?<br>
&lt;faceless> jkew: I'm sure we did have reports<br>
&lt;faceless> myles: when you started implementing? Or was it issues around the specific characters?<br>
&lt;faceless> jkew: initially we simply implemented and found the same issues in CJK as everyone else<br>
&lt;koji> q+<br>
&lt;faceless> myles: in the absence of specific bug reports and users are not complaining, maybe we should leave it as it is?<br>
&lt;florian> q+<br>
&lt;faceless> jensimmons: can we perhaps specify it and see what comes form that?<br>
&lt;Rossen__> ack koji<br>
&lt;faceless> koji: i"m generally with myles on this. we had reports that our slashes looked quite bad. when looking at gecko they don't look bad<br>
&lt;jensimmons> jensimmons: is the desire of one browser to not put in the effort a reason to not spec interop. If interop on this is ideal, we can spec it and then each browser can make decisions about prioritization. (is the point I was making)<br>
&lt;faceless> kohi: so I believe we shuold add slashes to the list. So this is a heuristic. It's not testable. But I understand that if gecko gets reports that says the inconsistancy is troubling then this is an issue<br>
&lt;Rossen__> ack florian<br>
&lt;skk> s/kohi/koji<br>
&lt;faceless> florian: the spec is very vague, it says you can skip but not why. Even if we don't go all the way to defining a list, we may want to clarify the intent of this. That will not help with the immediate concern about interop, but it will help for anyone trying to understand or implement this<br>
&lt;faceless> myles: I can add some text about that<br>
&lt;Rossen__> ack dbaron<br>
&lt;faceless> dbaron: I think the situation today is if we don't define things, everyone will just copy what chrome does. So if what Chrome does is right, lets put that in the spec as we're going to copy it anyway. If not, put in the spec what is right.<br>
&lt;tantek> I feel like that needs to be repeated at the start of every CSSWG meeting<br>
&lt;faceless> myles: is not keen on that idea<br>
&lt;Rossen__> q?<br>
&lt;faceless> tab: if we do whatever chrome does, it should be an choice made because chroms is doing the right thing. I want' something written down because it will be a compat issue<br>
&lt;faceless> myles: if no-one has bug reports, it's not a compat issue yet. maybe we wait until the first report<br>
&lt;faceless> tab: we have enough issues to know that's not the best aproach<br>
&lt;faceless> s/aproach/approach<br>
&lt;Rossen__> q?<br>
&lt;Rossen__> ack dbaron<br>
&lt;faceless> dbaron: we've found that compat constraints get stricter over time. The longer things are out on the web, they require interop and expect it to get better over time. So if we find things that aren't we should fix that early<br>
&lt;faceless> dbaron: with the lack of bug reports, we have a cultural bias - filing them requires that you speak english and this is not the sort of bug report that english speakers will file<br>
&lt;tantek> ^^^ great FAQ answer for "Did you get a bug report?"<br>
&lt;koji> q+<br>
&lt;faceless> myles: I'm not going to push back on this. I would prefer that the approach taken is that text describing this is a reference to another spec, not a list of characters.<br>
&lt;faceless> koji: I'm fine to have some text added that allows the UA to have some heuristics. Our bug report was opposite. We had strong opinions. people said "don't just disable skipping because slashes look bad"<br>
&lt;faceless> myles: how would you formulate that in a spec? a list that need to be skipped and the rest are undefined? something else?<br>
&lt;faceless> koji: not strong on specifics, but if we got reports on a specific code point we could add that, but leave others undefined.<br>
&lt;faceless> rossen: who's going to write this up?<br>
&lt;faceless> myles: I volunteer jkew<br>
&lt;faceless> rossen: next action, jkew to modify the spec which - as myles suggests, references unicode - with a suggested approach that allows flexibility:<br>
&lt;faceless> ACTION: add specifics into ink-skipping details TBD. And that it's done by reference.<br>
&lt;faceless> ACTION: fully specify an algorithm that specifies ink skipping that references other specifications that isn't codepoint-by-codepoint<br>
&lt;Rossen__> RESOLVED: fully specify an algorithm that specifies ink skipping that references other specifications that isn't codepoint-by-codepoint<br>
&lt;faceless> fantasai: who's doing this?<br>
&lt;faceless> rossen: jkew<br>
</details>


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

Received on Friday, 24 January 2020 10:19:05 UTC