JLReq TF meeting notes 2024-3-25, 4-12, 4-17 w/fantasai

[kidayasuo]

日本語版

These are notes/discussions from a series of meetings that reviewed the CSS Text Level 4 draft. We scanned through the draft based on the summary Murakami-san created to identify potential issues on 3-25, explored them in depth at the F2F on 4-12, and discussed the results with fantasai at the F2F on 4-17.

• Comments on the 3-25 notes by Murakami-san (J)
• Agenda for 4-17 meeting with fantasai (J)
• Meeting notes 4-17 w/fantasai (E)

JLReq TF meeting notes 2024-3-25

(Parts of the text below was translated from Japanese with chatGPT)

At this meeting we mostly focused on reviewing CSS Text Level 4.

Presentation by Nat regarding baseline between Japanese and English

I missed the part but issue is about inconsistent underline position when multiple fonts are used typically between Japanese and English. We are planning to discuss this at the next meeting on 12th.

CSS Text Level 4 review

The review notes are attached at the bottom.

Next meeting

It seems everybody visits Japan in April.

• The next meeting is F2F on April 12th using the opportunity that Nat is in Tokyo.
• We’ll have another F2F on 17th with fantasai.
• As all these will focus on CSS Text, we are planning to have regular meeting, probably on 23rd?

CSS Text Level 4 review notes

2. Transforming Text

2.1. Case Transforms: the ‘text-transform’ property

Note: text-transform: full-width can be useful to turn alphabets and numbers into full-width characters in vertical writing. text-orientation: upright is similar, but keeps characters proportional and upright. full-size-kana turns small kana into larger characters.

Question: Can UA use OpenType's fwid feature to make characters full-width? or is it for characters that have their full-width counter part? It does not seem to be clear from the document.

Discussion: Small Kana characters differ in meaning from regular ones, that is they represents different phonemes. Since other cases transform between characters of the same phonetic value, such as uppercase and lowercase or full-width and proportional, full-size-kana seems misplaced here. Should it not be a separate property? (Nat) (Kida: However, when small Kanas are enlarged in ruby they represent the same phonetic value, right?)

Feedback: However full-width is useful for vertical writing it can’t be applied to the whole text because you would want to make two-digit numbers tate-chu-yoko, transform most other numbers to Kanji, etc. It means you need to apply different features to different parts of the document. This is not practical, and the actual industry practice is to modify text to make it suitable for vertical text. It poses an issue against the principle of the separation of content and presentation.

2.2. Expanding Between Words: the ‘word-space-transform’ property

Note: This property can be used for Japanese word separation. The auto-phrase feature automatically identifies phrases. There's an example on how to distinguish between word and phrase separation.

Discussion: Well received especially for accessibility.

2.3. Order of Operations

3. White Space and Wrapping: the ‘white-space’ property

Note: Combines the techniques defined in section 4: ‘white-space-collapse’, ‘text-wrap-mode’, and ‘white-space-trim’. Oddly enough, this forms a separate chapter.

4. White Space Processing & Control Characters

Note: There may be extra spaces or line breaks in the source text. This section discusses properties to ignore them.

Question: In the style of starting a Japanese paragraph with a full-width space, if one wants to switch to a paragraph style separated by blank lines, is it necessary to ignore this paragraph-leading full-width space using this property?

4.1. White Space Collapsing: the ‘white-space-collapse’ property

Note: Defines how consecutive white spaces or newline characters are treated.

4.2. White Space Trimming: the ‘white-space-trim’ property

Note: Specifies ignoring spaces and newline characters before, after, and inside a specified box.

Question: It's unclear how this differs from ‘white-space-collapse’. Also, the term collapse seems to mean condensing consecutive spaces into one character under ‘white-space-collapse’, whereas under ‘white-space-trim’ it seems to mean eliminating them altogether.

4.3. The White Space Processing Rules

Note: Explains how the above properties work. It’s quite complex.

4.3.3. Segment Break Transformation Rules

Feedback: There is an issue with Japanese text where white spaces are inserted between characters in a line. The NOTE asks "Should we define this for Level 4?" Yes, please. It would be useful if it describes at least cases where segment breaks should be removed.
2. Then any remaining segment break is either transformed into a space (U+0020) or removed depending on the context before and after the break. The rules for this operation are UA-defined in this level.

Question: Does the problem of white spaces being inserted when pasting Japanese text relate closely to the above, or is it beyond the scope of CSS?

4.4. Tab Character Size: the tab-size property

5. Text Wrapping

5.1. Deciding Whether to Wrap: the text-wrap-mode property

5.2. Controlling Breaks Within Boxes: the wrap-inside property

5.3. Controlling Breaks Between Boxes: the wrap-before/wrap-after properties

5.4. Selecting How to Wrap: the text-wrap-style property

Note: Defines values for intelligent line-breaking. balance: Mainly for titles and captions. Ensures that the spacing left at the end of each line is even across lines. pretty: For main text. Prioritizes quality over speed in finding wrap points. stable: For editable text. Prevents text from shifting during editing by not considering subsequent lines.

5.5. Joint Wrapping Control: the text-wrap shorthand property

5.6. Line Breaking Details

Discussion: Although it is not related to CSS, the rules for wrapping lines in Japanese must be appropriately reflected in Unicode.

6. Line Breaking and Word Boundaries

Feedback: Are there any reasons why some languages are in parentheses and some are not?
In others such as Chinese (as well as Japanese, Yi, and sometimes also Korean),

6.1. Breaking Rules for Letters: the word-break property

Note: auto-phrase identifies and separates phrases. Useful for titles, presentations, picture books, and poetry.

Discussion: Web designers are struggling. In Japanese, where should breaks occur? (Clarify exactly what the issue is in the next meeting)

Question: Does break-all ignore Kinsoku rules? Is Kinsoku disregarded when specifying break-all? "NOTE: This value does not affect whether there are soft wrap opportunities around punctuation characters. To allow breaks anywhere, see line-break: anywhere." So, it is not ignored?

Discussion: EXAMPLE 19: Although not related to CSS, should the habit of arbitrarily cutting Latin text strings in Japanese stop? It's unreadable if broken at strange places. If it needs to be broken mid-string, shouldn't it be properly hyphenated? If it becomes very long when in full-width, it can't be helped?

6.2. Line Breaking Strictness: the line-break property

Note: Control of Kinsoku rules. Loose, strict. Follows Unicode definitions. auto looks at the line length 👍

Note: Future versions of CSS plan to offer finer control (perhaps at the character level?).

6.3. Hyphenation: Morphological Breaking Within Words

6.4. Overflow Wrapping: the overflow-wrap/word-wrap property

Question: How does this interact with ruby which is not foldable?

7. Alignment and Justification

7.1. Text Alignment: the ‘text-align’ shorthand

