Re: web における和欧間スペース

I have a fair amount to say about this. Apologies for being in English.

The mojikumi aki is a context-sensitive (depends on character class as well as location in the line) and adjustable spacing. There still seems to be confusion about whether the space is a Unicode character being added or whether it is simply layout (due to overlap with workarounds that use U+0020?).

I see it as strictly layout:

  1.  The width of space changes based on justification of the line, kinsoku at line end, and which characters abut the space. These varying widths have nothing to do with a given glyph width in a font, be it that of U+0020 or any other space glyph.
  2.  Inserting characters in the line to accomplish spacing in a static sense gets very messy when reflowing the text such that such space should change width, or even change width in the same line due to a differing context.

I see much of the "layout-only" discussion talking about the presence or absence of the space, not of its adjustability. But, although it may seem very fancy, how can you get away with a constant aki amount in any but very simple use cases? It just isn't ever constant. Even when it doesn't adjust (in UI or single line runs), it varies according to the application and need for tightness. The tightness factor is more or less allowed by the context (e.g. after full-stop, generally the amount of space doesn't shrink, but would shrink to achieve tighter layout around other punctuation).

--Nat
________________________________
From: 木田泰夫 <kida@mac.com>
Sent: Monday, June 27, 2022 6:43
To: JLReq TF 日本語 <public-i18n-japanese@w3.org>
Subject: web における和欧間スペース

EXTERNAL: Use caution when clicking on links or opening attachments.


JLReq TF の皆さま、

CSS ワーキンググループの GitHub で和欧間スペースが議論されています。
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fcsswg-drafts%2Fissues%2F6950&amp;data=05%7C01%7Cnmccully%40adobe.com%7Cc6ed56c1349740e2010008da58430dc5%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637919342272680627%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=dlm17pWIp%2Bbogh5Q2u%2FQCUwxA%2FlyUNwKg%2B3Ph7es%2BAE%3D&amp;reserved=0

非常に簡単に説明すると、提案者は ideograph-alpha と ideograph-numeric つまり英数字と漢字の間の空白をデフォルトで ON にすべきではないか、と提起し、それに対して議論が起こっています。JLReq TF からも意見を出すべきかと思います。

出ている議論をかいつまんでみますと：
・互換性の問題はどうする？おそらく数行以上のテキストでは影響が少ない。一行だけのUIなどで影響の出る可能性がある
・trim-adjacent や allow-end で既に壊したではないか
・難しい判断だ。互換性の問題 vs 望ましい挙動を得るために未来永劫プロパティを付けることを要求する & 自動変換などでそれができない場合もある
・iOS の UI は最近空白を入れ始めた
・clreq から印刷の例がいくつか示されている。オンラインテキストの例は web がサポートしていないので、参考にすべきではないだろう
 etc.

議論する際に「何が望ましいか」と「デフォルトはどうあるべきか」を分けることは整理のために重要かと思います。また、望ましい挙動を示すとして、空間の大きさを示すことも有益かと思います。

皆さま、いかがでしょう？

木田