- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Fri, 16 Sep 2022 17:54:27 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Backslash and Yen`. <details><summary>The full IRC log of that discussion</summary> <TabAtkins> Topic: Backslash and Yen<br> <TabAtkins> github: https://github.com/w3c/csswg-drafts/issues/6848<br> <TabAtkins> fantasai: WebKit has a bunch of code to handle this problem - the backslash is often rendered as a Yen sign, especially on Windows systems, for historical reasons<br> <addison> (or a won sign or a yuan sign; special handling is on non-Windows OS)<br> <TabAtkins> fantasai: The special handling in WK is they check if they have one fo the "known problematic fonts" or if the encoding is one of the "known problematic encodings", they'll render the backslash as Yen, kinda like a text-transform.<br> <TabAtkins> fantasai: So for the WG, do we want a heuristic for this like the WK stuff, or do we want to ask them to ignore it?<br> <TabAtkins> fantasai: Currently text rendered on Windows doesn't look like other OSes, because the Yen characters appear on Windows and not elsewhere.<br> <TabAtkins> addison: One issue is that it's an expectation of some speakes that the path separate is actually a Yen<br> <TabAtkins> addison: So actually showing backslash might not be expected by the user.<br> <florian> q+<br> <TabAtkins> florian: bc this is a strong expectation in japan/korea, at least, that the backslash doesn't look liekt he backslash, authors will continue author this way, and if it works inconsistently based on the system that's not good. I think we should try for interop.<br> <TabAtkins> florian: Reason it works on Windows is the fonts; if you don't ahve the right font it won't happen<br> <addison> s/liekt/like/<br> <emilio> q+<br> <TabAtkins> florian: So the font heuristics shoudl probably be standardized<br> <TabAtkins> florian: On top of that, I think authors should be able to control this more directly.<br> <drott> q+<br> <TabAtkins> florian: An @font-face descriptor that lets them say what this font is doing wrt backslash or yen<br> <TabAtkins> florian: Otherwise pages authored on windows will look different on Mac or Android, etc.<br> <TabAtkins> florian: So we should aim for interop on at least the heuristics.<br> <hober> q+<br> <TabAtkins> florian: And likely go byeond to let authors specify.<br> <astearns> ack emilio<br> <TabAtkins> emilio: The compat issue on Mac comes from authros not specifying a font-name, or specifying a font that doesn't exist?<br> <TabAtkins> addison: The last one.<br> <TabAtkins> emilio: In taht case, can that font be shipped on Mac?<br> <addison> I believe locales for JP, KR, TW, and CN regions do this<br> <TabAtkins> florian: And Android, and Linux...<br> <TabAtkins> emilio: These kinds of heuristics don't seem terribly appealing to implement... I'd rather not have them, especially if it works on windows due to fonts<br> <David-Clarke> s/authros/authors/<br> <addison> This is rooted in DOS code page behavior<br> <TabAtkins> myles: there's no way we can ship this font on iOS or Mac, that options is off the table<br> <TabAtkins> emilio: can you explain why?<br> <florian> q?<br> <astearns> ack drott<br> <TabAtkins> hober: fonts are expensive; this would have to be a business arrangement, and the spec probably shoudlnt' rely on that existing for all OSes<br> <TabAtkins> drott: Can we discuss what th eheuristic would look like? Is it like "this window font as the primary in the font stack"?<br> <fantasai> WebKit heuristic is described here: https://github.com/w3c/csswg-drafts/issues/6848#issue-1067848361<br> <florian> q+<br> <TabAtkins> drott: And second to emilio, I don't think I'd like to carry this legacy issue further by putting it into @font-face<br> <emilio> +1<br> <TabAtkins> drott: So probably fint with a heuristic but not futher<br> <TabAtkins> fantasai: Heuristic is "problematic font? problematic encoding? yes to either, render backslash as yen"<br> <TabAtkins> iank_: What does "render" mean?<br> <TabAtkins> fantasai: Do a text-transform, basically.<br> <TabAtkins> myles: And this is a whole-element thing, looking at primary font, not a glyph-by-glyph sub.<br> <TabAtkins> drott: So primary font of the element, ok.<br> <David-Clarke> q+<br> <TabAtkins> fantasai: So just checking, you're looking at computed 'font-family' and looking at the first font in the list?<br> <TabAtkins> myles: Probably, yes, I'll need to check.<br> <TabAtkins> myles: Also this code is older than the Blink fork. But this behavior doesn't happen in Mac Chrome, so presuambly it was deleted?<br> <TabAtkins> iank_: I'd have to dig into the history, yeah<br> <JakeA> q+<br> <TabAtkins> myles: grep for "yen sign" in the webkit codebase to find it in ours<br> <astearns> ack hober<br> <David-Clarke> q-<br> <emilio> https://searchfox.org/wubkat/rev/0c40ba62b482511fe03646f1d4982efd727475dd/Source/WebCore/rendering/RenderText.cpp#1345-1346<br> <emilio> iank_: ^<br> <TabAtkins> hober: Sometimes we need heuristics for compat reasons, but that makes me nervous<br> <TabAtkins> hober: So one, heuristic should be as simple as possible.<br> <TabAtkins> hober: And two, spec is as a floor; this is the minimum for compat, but you might do better, and hopefully bring it to the group to specify.<br> <astearns> ack florian<br> <andreubotella> q+<br> <TabAtkins> florian: I'd like to push back against this as legacy. It's a compat problem, but it's not rooted in the past; it's the current expectation for Korea and Japan users<br> <TabAtkins> florian: I don't think a German user wants their path filled with Yen signs, so it's not spreading.<br> <drott> q+<br> <TabAtkins> florian: The primary offender is Windows system fonts, but Japanese fonts are often *written* this way.<br> <emilio> https://searchfox.org/wubkat/rev/0c40ba62b482511fe03646f1d4982efd727475dd/Source/WebCore/platform/graphics/FontCache.cpp#457 is the font-family check<br> <TabAtkins> florian: So if your primary font is one of these manually-authored fonts, but it didn't download, you'll have this problem again.<br> <dholbert> q+<br> <TabAtkins> florian: So that's why my suggestion for @font-face exists, so authors can tell us what their font expects and we can do the right thing just like if it was a windows system font.<br> <florian> q?<br> <TabAtkins> myles: Right now there are zero browsers that do this on a font-by-font basis; putting it in @font-face would mean we have to invent a new mechanism<br> <astearns> zakim, close queue<br> <Zakim> ok, astearns, the speaker queue is closed<br> <drott> q-<br> <JakeA> q-<br> <TabAtkins> florian: I don't see why that would be required - the descriptor would just tell you whether the font is one that needs the transform<br> <TabAtkins> (I assume this would just cause the font to trip the "problematic font?" part of the heuristic.)<br> <astearns> ack andreubotella<br> <TabAtkins> andreubotella: What happens on Windows if you copy text with this behavior?<br> <TabAtkins> addison: They'll copy a backspace, that's the acutal character<br> <TabAtkins> andreubotella: Is that what authors expect?<br> <TabAtkins> addison: They'll see it as a Yen when they paste, as well. The only difference will be if they put it in a message and send it elsewhere.<br> <TabAtkins> JakeA: Note that text-transfo9rm doesn't usually do that; it typically changes what you copy<br> <TabAtkins> fantasai: For some values; for other values (like fullsize-kana) you do *not* copy the transformed version of the text.<br> <astearns> ack dholbert<br> <addison> s/They'll/Windows users will/<br> <iank_> Our bug relating to this: https://bugs.chromium.org/p/chromium/issues/detail?id=305827<br> <fantasai> And I would argue that text-transform should never copy out the transformed text<br> <TabAtkins> dholbert: Does the text-transform handle the scenario where the font has a backslash but not a yen character?<br> <TabAtkins> myles: We don't handle that; rather, I don't know what happens, but we don't seem to do anything special.<br> <drott> q+<br> <addison> Not just yen sign... sometimes the won sign (in Korea)<br> <TabAtkins> dholbert: So possibly rendering tofu rather than slash<br> <drott> q?<br> <drott> q-<br> <TabAtkins> myles: Probably just doing a fallback, like text-transform:uppercase on a font with only lowercase will trigger fallback<br> <emilio> Gecko also implemented this hack and removed it: https://bugzilla.mozilla.org/show_bug.cgi?id=926580<br> <TabAtkins> drott: I foudn the Chrome bug to remove the hack<br> <addison> s/foudn/found/<br> <TabAtkins> drott: There was some question of whether content was being created expecting this, and if we could phase it out<br> <David-Clarke> All the fonts and encodings shown in the example are Japanese, but this affects Korean?<br> <TabAtkins> astearns: Seems the answer is yes, and no.<br> <TabAtkins> florian: When Windows reaches 0 market share...<br> <TabAtkins> myles: I asked another group earlier this week - in Japanese keyboards, is there separate backslash and Yen keys? If not, what keycode comes out?<br> <TabAtkins> florian: Think the answer is "depends on the keyboard"<br> <TabAtkins> astearns: Probalby enough discussion - is there appetite from gecko and blink to specify a simple heuristic and implement it?<br> <TabAtkins> iank_: I think the problem is... i'm looking at the patch that removed this, and it's a lot bigger than a text-transform.<br> <TabAtkins> iank_: Appears to be special code...<br> <TabAtkins> astearns: Re: tess's point, the rule should be simple and you should implement it as you want.<br> <TabAtkins> chris: the backing store is a backslash<br> <TabAtkins> fantasai: I'd said before it depends on the transform<br> <TabAtkins> myles: from a user perspective it looks like a Yen, so they'd expect a Yen<br> <addison> (if you paste into a cmd shell, you want the path separator to be a path separotr)<br> <TabAtkins> florian: Unsure that's true, to the user it's a path separator, and that's a specific codepoint<br> <TabAtkins> emilio: I'd want to check with jfkthame and the Japanese folks<br> <TabAtkins> emilio: But given we removed this a while ago, I don't think so. We could reconsider, I guess.<br> <TabAtkins> drott: The previous patch didn't seem to be text-transform based<br> <TabAtkins> ACTION drott to investigate for Chrome<br> <TabAtkins> ACTION emilio to investigate for Firefox<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6848#issuecomment-1249645495 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 16 September 2022 17:54:29 UTC