7.2. Character-based Alignment in a Table Column

7.3. Default Text Alignment: the ‘text-align-all’ property

7.4. Last Line Alignment: the ‘text-align-last’ property

7.5. Justification Method: the ‘text-justify’ property

Feedback: What is the purpose of ‘ruby’? If it is primarily for Bopomofo, it should be stated as such.

7.6. Aligning a block of text within its container: the ‘text-group-align’ property

8. Spacing

8.1. Word Spacing: the word-spacing property

Note: Adjusts the width of space characters between words. Does not affect fixed-width spaces, including full-width spaces.

8.2. Tracking: the letter-spacing property

Note: Also known as tracking. Adjusts the spacing between letters, which may be further adjusted during justification.

Feedback: Section 8.3 says “Whereas letter-spacing adjusts spacing between typographic letter units” whereas section 8.2 says “This property specifies additional spacing (commonly called tracking) between adjacent typographic character units.” Which is correct? (Kida)

8.3. Line Start/End Padding: the ‘line-padding’ property

Note: Sets equal padding at the start and end of lines.

8.4. Automatic Contextual Spacing: the ‘text-autospace’ property

Note: Achieves space between Japanese and Western characters. With 'replace' specified, it ignores existing spaces and applies the defined space between Japanese and Western characters, adding an amazing feature. If spacing between characters is specified, it adds to that value.

Feedback: The default value is 1/8. Shouldn’t there be a way to control this value? The appropriate value varies depending on the font design, possibly other factors and preference.

Feedback: Ishii-san, xfq and Kida are currently proposing to Unicode which characters should be spaced and which should not.

Feedback: Which characters should be spaced or not may vary depending on the font, application or the site policy. The ability to apply finer control to the default rule is highly desirable (Kida).

8.5. CJK Punctuation Spacing: the text-spacing-trim property

Note: Settings for consecutive punctuation spacing. Default is ‘normal’, focusing on compatibility, not trimming at the start of lines and only trimming at the end of lines if necessary. ‘space-all’ does nothing, maintaining the original width provided by the font.

Discussion: There were significant discussions about this at the meeting on 3/25.

Discussion: trim-auto, auto is not supported by Chrome yet. As implementation has just begun, we need to observe future developments. Once Text Level 4 becomes official, it will be covered in the JLReq TF Gap Analysis.

Discussion: There's an issue with Yu Gothic UI included with Windows. The halt value is incorrect. This font is completely proportional, but how should a Japanese proportional font with punctuation be ideally? There would be space for non-continuous punctuation, which should be trimmed when continuous. However, it cannot be assumed that cutting glyphs in half unconditionally is acceptable, so without halt, it cannot be halved or turned into half-width.

Discussion: Sometimes it may be necessary to distinguish between commas and periods (when? kida)

Feedback: Isn't a guideline needed for auto? (Murakami)

Feedback: In the description of 'space-first', it says "on the first line the block container," should it be "first line of the"?

Feedback: 8.5.1's NOTE on the judgment method does not seem to accommodate fonts that has full-width Kanji and proportiona Kana, ones that have different fixed width for Kanji and Kana.

Feedback: In the NOTE below 8.5.1, "Some fonts have fullwidth punctuation characters whose blank are too small to trim (kern)." What does kern mean?

Todo: Detailed review needed for 8.5.1-8.5.3.

8.6. Character Class Spacing Shorthand: the text-spacing property

Note: Simplifies setting ‘text-autospace’ and ‘text-spacing-trim’.

8.7. Shaping Across Element Boundaries

Note: Describes conditions where cursive scripts like Arabic are allowed to break apart.

9. Edge Effects

9.1. First Line Indentation: the ‘text-indent’ property

Feedback: How does it handle fonts where the width of kanji (ic) and full-width spaces are different? Japanese paragraph style, if one wants to achieve it via CSS, requires a definition of the width of the full-width spaces. Below is feedback from the Type Project regarding their AXIS Condensed fonts.
Kida-sama, we appreciate your continued support. Below is the response from our engineer. "AXIS Font Condensed is designed with the understanding that kana are primarily used in Japanese typesetting, hence full-width spaces and full-width punctuation are set to the width of kana."

9.2. Hanging Glyphs

Feedback: It's unseemly for periods used for abbreviation in Japanese to hang at the end of a line (Professor Toshi) (Kida: How should it be?)

Question to Bin-sensei: Is there a method in Japanese like in English where quotation marks or parentheses hang over the front or back?

Discussion: Is it possible to set ruby to hang above in horizontal writing?

9.3. Bidirectionality and Line Boxes

Note: About handling languages that are written from right to left.

[kidayasuo]

JLReq TF meeting notes 2024-3-25

CSS Text Level 4 draft のレビューを行った。3-25のミーティングで村上さんのサマリーをベースにドラフトの全体をレビューして問題点となりそうな点を抽出した。4-12のF2Fミーティングで、それらの点についてさらに議論し、4-17のF2Fミーティングでそれらの点をfantasaiと議論し今後のアクションを決めた。

• Comments on the 3-25 notes by Murakami-san
• Agenda for 4-17 meeting with fantasai
• Meeting notes 4-17 w/fantasai

また、3-25および4-12のミーティングにおいて、Natさんから、日本語と英語のフォントを混在させた場合のベースライン位置についての問題提起のプレゼンがあった。これについては別個のディスカッションとして記録する予定。

下線の位置が日本語と英語の間でズレる問題

私は遅刻してしまって内容を見ていないのですが、12日に再度議論することになっています。

CSS Text Level 4 review

長いので次回のミーティングの下に。

次回のミーティング

• 次回のミーティングはNatが東京にいる機会を利用して、会議室/zoomのハイブリッドで12日に行われます。
• その次にfantasaiとのミーティングが17日に予定されています。これも会議室/zoomのハイブリッドです。
• 3/25のミーティングを含め、CSS Textに使ってきたので、jlreq-dやGH issueをカバーする通常のミーティングを23日に考えています。12日に決めましょう。

CSS Text Level 4 のレビュー結果

木田が後で気がついて加えたコメントを含みます

2. Transforming Text

2.1. Case Transforms: the ‘text-transform’ property

Memo: text-transform: full-widthは縦書きで英字や数字を全角にするのに使える。text-orientation: upright は似ているが、文字をプロポーショナルのまま upright にする。full-size-kana はルビの小書を大きい文字へ。

Question: UAはOpenTypeのfwidフィーチャーを使うか？それとも文字コードの対応だけか？　ドキュメントからは明確ではないように読めた。

Feedback: 小書きは大きい文字と文字の意味が異なる、即ち異なる音韻を表している。他のプロパティのように大文字と小文字や、全角とプロポーショナルといった、同じ音価を持つ文字同士の変換ではない。よって、ここにあるのは違和感がある。別のプロパティであるべきではないか？（Nat）（木田：とはいえ、ルビで大きい文字を使うのは、まさに同じ音価を持たせた結果では？）

Feedback: full-width は縦書きに便利だが、2桁の数字は縦中横にしたいなど、全角にしたくない場合もあるので、盲目的に全体に適用できるわけでもない。横書きで作られたテキストを、適切に縦書き用にしてくれるプロパティがあるととても便利。

2.2. Expanding Between Words: the ‘word-space-transform’ property

Memo: あらかじめ U+200B ZERO WIDTH SPACE や <wbr> などのマークを入れておくと、それをU+0020や全角空白に置き換えてくれるプロパティ。日本語の分かち書きに使える。auto-phrase があると自動的フレーズを見つけてくれる。例に、語区切りと、文節区切りを区別する方法が載っている。

Discussion: アクセシビリティに良い。すばらしい。

2.3. Order of Operations

3. White Space and Wrapping: the ‘white-space’ property

Memo: 4で定義される’white-space-collapse’, ‘text-wrap-mode’, and ‘white-space-trim’の合わせ技。なぜか独立した章になっている。

4. White Space Processing & Control Characters

Memo: ソースのテキストに余分なスペースや改行が入っている場合がある。それを無視するなどのためのプロパティ。

Question: 日本語の一字下げのスタイルの場合、段落先頭に全角空白を入れるのが慣習だが、これを空行で区切るパラグラフスタイルにしたい場合、この段落先頭の全角空白を無視する必要がある。これはこのプロパティで可能か？

4.1. White Space Collapsing: the ‘white-space-collapse’ property

Memo: 連続する空白文字や改行文字をどのように扱うかを定める。

4.2. White Space Trimming: the ‘white-space-trim’ property

Memo: 指定されたboxの前、後ろ、中身、の空白・改行を無視する指定。

Question: ‘white-space-collapse’とどう違うのかよくわからない。また、同じcollapseという用語が、‘white-space-collapse’では連続する空白を一つの文字にすることを意味し、‘white-space-trim’では無くしてしまうように読める。

4.3. The White Space Processing Rules

Memo: 上記のプロパティーがどのように働くかを説明してある、がなかなかに複雑。

4.3.3. Segment Break Transformation Rules

Feedback: ラインごとに作られた日本語文字の間に空白文字が入ってしまう問題がある。NOTEに”Should we define this for Level 4?”とあるが、Yes, definitely.
2. Then any remaining segment break is either transformed into a space (U+0020) or removed depending on the context before and after the break. The rules for this operation are UA-defined in this level.

Question: 日本語をペーストした時に空白文字が入ってしまう問題は上記に密接に関係するが、CSSの範囲外？

4.4. Tab Character Size: the tab-size property

5. Text Wrapping

5.1. Deciding Whether to Wrap: the text-wrap-mode property

5.2. Controlling Breaks Within Boxes: the wrap-inside property

5.3. Controlling Breaks Between Boxes: the wrap-before/wrap-after properties

5.4. Selecting How to Wrap: the text-wrap-style property

Memo: 賢い行分割を指示するための値が定義されている。balance: 主にタイトルやキャプション用。行ごとに余るアキが、各行で均等になるようにする。pretty: 本文用。速度よりも品質を重視して折り返し位置を見つける。stable: 編集可能テキスト用。編集している最中にテキストが動くことを防ぐため、後続のラインが考慮されないようにする。

Memo: 日本語で考慮すべきことはあるか？

5.5. Joint Wrapping Control: the text-wrap shorthand property

5.6. Line Breaking Details

Memo: CSSには関係ないが、日本語の行の折り返しのルールがUnicodeに適切に反映されている必要がある。

6. Line Breaking and Word Boundaries

Feedback: Are there any reasons why some languages are in the parentheses and some are not?
In others such as Chinese (as well as Japanese, Yi, and sometimes also Korean), 

6.1. Breaking Rules for Letters: the word-break property

Memo: auto-phrase は文節の区切りを発見して区切ってくれる。タイトルやプレゼン、絵本や詩などに有用。

Discussion: webデザイナーが困っている。日本語の場合どこでbreakすべきなのか？ （何を困っているのか、次のミーティングで正確な意味を確認）

Question: Does break-all ignore Kinsoku rules? break-allを指定すると禁則も無視される？”NOTE: This value does not affect whether there are soft wrap opportunities around punctuation characters. To allow breaks anywhere, see line-break: anywhere.”と書いてあるので無視されない？

Discussion: EXAMPLE 19: CSS に関係ないが、日本語でラテン文字列を任意の位置で切る習慣はもはややめるべきではないか？　変なところで折られると読めない。途中で折るならちゃんとハイフネートすべきではないだろうか。全角で非常に長くなってしまう場合は致し方ない？

6.2. Line Breaking Strictness: the line-break property

Memo: 禁則のコントロール。緩い、きつい。Unicodeの定義に従う。auto は行の長さを見る👍

Memo: CSSの将来のバージョンでは、もっと細かい（例えば文字単位で？）コントロールを提供する予定。

6.3. Hyphenation: Morphological Breaking Within Words

6.4. Overflow Wrapping: the overflow-wrap/word-wrap property

質問：これはrubyが折り返せない場合にも適用されるか？

7. Alignment and Justification

7.1. Text Alignment: the ‘text-align’ shorthand

7.2. Character-based Alignment in a Table Column

7.3. Default Text Alignment: the ‘text-align-all’ property

7.4. Last Line Alignment: the ‘text-align-last’ property

7.5. Justification Method: the ‘text-justify’ property

Feedback: ‘ruby’ はどのような用途か？　もしもっぱらボポモフォ用ならそのようにいうべき（meeting）

7.6. Aligning a block of text within its container: the ‘text-group-align’ property

8. Spacing

8.1. Word Spacing: the word-spacing property

Memo: 単語間の空白文字の幅を調節する。全角空白含め固定幅の空白には影響がない。

8.2. Tracking: the letter-spacing property

Memo: いわゆるトラッキング。文字間の空きを調節するが、ジャスティフィケーションが行われる場合はさらに調節が加わる可能性がある。

Feedback: 8.3 says “Whereas letter-spacing adjusts spacing between typographic letter units” whereas the section 8.2 says “This property specifies additional spacing (commonly called tracking) between adjacent typographic character units. ”. Which is correct? （木田）

8.3. Line Start/End Padding: the ‘line-padding’ property

Memo: 行の前と後ろに同量のアキ設定

8.4. Automatic Contextual Spacing: the ‘text-autospace’ property

Memo: 和欧間スペースを実現するもの。‘replace’ が指定してあると、既に空白があってもその空白を無視して規定の和欧間スペースにするという素晴らしい機能付き。もし文字間のアキが指定してある場合は、それに加えた値となる。

Feedback: デフォルトで1/8。このデフォルトの値をコントロールする方法がないが、あるべきではないか。word-space があるのにバランスが取れない（木田）

Feedback: どの文字とどの文字の間を開けるべきかは、現在石井さんとUnicodeに提案しつつある（木田）

Feedback: どの文字とどの文字の間を開けるべきか、または開けないべきかは用途やサイトの方針によっても異なってくる。これを調節するための方法がhighly desirableである（木田）

8.5. CJK Punctuation Spacing: the text-spacing-trim property

Memo: 連続約物のアキの設定。デフォルトはコンパチビリティを重視した’normal’で、これは行頭は詰めず、行末の詰めは収まらない場合のみ。’space-all’は何もしないフォントが持っている幅そのままの状態。’space-first’の下に良い文が書いてある。

Discussion: ここに関して3/25のミーティングで多くの議論があった。

Discussion: trim-auto, autoはChromeでサポートされていない。まだ実装が始まったばかりなので、今後を見てゆく必要がある。Text Level 4 が正式になったら、JLReq TF としてはGap Analysisでカバーする。

Discussion: Windowsに添付の游ゴシックUIに問題あり。haltの値が間違っている。 このフォントは完全にプロポーショナルだが、約物がプロポーショナルな日本語フォントはどのようになるのが理想的か。約物が連続しない場合のために空白があるだろうから、連続した時にはそこをtrimしたいだろう。ただし無条件にグリフの半分を削って良いとの前提をとることはできないので、haltがないと半角 or 半分にできない。

Discussion: 読点と句点を区別したいことがある。

Feedback: auto にガイドラインが必要なのではないか？（村上）

Feedback: ’space-first’ の記述で “on the first line the block container” とあるが、”first line of the” か？

Feedback: 8.5.1 の NOTE での判定方法、全ての漢字が等幅で、仮名だけプロポーショナルなものに対応できそうにない。また、Windowsのプロポーショナル日本語フォントがどうなっているかチェックが必要。

Feedback: 8.5.1 のNOTEの下の”Some fonts have fullwidth punctuation characters whose blank are too small to trim (kern.) “、kern とは？

Todo: 8.5.1-8.5.3 詳細にレビュー必要。

8.6. Character Class Spacing Shorthand: the text-spacing property

Memo: 8.4 ’text-autospace’ と 8.5 ‘text-spacing-trim’ を簡単に設定するためのもの。

8.7. Shaping Across Element Boundaries

Memo: Arabicのような連綿体が分かれ分かれになって良い条件を説明してある。

9. Edge Effects

9.1. First Line Indentation: the ‘text-indent’ property

Feedback: このセクションの問題ではないが、漢字幅（ic）と全角空白幅が異なるデザインを持つフォントの場合、例えば全角一時下がりができない。下はタイププロジェクトからのフィードバック。他にそのようなフォントがあるか未調査。MS P はどうだろう。
木田さま、お世話になっております。以下、弊社エンジニアの回答です。「AXIS Font コンデンスは、日本語組版では仮名がメインだという認識により、全角空白、全角約物を仮名幅としています」。

9.2. Hanging Glyphs

Feedback: 日本語の中に、省略のためのピリオドが行末にぶら下がるのは格好悪い（敏先生）（木田：どのようなるべきか？）

Question: 英語であるような、クオーテーションマークや括弧が前や後ろにはみ出すやり方は日本語にあるか？

Discussion: ルビが横書きの場合で上方にhangする設定は可能か？

9.3. Bidirectionality and Line Boxes

Memo: 右から書く言語の扱いについて。

[MurakamiShinyu]

いくつか補足とコメントします。

2.1. Case Transforms: the ‘text-transform’ property

Memo: text-transform: full-widthは縦書きで英字や数字を全角にするのに使える。text-orientation: upright は似ているが、文字をプロポーショナルのまま upright にする。full-size-kana はルビの小書を大きい文字へ。

Question: UAはOpenTypeのfwidフィーチャーを使うか？それとも文字コードの対応だけか？　ドキュメントからは明確ではないように読めた。

文字コードの対応だけであることは明確です。値 full-width は "Puts all typographic character units in full-width form." であり、その "full-width" の定義は
"The definition of full-width and half-width forms can be found in Unicode Standard Annex #11: East Asian Width. [UAX11] The mapping to full-width form is defined by taking code points with the <wide> or the <narrow> tag in their Decomposition_Mapping in Unicode Standard Annex #44: Unicode Character Database. [UAX44]"
と書かれています。Unicodeのコードポイントの変換であることがわかります。

Feedback: 小書きは大きい文字と文字の意味が異なる、即ち異なる音韻を表している。他のプロパティのように大文字と小文字や、全角とプロポーショナルといった、同じ音価を持つ文字同士の変換ではない。よって、ここにあるのは違和感がある。別のプロパティであるべきではないか？（Nat）（木田：とはいえ、ルビで大きい文字を使うのは、まさに同じ音価を持たせた結果では？）

text-transformプロパティの値 full-size-kana が「別のプロパティであるべきではないか」という意見に私は反対です。
text-transformは、その名前のとおりテキストの文字の変換を指定するものであり、音韻が変わらない変換に制限する理由はないと思います。大文字・小文字と同様に、小書きの仮名文字と普通の仮名文字との間には対応関係があって変換できるのだから、同じtext-transformプロパティで指定するのが適切だと思います。

Feedback: full-width は縦書きに便利だが、2桁の数字は縦中横にしたいなど、全角にしたくない場合もあるので、盲目的に全体に適用できるわけでもない。横書きで作られたテキストを、適切に縦書き用にしてくれるプロパティがあるととても便利。

2桁の数字を縦中横にするのは、CSS Writing Modes Level 4のtext-combine-uprightプロパティに値 digits 2 を指定することで実現できることになっています。

https://drafts.csswg.org/css-writing-modes-4/#text-combine-upright

これと text-transform: full-width を組み合わせることで、2桁の数字を縦中横にして、それ以外の数字や英字を全角文字にすることができます。

例：

p {
  text-transform: full-width;
  text-combine-upright: digits 2;
}

4. White Space Processing & Control Characters

Memo: ソースのテキストに余分なスペースや改行が入っている場合がある。それを無視するなどのためのプロパティ。

Question: 日本語の一字下げのスタイルの場合、段落先頭に全角空白を入れるのが慣習だが、これを空行で区切るパラグラフスタイルにしたい場合、この段落先頭の全角空白を無視する必要がある。これはこのプロパティで可能か？

現仕様では不可能です。
「§4.3. The White Space Processing Rules」に
「Except where specified otherwise, white space processing in CSS affects only the document white space characters: spaces (U+0020), tabs (U+0009), and segment breaks.」
とあります。つまりSPACE (U+0020)、TAB、改行のみが対象で、全角空白は対象外です。

案：

段落字下げの目的で全角空白が入っているのを無視して、段落字下げを text-indent プロパティで制御したいのだから、text-indent プロパティに全角空白を無視する機能（値のキーワード discard-ideographic-space）を追加するとよいかもしれません。
（和欧文間スペースを入れるためのプロパティ text-autospace に元のテキストの和欧文間に入っているスペースを無視する機能（値のキーワード replace）があるのと同様に）

Name:	text-indent
Value:	[ <length-percentage> ] && hanging? && each-line? && discard-ideographic-space?
Initial:	0

例：

p {
  text-indent: 0 discard-ideographic-space;
}

p {
  text-indent: 1em discard-ideographic-space;
}

4.3.3. Segment Break Transformation Rules

Feedback: ラインごとに作られた日本語文字の間に空白文字が入ってしまう問題がある。NOTEに”Should we define this for Level 4?”とあるが、Yes, definitely.
2. Then any remaining segment break is either transformed into a space (U+0020) or removed depending on the context before and after the break. The rules for this operation are UA-defined in this level.

Question: 日本語をペーストした時に空白文字が入ってしまう問題は上記に密接に関係するが、CSSの範囲外？

以前、CSS Text Level 3 でセグメントブレーク変換ルールの議論がありました。

その議論があった当時のCSS Text Level 3の§4.1.3. Segment Break Transformation Rules:
https://www.w3.org/TR/2020/WD-css-text-3-20200429/#line-break-transform

• If the character immediately before or immediately after the segment break is the zero-width space character (U+200B), then the break is removed, leaving behind the zero-width space.
  （セグメントブレークの直前または直後の文字がゼロ幅スペース文字（U+200B）である場合、セグメントブレークは削除され、ゼロ幅スペースが残されます。）
• Otherwise, if both the characters before and after the segment break belong to the space-discarding character set (see Appendix F. Space-Discarding Unicode Characters), then the segment break is removed.
  （それ以外の場合、セグメントブレークの前の文字と後の文字が両方ともスペースを削除する文字セットに属する場合、セグメントブレークは削除されます。）
• Otherwise, the segment break is converted to a space (U+0020).
  （それ以外の場合、セグメントブレークはスペース（U+0020）に変換されます。）

スペースを削除する文字セット（space-discarding character set）は、漢字、仮名、CJKの約物と記号類、Halfwidth and Fullwidth Forms、など。（ほぼCJK文字だが、ハングルは含まない）
→Appendix F. Space-Discarding Unicode Characters

このルールの問題点は、セグメントブレークの前の文字と後の文字が両方ともCJK文字のときだけ削除なので、片方が英数字の場合に余計な空白が入ってしまうことです。

例：

日本語の
テキストに
English
text
を埋め込む。

この場合、

日本語のテキストに English text を埋め込む。

となります。「English text」の前後にスペースが入ってしまうのが気になりますが、このスペースが入るのが制作者の意図通りである可能性もあるので、このケースではこのルールでよいだろうと思います。
（この「English text」の前後に入った余計なスペースは、text-autospaceプロパティの値 replace によって自動の和欧文間スペースに置き換えることができます）

しかし、CJKの約物の前後で改行しているケースでは、このスペースが入るのが適切でない可能性が高いです：

日本語のテキストに、
English textを埋め込む。

日本語のテキストにEnglish text
（英語のテキスト）
を埋め込む。

次のようになります：

日本語のテキストに、 English textを埋め込む。

日本語のテキストにEnglish text （英語のテキスト） を埋め込む。

句読点や全角括弧と英字との間にスペースが入るのは、ほとんどの場合、制作者の意図通りではないと思います。

（この余計なスペースはtext-autospaceプロパティの値 replace によっても除去されません。和欧文間スペースが入る位置ではないからです）

そこで私は、CJK約物と隣接するセグメントブレークは削除するようにルールを修正する提案をしました：

[css-text-3] Segment Break Transformation Rules around CJK Punctuation
w3c/csswg-drafts#5086

この提案は、元のルールの "Otherwise, the segment break is converted to a space"（それ以外の場合、セグメントブレークはスペースに変換されます）の前に、次のルールを追加するというものです：

• Otherwise, if either the character before or after the segment break belongs to the space-discarding character set and is a Unicode Punctuation (P*) or Space Separator (Zs), then the segment break is removed.
  （それ以外の場合、セグメントブレークの前または後の文字がスペースを削除する文字セットに属し、Unicodeの句読点（P*）またはスペースセパレータ（Zs）である場合、セグメントブレークは削除されます。）

2020年10月にCSSWGで議論された結果、Level 3 では未定義として、Level 4で取り組もうということになりました。しかしそのあと議論が進んでないので、Level 4でもまだ未定義のままです。

7.5. Justification Method: the ‘text-justify’ property

Feedback: ‘ruby’ はどのような用途か？　もしもっぱらボポモフォ用ならそのようにいうべき（meeting）

text-justify: ruby の定義は：

• Justification opportunities are disabled at word separators.
  （単語の区切りでのジャスティフィケーション機会は無効になります。）
• Justification opportunities are disabled between Bopomofo characters
  （注音符号文字間のジャスティフィケーション機会は無効になります。）

これはルビ文字列（rt要素）にデフォルトで適用されることが想定されています：

rt {
  text-justify: ruby;
}

ルビの親文字列が長くてルビ文字列が英語であるような場合、ルビ文字列の英単語間は伸ばさないようにするということのようです。

[kidayasuo]

12日のミーティング、および上の村上さんのコメントをベースに、今日fantasaiと議論すべきことをまとめました。インプットがあればぜひください。

2.1. Case Transforms: the ‘text-transform’ property

Future: これは将来の版に向けての希望：full-width は縦書きに便利だが盲目的に全体に適用できるわけではない。横書きで作られたテキストを、適切に縦書き用にしてくれるプロパティがあるととても便利。村上さんの例のようにルールによってはCSSで組み立てられる。JLReq TF 側でルールを明確化することがまず重要。

p {
  'text-transform: full-width';
  text-combine-upright: digits 2;
}

4. White Space Processing & Control Characters

Feedback: 段落先頭の全角空白を無視できる手段が必要：日本語の一字下げのスタイルの場合、段落先頭に全角空白を入れるのが慣習だが、これを空行で区切るパラグラフスタイルにしたい場合、この段落先頭の全角空白を無視する必要がある。それを可能にするプロパティが必要。二つ方法がある。一つはここ、もう一つは下の村上さんの案、text-indent。

村上さんの案：段落字下げの目的で全角空白が入っているのを無視して、段落字下げを text-indent プロパティで制御したいのだから、text-indent プロパティに全角空白を無視する機能（値のキーワード discard-ideographic-space）を追加するとよいかもしれません。
（和欧文間スペースを入れるためのプロパティ text-autospace に元のテキストの和欧文間に入っているスペースを無視する機能（値のキーワード replace）があるのと同様に）

4.2. White Space Trimming: the ‘white-space-trim’ property

Memo: 指定されたboxの前、後ろ、中身、の空白・改行を無視する指定。

Question: これは単に村上さんに伺えば良いか？：‘white-space-trim’と‘white-space-collapse’とどう違うのかよくわからない。また、同じcollapseという用語が、‘white-space-collapse’では連続する空白を一つの文字にすることを意味し、‘white-space-trim’では無くしてしまうように読める。

4.3.3. Segment Break Transformation Rules

Feedback: line-break-transform において、segment break を空白にせず削除するためのガイドラインがぜひ必要。ラインごとに作られた日本語文字の間に空白文字が入ってしまう問題。ISSUE 4に”Should we define this for Level 4?”とあるが、Yes, definitely please. この手の問題にガイドラインを作らないと知識のギャップから、現実的には英語だけで正しく動く実装になる。
2. Then any remaining segment break is either transformed into a space (U+0020) or removed depending on the context before and after the break. The rules for this operation are UA-defined in this level.
ISSUE 4 Should we define this for Level 4?

Question: 日本語をペーストした時に空白文字が入ってしまう問題は上記に密接に関係するが、CSSの範囲外？

5.4. Selecting How to Wrap: the text-wrap-style property

Feedback: 日本語の場合文節を気にしてほしい。CSSは方法は規定していないので、方法は実装者依存だが、上記と同様、そのようなアプローチの場合、英語だけで動き、日本語でうまくゆかない場合が多い。

6. Line Breaking and Word Boundaries

Feedback: Are there any reasons why some languages are in the parentheses and some are not?
In others such as Chinese (as well as Japanese, Yi, and sometimes also Korean), 

7.5. Justification Method: the ‘text-justify’ property

Internal notes: Discussion: justificationで圧縮を行う際は読点と句点を区別したい。行末での区別は4051にはあるけれど、それは不要。

8.2. Tracking: the letter-spacing property

Typo?: 8.3 says “Whereas letter-spacing adjusts spacing between typographic letter units” whereas the section 8.2 says “This property specifies additional spacing (commonly called tracking) between adjacent typographic character units. ”.

8.4. Automatic Contextual Spacing: the ‘text-autospace’ property

Feedback: デフォルトで1/8の値をコントロールする方法がないが、word-spaceのようにあるべきではないか。

Feedback: どの文字とどの文字の間を開けるべきかは、現在石井さんとUnicodeに提案しつつある。どの文字とどの文字の間を開けるべきか、または開けないべきかは用途やサイトの方針によっても異なってくる。これを調節するための方法がhighly desirableである（木田）

8.5. CJK Punctuation Spacing: the text-spacing-trim property

Typo?: ’space-first’ の記述で “on the first line the block container” とあるが、”first line of the” か？

Feedback: 8.5.1 の NOTE での判定方法、漢字だけ調べては全ての漢字が等幅で、仮名だけプロポーショナル、もしくは漢字と仮名の幅の異なるものに対応できない。

8.7. Shaping Across Element Boundaries

Feedback: 記述が不明確（山口）これはよくわからなかったので山口さんに説明していただく。

9.1. First Line Indentation: the ‘text-indent’ property

Feedback: このセクションの問題ではないが、漢字幅（ic）と全角空白幅が異なるデザインを持つフォントの場合、例えば全角一時下がりができない。下はタイププロジェクトからのフィードバック。

木田さま、お世話になっております。以下、弊社エンジニアの回答です。「AXIS Font コンデンスは、日本語組版では仮名がメインだという認識により、全角空白、全角約物を仮名幅としています」。`

「AXIS Font コンデンスでは、ご指摘のとおり、全角空白、全角約物が仮名幅となっています。すなわち、仮名を基準とした組版システムを採用していると理解していただいてよいかと思います。言い換えれば、仮名と約物だけからなる文章が、AXIS Font コンデンスの組版の基準となります。

通常の仮名・漢字が正方形ボディの場合のベタ組みにおいても、プロポーショナル欧文という例外的な要素が介在してくるのと同様、AXIS Font コンデンスでは、仮名幅を基準とした組版システムに、漢字およびプロポーショナル欧文という例外的な要素が関わってくると考えるのがシンプルかと思います。

実際、こうして文章を書いているときの意識としても、仮名をメインとする流れのなかに、適宜漢字が挿入されると感じるのが自然ではないでしょうか。

以上に基づき、AXIS Font コンデンスにおける全角一字下がりの分量は、全角空白の幅（760/1000）としていただくのが適切かと思います。」

9.2. Hanging Glyphs

Feedback: 日本語の中に、省略のためのピリオドが行末にぶら下がるのは格好悪い（敏先生）カッコ悪いので区別したい。そもそも、日本語のぶら下がりは欧文のhangingと用途が異なるので、ここに一緒に入れるのは無理があるのではないか。

Feedback: このセクションとは別だが、ルビが横書きの場合で上方にhangする設定は可能か？

[yamahige]

山口です:
1.5. Text Processing &
8.7. Shaping Across Element Boundaries
"1.5. Text Processing" states that inline-box boundaries must be ignored except in shaping. But there seem to be exceptions in cases other than shaping, too. In some cases, non-zero margin preserves inline-box boundaries, for example, "8.4.1. Inter-script Spacing."

[kidayasuo]

meeting notes 4-17 w/fantasai (J)

fantasaiの来日に合わせたCSS Text Level 4レビューの最後のミーティング。アクションを決めた。

2.1. Case Transforms: the ‘text-transform’ property

縦書きの出版物や電子書籍を制作する際、横書きで作られた原稿に対し、縦書きに適したフォーマットを得るためにテキストの書き換えを行うことが一般的に行われている。このような書き換えは、これにかかるコスト、および内容とスタイルの分離の原則から考えて好ましいことではない。横書きテキストを縦書きでフォーマットするためのプロパティを作れないか。これはLevel 4ではなく、将来の版への要望である。

fantasaiによると、CSSがテキストのコンテキストを見ることは、単純なものなら不可能ではないが、問題点が多くあるとのこと。コンテキスト依存部分があるなら例えばjavascriptやpythonなどのスクリプトに依存するのも良いアイディアであろうとのこと。

まずはJLReq TFにおいて、横書き→縦書きの際にどのような変換が必要であるかの文書をまとめることになった。

アクション

JLReq TFにおいて、横書き→縦書きの際にどのような変換が必要であるかの文書をまとめる。また（可能なら）その変換を実行するスクリプトを作ってみる。 jlreq/#422

4. White Space Processing & Control Characters

日本語の段落先頭一字下がりのスタイルは通常テキストの段落先頭に全角空白文字を入れることで達成されている。このように作られたテキストの段落スタイルを変更しようとする場合、この段落先頭の全角空白文字を無視する必要がある。それを可能にするプロパティが必要。

fantasaiとともに4. White Space Processing を使う方法含めいくつかの案を検討した結果、村上さん提案の「text-indentプロパティに全角空白を無視する機能をつける」とうい案が良いという結論となった。これはtext-autospaceに、元のテキストの和欧文間に入っているスペースを無視する機能replaceがあるのと似ている。

アクション

村上さんが、csswg-draftsにこの提案のissueを作る。 jlreq/#423

4.3.3. Segment Break Transformation Rules

英語のテキストを適当な長さに区切って入力すると、segment breaksは適切に扱われ、典型的な場合には単語間区切りの空白として扱われる。日本語のテキストを同様に適当な長さに区切って入力すると、segment breaksが空白文字になり、文字の間に不要な空白が入り、フォーマットや検索を壊してしまう。Text Level 4 のline-break-transformの記述に、”segment break is either transformed into a space (U+0020) or removed depending on the context”とあり、segment breaksを空白にせずに取り除くことが可能になっている。しかしこの実装には高度な言語の知識と、判断の難しいケースについて議論のできる環境が必要であり、実際には困難である。CSSがガイドラインを示すことを強く求める。

fantasai / 村上さんによると、ルールはCSS3においても議論があったが、合意の困難さから先送りになったとのこと。判断の分かれる場合の例は、segment breakを挟んだ片側が漢字や仮名、片側がラテンの場合（mixed case）である。議論の後、次のようなルールが良いのではないかということになった：

• 全角文字がCJK約物である場合：discard
• もし言語が日本語などになっている場合：discard
• それ以外：keep

また、Firefoxでは空白を取り除くルールを長年実装しているので、これをベースラインとして考えられるだろうとのこと。

text-autospace同様、完璧なルールは存在し得ないので、完璧を目指すのではなく、多くの人がある程度納得できるベースラインを目指すべきであろうということになった。

アクション

Level 3で議論されたルール、およびFirefoxのルールを調べ、木田が村上さんと共にcsswg-draftsに提案のissueを作る。 jlreq/#424

5.4. Selecting How to Wrap: the text-wrap-style property

balance の場合に日本語の場合文節を気にしたアルゴリズムが望ましい。議論を行ったが特に結論は出なかった。word-break: auto-phraseを使うことによって、文節を区切りとすることは可能だが、行の折り返しが文節でのみで可能な場合、行の長さのバランスが大きく崩れる場合がある。よって行の折り返しの優先度の概念が必要となる。

アクション

特にアクションは定まらなかった。

8.2. Tracking: the letter-spacing property

Typo?: 8.3 says “Whereas letter-spacing adjusts spacing between typographic letter units” whereas the section 8.2 says “This property specifies additional spacing (commonly called tracking) between adjacent typographic character units. ”.

アクション

typographic character units が正しい。fantasaiが手元で修正を行なった。

8.4. Automatic Contextual Spacing: the ‘text-autospace’ property

Customizing the default value

デフォルトとして提案されている1/8の値は良いが、その量をコントロールする方法が必要ではないか。議論の結果、1/8の値でまずリリースを行い、それを変更したいというリクエストが出てくるかどうかを待とうということになった。

アクション

特になし

Customizing the behavior

どの文字とどの文字の間を開けるべきか、または開けないべきかはフォント、用途やサイトの方針によっても異なってくる。これを調節するための方法のあるのが望ましい。

アクション

木田が必要となる例と共にcsswg-draftsに提案のissueを作る。jlreq/#425

8.5. CJK Punctuation Spacing: the text-spacing-trim property

Typo?: ’space-first’ の記述で “on the first line the block container” とあるが、”first line of the” か？

アクション

fantasaiが手元で修正した。済み。

9.1. First Line Indentation: the ‘text-indent’ property

日本語の段落先頭一字下がりのスタイルは通常テキストの段落先頭に全角空白文字を入れることで達成されている。これを文字を挿入することなしに’text-indent’で達成するためには、そのフォントの全角空白文字の幅をもつ単位の定義が必要である。現在漢字の幅を表すicという単位が定義されているが、漢字の幅と全角空白文字の幅が異なるフォントも珍しくない。一つの例はWindowsでデフォルトのMS P ゴシック、もう一つの例はAXIS Condensed / Compressed。後者は漢字、仮名、それぞれ等幅であるが、仮名の幅は漢字よりも狭く設定されており、また全角空白文字と約物は仮名と同じ幅を持つ。

下はタイププロジェクトからのフィードバック。

「AXIS Font コンデンスでは、ご指摘のとおり、全角空白、全角約物が仮名幅となっています。すなわち、仮名を基準とした組版システムを採用していると理解していただいてよいかと思います。言い換えれば、仮名と約物だけからなる文章が、AXIS Font コンデンスの組版の基準となります。
通常の仮名・漢字が正方形ボディの場合のベタ組みにおいても、プロポーショナル欧文という例外的な要素が介在してくるのと同様、AXIS Font コンデンスでは、仮名幅を基準とした組版システムに、漢字およびプロポーショナル欧文という例外的な要素が関わってくると考えるのがシンプルかと思います。
実際、こうして文章を書いているときの意識としても、仮名をメインとする流れのなかに、適宜漢字が挿入されると感じるのが自然ではないでしょうか。
以上に基づき、AXIS Font コンデンスにおける全角一字下がりの分量は、全角空白の幅（760/1000）としていただくのが適切かと思います。」

議論の結果、全角空白文字の幅を持つ単位の定義が必要だろうということになった。

アクション

木田がcsswg-draftsに提案のissueを作る。jlreq/#426

9.2. Hanging Glyphs

日本語のぶら下がり組みにおいて、欧文のピリオドなどが行末にぶら下がることはなく、日本語の句読点と、ぶら下がるべきではない欧文の句読点を区別する必要がある。

日本語のぶら下がり組と、欧文のハンギングとは用途が異なる。日本語のぶら下がり組は句読点を行内に収めることで行の調整を避けるのが目的である。句読点は行頭禁則文字であるので、句読点の前の文字と共に次の行に送る必要があり、元の行に行の調整が必要になる。日本語組版において、行の調整はグリッドを乱すため、また作業効率上できるだけ避けたい。そのためにぶら下がりを許容する。対して欧文組版のハンギングは、句読点の作る空白を避け視覚的にエッジを揃えるために行われる。

fantasaiからは、欧文のハンギングの視覚的な効果の達成は、現代の技術を用いることで、句読点の文字単位のハンギングよりも高度に達成できるため、このプロパティが正しいのか疑問であるとの議論があった。

アクション

木田がcsswg-draftsに提案のissueを作る。jlreq/#427

[kidayasuo]

Meeting Notes 4-17 with Fantasai (E)

(translation to English by chatGPT + some manual adjustments)

This was the final meeting for the CSS Text Level 4 review, coinciding with Fantasai's visit to Japan. Decisions on actions were made.

2.1. Case Transforms: the ‘text-transform’ property

When producing publications or e-books, it is common to rewrite texts made for horizontal writing to suit vertical formats. This kind of rewriting, considering its cost and the principle of separating content and presentation, is undesirable. Discussion was held about creating a property that could format horizontal texts for vertical presentation. This request is for a future version, not for Level 4.

According to Fantasai, while CSS can handle simple text contexts, doing so involves complications. If it involves many context-dependent adjustments, it might be good to rely on scripts such as JavaScript or Python.

It was decided that the JLReq TF should first compile a document detailing the necessary conversions when changing horizontal text to vertical.

Actions

The JLReq TF will compile a document detailing the necessary transformations from horizontal to vertical text. If possible, a script will be created to perform these transformations. jlreq/#422

4. White Space Processing & Control Characters

In Japanese text, the style of indenting the first character of a paragraph is usually achieved by inserting a full-width space. To change this paragraph style, it's necessary to ignore this full-width space character at the start. A property that enables this is required.

After reviewing several approaches with Fantasai, Mr. Murakami's proposal to add a function to the 'text-indent' property that ignores full-width spaces was deemed good. This is similar to the 'replace' function in text-autospace that ignores spaces between Japanese and Western text.

Actions

Mr. Murakami will create an issue on csswg-drafts regarding this proposal. jlreq/#423

4.3.3. Segment Break Transformation Rules

When English text is appropriately segmented, segment breaks are managed properly, typically treated as spaces between words. However, when Japanese text is segmented in the same way, segment breaks become spaces, inserting unwanted spaces between characters, which disrupt formatting and searchability. Text Level 4's description of 'line-break-transform' allows for the removal of segment breaks without turning them into spaces, depending on the context. However, implementing this requires advanced linguistic knowledge and a conducive environment for discussing complex cases, making practical implementation difficult. A strong call was made for CSS to provide guidelines.

Fantasai and Mr. Murakami mentioned that there were discussions about these rules in CSS3, but they were deferred due to difficulty in reaching consensus. A case for debate is when one side of a segment break is Kanji or Kana and the other side is Latin (mixed case). It was suggested that the following rules might be appropriate:

• If the full-width character is CJK punctuation: discard.
• If the language is set to Japanese, etc.: discard.
• Otherwise: keep.

As Firefox has been implementing a rule to remove such spaces for many years, this could be considered a baseline.

Like with text-autospace, a perfect rule is unattainable; rather, a baseline that most people can reasonably accept should be aimed for.

Actions

Research rules discussed in Level 3 and Firefox's rules, and Mr. Kida, along with Mr. Murakami, will create an issue on csswg-drafts to propose this. jlreq/#424

5.4. Selecting How to Wrap: the text-wrap-style property

For 'balance', an algorithm that considers Japanese phrases is desirable. Discussions were held but no conclusion was reached. Using 'word-break: auto-phrase' allows for wrapping at phrases, but if wrapping is only possible at phrases, it can significantly disrupt the balance of line lengths. Thus, a concept of prioritizing line breaks is needed.

Actions

No specific actions were decided.

8.2. Tracking: the letter-spacing property

Typo?: Section 8.3 says “Whereas letter-spacing adjusts spacing between typographic letter units,” whereas section 8.2 says “This property specifies additional spacing (commonly called tracking) between adjacent typographic character units.”

Actions

The correct term is typographic character units. Fantasai made the correction on site

.

8.4. Automatic Contextual Spacing: the ‘text-autospace’ property

Customizing the default value

The proposed default value of 1/8 is good, but a method to control this amount might be necessary. It was decided to first release with the 1/8 value and wait to see if requests for changes emerge.

Actions

None specific.

Customizing the behavior

How to space or not space between certain characters may differ based on the font, usage, and site policy. A method to adjust this would be desirable.

Actions

Mr. Kida will create an issue on csswg-drafts with necessary examples. jlreq/#425

8.5. CJK Punctuation Spacing: the text-spacing-trim property

Typo?: The description for 'space-first' says “on the first line the block container,” but should it be “first line of the”?

Actions

Fantasai corrected it on site. Completed.

9.1. First Line Indentation: the ‘text-indent’ property

In Japanese text, the style of indenting the first character of a paragraph is typically achieved by inserting a full-width space. To achieve this indentation using the 'text-indent' property without inserting characters, it is necessary to define a unit that accounts for the width of the full-width space character of the font. Although the ic unit, which represents the width of Kanji, is currently defined, it is not uncommon for the widths of Kanji and full-width space characters to differ in fonts. One example is the default MS P Gothic on Windows, and another is AXIS Condensed / Compressed. In the latter, Kanji and Kana are monospaced, yet Kana is set narrower than Kanji, and both full-width spaces and punctuation have the same width as Kana.

Below is feedback from the Type Project:

"In AXIS Font Condensed, as you mentioned, full-width spaces and punctuation are based on the Kana width. Therefore, it is understood that a typesetting system based on Kana is being used. In other words, a text composed solely of Kana and punctuation would serve as the typesetting standard for AXIS Font Condensed.
Just as proportional Western text intervenes as an exceptional element in the normal setting of square-bodied Kana and Kanji, in AXIS Font Condensed, it is simpler to think of the typesetting system as being based on Kana width, involving Kanji and proportional Western text.
In fact, when writing texts like this, it feels natural to intermittently insert Kanji into a flow primarily composed of Kana.
Based on this, the appropriate amount of first-line indentation in AXIS Font Condensed would be the width of a full-width space (760/1000)."

As a result of the discussion, it was concluded that a definition of a unit representing the width of a full-width space character is needed.

Actions

Mr. Kida will create an issue on csswg-drafts. jlreq/#426

9.2. Hanging Glyphs

In Japanese typesetting of hanging punctuation, Western periods and other punctuation do not hang at the end of lines. Japanese punctuation must be differentiated from Western punctuation.

The purpose of Japanese hanging punctuation is to keep punctuation marks within the line to avoid adjusting the line, as punctuation marks are line-start prohibited characters and need to move to the next line along with the preceding character if they cannot fit at the line end. In Japanese typesetting, adjusting lines disrupts the grid, and for efficiency, it is preferable to avoid this, hence the allowance for hanging. In contrast, hanging in Western typesetting is performed to avoid the visual gaps created by punctuation marks and align edges visually.

Fantasai raised concerns whether this property is appropriate, suggesting that with modern technology, the visual effects of hanging at the character level of punctuation can be achieved more effectively than with traditional methods.

Actions

Mr. Kida will create an issue on csswg-drafts proposing this feature. jlreq/#427