和欧混植文における英単語前後のスペースの是非とtext-autospaceプロパティの行方

はじめに

こんにちは。@debiruです。私は2000年頃からHTMLを研究していて、HTML仕様やWebページ、HTMLリソースの在り方について考察しています。MDNやAstroの日本語翻訳コントリビューターもしています。

この記事は[css-text] Reconsider the initial value of the text-autospace property #12386において、CSS仕様としてtext-autospaceプロパティの初期値をnormalにすべきかno-autospaceにすべきかの議論が起こっていることに対して、私の意見の根拠を示すためのものです。

概要

何の話かというと、

• 英単語前後に半角スペースあり
  • 「HTML 仕様や Web ページ、HTML リソースの在り方について考察しています」
• 英単語前後に半角スペースなし
  • 「HTML仕様やWebページ、HTMLリソースの在り方について考察しています」

のように、和文と欧文（日本語と英語）が混在するような文章で、欧文（英数字）の前後に半角スペース文字（ASCIIスペース）を入れるか入れないか、といった話です。

このASCIIスペースの挿入がなぜ行われているのか、そしてtext-autospaceプロパティの初期値は何が望ましいのかについて、歴史的経緯も踏まえて私の見解をまとめます。

用語について

「スペース」は多義語である

スペースという単語は一般的には何らかの「空間」を意味します。

情報技術分野においては、第一の意味として、文字としての「全角スペース（和字間隔, FWSP）」または「全角以外のスペース（HWSP, NBSP, ZWSP 等）」を指します。第二の意味として、余白としての「空間」「字間（間隔）」を指します。

単に「スペース」と言うと何のことだか分からないので、総称以外の文脈では次のように呼ぶことにします。

• 純粋な半角スペース（ASCIIコード 0x20）は「ASCIIスペース」
• 余白としての文字間隔は「字間」

和文と欧文とCJK文字

CJKは "Chinese, Japanese and Korean" の略です。中国語・日本語・韓国語では、アルファベットの他に「漢字」「平仮名」「片仮名」「ハングル」「全角記号類」が使われます。情報技術分野においては、半角記号やアルファベット以外の文字は扱いが難しいため、それらは総称してCJK文字と呼ばれています。

この文書の文脈では、CJK文字は和欧混植文における「和文」を指します。

一方「欧文」は、半角記号やアルファベット、言い換えると「半角英数字」を指します。

ASCIIスペースがなくても欧文前後の字間を自動調整する仕組み

Microsoft Wordでは「日本語と英数字の間隔を自動調整する」といった設定項目があり、これが有効になっていると文章上でASCIIスペースを挿入していなくても、英数字前後に余白が生じるようになります。ちなみに、この機能はGoogle Docsにはありません。

HTML, CSSの世界では、2000年頃にInternet Explorer 6がtext-autospaceプロパティを独自実装していました。このプロパティを設定するとMicrosoft Wordと同様に英数字前後に余白が生じるようになります。

• 1999年時点のtext-autospace仕様
  • https://www.w3.org/TR/1999/WD-i18n-format-19990127/#a6-7

IE以外のブラウザはtext-autospaceプロパティを実装していませんでしたが、このプロパティはCSS仕様に取り入れられており、2025年になってようやくモダンブラウザが実装し始めました。

和欧混植文で欧文前後にASCIIスペースを挿入する理由

いくつかの異なる理由が考えられます。

第一の理由：字間の確保

第一の理由は、読みやすさの確保のために「字間」を設けるというものです。

2000年頃にIEがtext-autospaceを独自実装していましたが、他のモダンブラウザでは一切このプロパティは実装されていませんでした。

CSS仕様には当時からこのプロパティは掲載されていましたが、text-autospaceとtext-trimをtext-spacingプロパティとして統合することが検討され、CSS Text Module Level 3に記述されていたそのプロパティは2012年にCSS Text Level 4へ移されました。

• [css3-text] text-spacing プロパティ (text-trim + text-autospace)
  • https://lists.w3.org/Archives/Public/public-html-ig-jp/2011Apr/0028.html

各種ブラウザが実装していなかったので、欧文前後に和文が続く場合、何もしないと文字がくっついて読みづらいという問題があったのです。

• 英単語前後に半角スペースあり
  • 「HTML 仕様や Web ページ、HTML リソースの在り方について考察しています」
• 英単語前後に半角スペースなし
  • 「HTML仕様やWebページ、HTMLリソースの在り方について考察しています」

上記のどちらが視覚的に読みやすいか、という話です。

第二の理由：コンテキストの分離

第二の理由は、異なる文脈のテキストを分離するためです。

• 日本文の中に英文がある場合（英文の前後にASCIIスペースを入れるかどうか）
  • 「彼はIt's OKと答えました」
  • 「彼は"It's OK"と答えました」
  • 「彼は It's OK と答えました」
  • 「彼は "It's OK" と答えました」
• 日本文の中にURLがある場合（URLの前後にASCIIスペースを入れるかどうか）
  • 「詳細はhttps://example.comをご覧ください」
  • 「詳細は https://example.com をご覧ください」

和欧混植文におけるスペース挿入の是非を議論するには、「和文と欧文の間にスペースを入れるべきか」というスコープではなく、「どういうケースではどういう理由でスペースを入れるべきか」というコンテキストに応じた議論が必要です。

極論「スペースを入れたほうが都合が良ければ入れるべきで、そうでなければ入れるべきではない」という答えになるはずです。その結論ではなく、それは何故かを理解することが重要です。

第三の理由：ライティングガイドラインの存在

第三の理由は、何らかの経緯で制定されたガイドラインが存在するためです。

個人で文章を書く上では、個人の判断でこの問題を扱うことができます。しかし、複数人で開発しているようなプロダクトにおいては、個人の判断に頼っていては品質の一貫性が確保できません。

そこで、通常そのようなプロダクトを開発するプロジェクトではガイドラインを用意します。

MDNでは4つほどのガイドライン文書が存在しますが、その中の表記ガイドラインでは、

• 見やすさのため、日本語と英数字の間には半角スペースを挿入する。
  • (Microsoft のドキュメントも同じルールを採用している)

と明記されています。

このルールを採用した経緯は私は知りませんが、個人的にはこのルールは強すぎると思っています。ある例外を除いて、常に「英数字前後」にはASCIIスペースを挿入するべき、と言っているのです。ある例外とは「句読点、カギ括弧などの日本語《約物》と英数字が隣接する場合は半角スペースを挿入しない」というものです。

このルールが強すぎると感じるMDNの文章例として次のようなものがあります。

4 つのボタンの 1 つが押されているかどうかがチェックされます

2008 年 12 月 11 日に WCAG 1.0 の次となる WCAG 2.0 が W3C から勧告されました

数字の前後に常にASCIIスペースが付けられています。これはやりすぎでしょう。分離すべきでないコンテキスト中のテキストが機械的にASCIIスペースで分離されてしまっています。これは例えば「2008年」というフレーズで文字列検索したときに、上記の後者の文章がヒットしないことを意味します。

第四の理由：機械によって生成される場合

第四の理由は、その文章を生成するのが人ではなく機械である場合があるためです。

最終的に生成される（HTML）文章を人が書いているとは限りません。元となる文章は人が書いても、それを機械的に解析・生成することはしばしばあります。

具体的には、Markdownテキストを書いている場合や、Prettierと呼ばれるような整形ツールを用いている場合です。

この場合、Markdown解析器やPrettierの実装で欧文前後にASCIIスペースを挿入する機構があった場合、結果的に生成される文章にはASCIIスペースが挿入されます。

実際、有名な実装としてのPrettierは、2系まではASCIIスペースを挿入する実装になっていましたが、2023年7月にリリースされた3系ではASCIIスペースを挿入しないように仕様が変更されました。

この経緯についてはAstroの日本語翻訳ガイドラインに記載されています（私が書きました）。

段落の字下げを考える

以下ではInline-Literal, Hook-Element, Extra-Semantic-Markupというアプローチを紹介しますが、これらは私が考えた造語です。他の文献では使われていない用語なので注意してください。

Inline-Literalアプローチ

Inline-Literalアプローチは、字下げやリストマーカーなどの装飾情報を本文中の文字そのもので表現する方法です。

字下げやリストマーカーに限らず、例えば改行位置を指定するためにHTML中に改行文字を挿入して、CSSでそのテキストの親要素をwhite-space: preにすることでテキスト中の改行を実現するのもInline-Literalアプローチに含まれます。

ただし、後述するHook-ElementやExtra-Semantic-Markupアプローチを用いた上で擬似要素（::marker, ::before, ::after）を用いて、content: "・"のように結果的に字下げやリストマーカーを文字で表現する方法はInline-Literalアプローチとは区別されます。あくまで本文中（HTML）に文字を埋め込むアプローチのことを指します。

<p>ごめんごめん、お待たせ。悪いね急に呼び出して。あ、髪型変えた？変えてない？だと思った。</p>
<p>　でっさ、どう？ぶっちゃけ、理解した？条件付き確率。五分五分？いいじゃんいいじゃん！</p>
<p>　でっさ、ちょっと聞いてほしいんだけど、ここに3つコーラがあります。このうち1つだけ炭酸入ってない。事前に抜いておいた。ぶっちゃけどれだと思う？これ？なるほど？じゃあ実際、ここに炭酸が入ってない確率ってどんぐらいだと思う？3分の1？いいじゃん、パーフェクト！</p>
<p>　でっさ、こんなことをやってみよう。いま、ここに炭酸が入っていることが分かったわけなんだけど、どう？変えてみたい？選択肢。いま、こことここに炭酸が入っている確率、五分五分じゃないって言ったら、信じる？ちょっと待ってちょっと待って、めっちゃ疑ってんじゃん。絶対騙されませんよって顔。ここにあった炭酸が入っていない3分の1の確率が、全部このペットボトルに移ったんだ！</p>
<p>ほらな、えっ？喋り方が胡散臭い？こらっ。コーラだけに。</p>

このようなHTMLを書いてはいけない理由は何だったでしょうか。

• HTML文書は構造とスタイルの分離をするという原則があり、その思想に反しているから
• 文章テキストをコピーすると全角スペースまでコピーされてしまい、利用者の意図に反するから
• 字下げを「全角スペース1個分」から変更したいときに、文字列全置換をする以外の方法で変更できないから
• そもそもプロポーショナルフォントの場合は「全角スペース」で確保される文字幅が不定だから
• 字下げとしての全角スペースを入れ忘れているのか、意図的にその段落だけ例外的に字下げをしていないのか区別できないから

こういった理由が挙げられるでしょうか。

では、次の方法はどうでしょうか。

Hook-Elementアプローチ

Hook-Elementアプローチは、字下げやリストマーカーを表したい箇所にトリガーとして機能するダミー要素（フック要素）を記述して、そのフック要素の振る舞いを指定することで表現を実現する方法です。

ハンバーガーメニューと呼ばれる表現を実現するために、次のようなマークアップを行うパターンがこれに該当します。

<button type="button" class="menu-button" aria-label="メニューを開く">
  <span class="hamburger-line"></span>
  <span class="hamburger-line"></span>
  <span class="hamburger-line"></span>
</button>

また、改行や折り返し制御については<br>や<wbr>要素を使う場合がこの方法に該当します。

<style>
  .hook-indent { display: inline-block; width: 1em; }
</style>
<p>ごめんごめん、お待たせ。悪いね急に呼び出して。あ、髪型変えた？変えてない？だと思った。</p>
<p><span class="hook-indent"></span>でっさ、どう？ぶっちゃけ、理解した？条件付き確率。五分五分？いいじゃんいいじゃん！</p>
<p><span class="hook-indent"></span>でっさ、ちょっと聞いてほしいんだけど、ここに3つコーラがあります。このうち1つだけ炭酸入ってない。事前に抜いておいた。ぶっちゃけどれだと思う？これ？なるほど？じゃあ実際、ここに炭酸が入ってない確率ってどんぐらいだと思う？3分の1？いいじゃん、パーフェクト！</p>
<p><span class="hook-indent"></span>でっさ、こんなことをやってみよう。いま、ここに炭酸が入っていることが分かったわけなんだけど、どう？変えてみたい？選択肢。いま、こことここに炭酸が入っている確率、五分五分じゃないって言ったら、信じる？ちょっと待ってちょっと待って、めっちゃ疑ってんじゃん。絶対騙されませんよって顔。ここにあった炭酸が入っていない3分の1の確率が、全部このペットボトルに移ったんだ！</p>
<p>ほらな、えっ？喋り方が胡散臭い？こらっ。コーラだけに。</p>

字下げ（インデント）がその段落に存在することを、<span class="hook-indent"></span>という要素タグの有無で表現しています。実際、字下げのためにこのようなアプローチを採ることは少ないと思いますが、HTML的に親要素（p要素）が触れない場合には選択肢として有効な方法かもしれません。

みなさんが字下げの実現方法として思いつくのは次の方法でしょう。

Extra-Semantic-Markupアプローチ

Extra-Semantic-Markupアプローチは、HTML 中にフック要素（Hook-Element）や文字（Inline-Literal）を置くことなく、本来行いたい装飾を実現する方法です。

ハンバーガーメニューの例では、次のようなマークアップになります。

<button type="button" class="menu-button">
  <span class="hamburger-outer">
    <span class="hamburger-wrapper">
      <span class="hamburger-inner">
        メニューを開く
      </span>
    </span>
  </span>
</button>

上記の例は、もともとhamburger-lineを3個用意していたものをそのまま書き直したので<span>を3重にしていますが、使える疑似要素の数を考えれば<span>の数を減らすことができるかもしれません。

このアプローチで字下げの例をマークアップすると次のようになります。

<style>
  .indent { text-indent: 1em; }
</style>
<p>ごめんごめん、お待たせ。悪いね急に呼び出して。あ、髪型変えた？変えてない？だと思った。</p>
<p class="indent">でっさ、どう？ぶっちゃけ、理解した？条件付き確率。五分五分？いいじゃんいいじゃん！</p>
<p class="indent">でっさ、ちょっと聞いてほしいんだけど、ここに3つコーラがあります。このうち1つだけ炭酸入ってない。事前に抜いておいた。ぶっちゃけどれだと思う？これ？なるほど？じゃあ実際、ここに炭酸が入ってない確率ってどんぐらいだと思う？3分の1？いいじゃん、パーフェクト！</p>
<p class="indent">でっさ、こんなことをやってみよう。いま、ここに炭酸が入っていることが分かったわけなんだけど、どう？変えてみたい？選択肢。いま、こことここに炭酸が入っている確率、五分五分じゃないって言ったら、信じる？ちょっと待ってちょっと待って、めっちゃ疑ってんじゃん。絶対騙されませんよって顔。ここにあった炭酸が入っていない3分の1の確率が、全部このペットボトルに移ったんだ！</p>
<p>ほらな、えっ？喋り方が胡散臭い？こらっ。コーラだけに。</p>

段落は字下げをデフォルトで付けるものとして、例外的に字下げしない段落を指定したいと思えば次のようにマークアップする方針もあるでしょう。

<style>
  p:not(.no-indent) { text-indent: 1em; }
</style>
<p class="no-indent">ごめんごめん、お待たせ。悪いね急に呼び出して。あ、髪型変えた？変えてない？だと思った。</p>
<p>でっさ、どう？ぶっちゃけ、理解した？条件付き確率。五分五分？いいじゃんいいじゃん！</p>
<p>でっさ、ちょっと聞いてほしいんだけど、ここに3つコーラがあります。このうち1つだけ炭酸入ってない。事前に抜いておいた。ぶっちゃけどれだと思う？これ？なるほど？じゃあ実際、ここに炭酸が入ってない確率ってどんぐらいだと思う？3分の1？いいじゃん、パーフェクト！</p>
<p>でっさ、こんなことをやってみよう。いま、ここに炭酸が入っていることが分かったわけなんだけど、どう？変えてみたい？選択肢。いま、こことここに炭酸が入っている確率、五分五分じゃないって言ったら、信じる？ちょっと待ってちょっと待って、めっちゃ疑ってんじゃん。絶対騙されませんよって顔。ここにあった炭酸が入っていない3分の1の確率が、全部このペットボトルに移ったんだ！</p>
<p class="no-indent">ほらな、えっ？喋り方が胡散臭い？こらっ。コーラだけに。</p>

Extra-Semantic-MarkupアプローチはHook-Elementアプローチの上位互換なので、拡張性を重視するのであればまずはExtra-Semantic-Markupアプローチを検討するのがよいでしょう。

上位互換であるというのは次のような意味です。

<p>
  ごめんごめん、<wbr>お待たせ。<wbr>悪いね急に呼び出して。<br>
  あ、髪型変えた？<wbr>変えてない？<wbr>だと思った。
</p>

上記のHook-Elementアプローチは次のように書き換えられます。

<p>
  <span class="line"><!--
    --><span class="word">ごめんごめん、</span><!--
    --><span class="word">お待たせ。</span><!--
    --><span class="word">悪いね急に呼び出して。</span><!--
  --></span><!--
  --><span class="line"><!--
    --><span class="word">あ、髪型変えた？</span><!--
    --><span class="word">変えてない？</span><!--
    --><span class="word">だと思った。</span><!--
  --></span>
</p>

この書き換えが可能な理由は、次の例を見てください。

ごめんごめん、<wbr>お待たせ。

これは、「ごめんごめん、」と「お待たせ。」の間に折り返しを制御するフック要素があるわけですが、上記のフック要素<wbr>と同じことが次のマークアップの疑似要素で表現できます。

<style>
  :nth-child(1 of .word)::after { content: ""; }
  /* または */
  :nth-child(2 of .word)::before { content: ""; }
</style>
<span class="word">ごめんごめん、</span><span class="word">お待たせ。</span>

また、Hook-Elementアプローチよりも高度なことができます。例えば<span>で括った要素自体のdisplayプロパティ値を変更したりすることができるようになります。

Extra-Semantic-Markupアプローチは、構造化の観点では非常に強力な表現ができますが、一方でHTMLが必要以上に複雑になるデメリットがあります。状況に応じてHook-Elementアプローチと使い分けするのがよいでしょう。

HTMLにおける和欧混植文のマークアップ

以下の文章をHTMLで書こうと思ったらどうなるでしょうか。

2025年7月13日頃、https://github.com/w3c/csswg-drafts/issues/12386ではCSSのtext-autospaceプロパティの初期値に関する議論がされています。CSSはWorld Wide Webの登場と共に考案されたスタイル情報を表現するための技術でWebブラウザによって実装状況が異なります。

以下では、この記事上で<pre>要素内容が1行で表示されると読みにくいので注釈宣言<!-- -->を用いて改行しています。

マークアップ例 (1) - 欧文前後のASCIIスペースなし

<p>2025年7月13日頃、<!--
--><a href="...">https://github.com/w3c/csswg-drafts/issues/12386</a><!--
-->ではCSSの<code>text-autospace</code>プロパティの初期値に関する議論がされています。<!--
-->CSSはWorld Wide Web（ワールド・ワイド・ウェブ）の登場と共に考案された<!--
-->スタイル情報を表現するための技術でWebブラウザによって実装状況が異なります。</p>

これはAstroの日本語訳ドキュメントのライティング方針です。

Astroの日本語翻訳ガイドライン

マークアップ例 (2) - 要素タグ前後のASCIIスペースあり

<p>2025年7月13日頃、<!--
--><a href="...">https://github.com/w3c/csswg-drafts/issues/12386</a> <!--
-->ではCSSの <code>text-autospace</code> プロパティの初期値に関する議論がされています。<!--
-->CSSはWorld Wide Web（ワールド・ワイド・ウェブ）の登場と共に考案された<!--
-->スタイル情報を表現するための技術でWebブラウザによって実装状況が異なります。</p>

• <a>要素と<code>要素の前後にASCIIスペースを挿入しています
• ただし例外として、句読点、カギ括弧などの日本語《約物》と英数字が隣接する場合は半角スペースを挿入しません

マークアップ例 (3) - 欧文フレーズ前後のASCIIスペースあり

<p>2025年7月13日頃、<!--
--><a href="...">https://github.com/w3c/csswg-drafts/issues/12386</a> <!--
-->では CSS の <code>text-autospace</code> プロパティの初期値に関する議論がされています。<!--
-->CSS は World Wide Web（ワールド・ワイド・ウェブ）の登場と共に考案された<!--
-->スタイル情報を表現するための技術で Webブラウザによって実装状況が異なります。</p>

• CSS, World Wide Web, Webブラウザの前後にASCIIスペースを挿入しています
• ただし、Webブラウザを1つのフレーズと見做し、Webとブラウザの間にはASCIIスペースを入れていません

マークアップ例 (4) - 英単語前後の ASCII スペースあり

<p>2025年7月13日頃、<!--
--><a href="...">https://github.com/w3c/csswg-drafts/issues/12386</a> <!--
-->では CSS の <code>text-autospace</code> プロパティの初期値に関する議論がされています。<!--
-->CSS は World Wide Web（ワールド・ワイド・ウェブ）の登場と共に考案された<!--
-->スタイル情報を表現するための技術で Web ブラウザによって実装状況が異なります。</p>

• WebブラウザのWebとブラウザの間にもASCIIスペースを挿入しています

マークアップ例 (5) - 英数字前後のASCIIスペースあり

<p>2025 年 7 月 13 日頃、<!--
--><a href="...">https://github.com/w3c/csswg-drafts/issues/12386</a> <!--
-->では CSS の <code>text-autospace</code> プロパティの初期値に関する議論がされています。<!--
-->CSS は World Wide Web（ワールド・ワイド・ウェブ）の登場と共に考案された<!--
-->スタイル情報を表現するための技術で Web ブラウザによって実装状況が異なります。</p>

• 欧文・英単語に加えて、数字の前後にもASCIIスペースを挿入しています

これはMDNのライティング方針です。

MDN日本語訳 表記ガイドライン

マークアップ例 (6) - 片仮名複合語の単語前後のASCIIスペースあり

<p>2025 年 7 月 13 日頃、<!--
--><a href="...">https://github.com/w3c/csswg-drafts/issues/12386</a> <!--
-->では CSS の <code>text-autospace</code> プロパティの初期値に関する議論がされています。<!--
-->CSS は World Wide Web（ワールド ワイド ウェブ）の登場と共に考案された<!--
-->スタイル情報を表現するための技術で Web ブラウザによって実装状況が異なります。</p>

• 欧文ではなく和文においても単語前後にASCIIスペースを挿入するケースがあります
• 「ワールドワイドウェブ」という片仮名複合語をASCIIスペースで区切っています

JTF（Japan Translation Federation）日本語標準スタイルガイド（翻訳用）では次のようなルールが存在しています。

長いカタカナ複合語は中黒または半角スペースで区切る

マークアップ例 (7) - Extra-Semantic-Markupアプローチを採用する

<p>
  <time data-text-format="cjk-date" datetime="2025-07-13"><!--
    --><span data-text-format="digit">2025</span><span data-text-format="cjk-unit">年</span><!--
    --><span data-text-format="digit">7</span><span data-text-format="cjk-unit">月</span><!--
    --><span data-text-format="digit">13</span><span data-text-format="cjk-unit">日</span><!--
  --></time><!--
  --><span data-text-format="cjk-text">頃、</span><!--
  --><a data-text-format="url" href="...">https://github.com/w3c/csswg-drafts/issues/12386</a><!--
  --><span data-text-format="cjk-text">では</span><!--
  --><abbr data-text-format="word">CSS</abbr><!--
  --><span data-text-format="cjk-text">の</span><!--
  --><code data-text-format="css-property-name">text-autospace</code><!--
  --><span data-text-format="cjk-text">プロパティの初期値に関する議論がされています。</span><!--
  --><abbr data-text-format="word">CSS</abbr><!--
  --><span data-text-format="cjk-text">は</span><!--
  --><span data-text-format="phrase">World Wide Web</span><!--
  --><span data-text-format="cjk-parentheses-container"><!--
    --><span data-text-format="cjk-parentheses-start">（</span><!--
    --><span data-text-format="katakana-phrase"><!--
      --><span data-text-format="cjk-word">ワールド</span><!--
      --><span data-text-format="cjk-word">ワイド</span><!--
      --><span data-text-format="cjk-word">ウェブ</span><!--
    --></span><!--
    --><span data-text-format="cjk-parentheses-end">）</span><!--
  --></span><!--
  --><span data-text-format="cjk-text">の登場と共に考案されたスタイル情報を表現するための技術で</span><!--
  --><span data-text-format="phrase"><!--
    --><span data-text-format="word">Web</span><!--
    --><span data-text-format="cjk-word">ブラウザ</span><!--
  --></span><!--
  --><span data-text-format="cjk-text">によって実装状況が異なります。</span>
</p>

• 本来不要なASCIIスペースを一切挿入せずに、文字列の塊を一つ一つマークアップしています
• text-autospaceプロパティで制御したかった字間を「和文と欧文の間」という文脈よりも詳細に制御できるようになります

このパターンでHTMLを記述することは、高度な字間制御ができるようになるものの、一般的なHTML文書で採用するにはその複雑さから現実的ではないでしょう。

和欧混植文における欧文（英数字）前後のスペース挿入の是非

前述の「マークアップ例 (7) - Extra-Semantic-Markupアプローチを採用する」までの考察を見てきて、何か気づくことはないでしょうか。

第一のポイント：Extra-Semantic-Markupの必要性

第一のポイントは、text-autospaceプロパティによる字間の調整を行うためには、ブラウザの内部ではExtra-Semantic-Markupに近いことを実行する必要があるという事実です。なぜなら、欧文と和文の字間を自動的に調整するために、どこが欧文でどこが和文かを判定する必要があるためです。

第二のポイント：文字列のコンテキストの抽出可能性

第二のポイントは、data-text-format属性を持たせて表現している文字列のグループがありますが、もともとの文章上でそのようなグループがどこにあるのかを検知できるようにすることが論理的に望ましいという事実です。これは「第二の理由：コンテキストの分離」で説明しているものです。

これは通常、日本語の文章でも鍵括弧を用いて文章を書くかどうか、という話に対応しています。

これは「第二の理由：コンテキストの分離」で説明しているものです。

と直前に書きましたが、この鍵括弧を外しても言いたいことは伝わります。

これは第二の理由：コンテキストの分離で説明しているものです。

しかし上記では、鍵括弧がないために当該の見出し文言が何であるかを抽出することが難しくなります。

こうした場合、一般的には鍵括弧が使われることが多いですが、代わりにASCIIスペースを用いても悪い道理はありません。

これは 第二の理由：コンテキストの分離 で説明しているものです。

別の例を見てみましょう。

関数getRandomは、1以上100以下の整数値を返します

人が読めば、getRandomという関数名の関数の返り値が1以上100以下の整数だということは読み取れます。しかしこれはマシンリーダブルでしょうか。もしかしたら「関数getRandom」という関数名の関数かもしれません。

関数名に日本語を含むことは考えられないと思うでしょうか。しかしモダンなプログラムでもテスト関数はしばしば日本語を含む関数名を設定します。

function test_関数getRandomは1以上100以下の値を返す() { ... }

この関数名を文章に書きたいとき、どうするでしょうか。

関数test_関数getRandomは1以上100以下の値を返すは、10000回実行しても範囲外の値が返ってこないことをチェックします。

こんな書き方ではどこが関数名か分かりません。鍵括弧を使ってみましょう。

関数「test_関数getRandomは1以上100以下の値を返す」は、10000回実行しても範囲外の値が返ってこないことをチェックします。

ASCIIスペースを使うという方針も考えられます。

関数 test_関数getRandomは1以上100以下の値を返す は、10000回実行しても範囲外の値が返ってこないことをチェックします。

なお、このとき、関数名の中にある英数字の前後にASCIIスペースをつけてはいけないことは分かるでしょう。その文字列のコンテキストが重要なのです。

少し前に示した例文は、次のように書いたほうが望ましいはずです。これはHTML文書上の話だけではなく、プログラムコード上のコメントに書くような場合にも該当します。

関数 getRandom は、1 以上 100 以下の整数値を返します

さて、あなたはこの文章をHTMLで記述するとき、以下のどちらのアプローチで記述したいでしょうか。

一つ目：関数名と返り値の前後にASCIIスペースを入れる。

<p>関数 getRandom は、1 以上 100 以下の整数値を返します。</p>

二つ目：関数名と返り値の前後にASCIIスペースを入れない。

<p>関数getRandomは、1以上100以下の整数値を返します。</p>

それとも、Extra-Semantic-Markupを採用しますか？

第三のポイント：英数字前後のASCIIスペースは装飾文字なのか

第三のポイントは、英数字前後のASCIIスペースは装飾文字なのかという論点です。

Inline-Literalアプローチによる字下げのマークアップ例を思い出してみましょう。

<p>ごめんごめん、お待たせ。悪いね急に呼び出して。あ、髪型変えた？変えてない？だと思った。</p>
<p>　でっさ、どう？ぶっちゃけ、理解した？条件付き確率。五分五分？いいじゃんいいじゃん！</p>
<p>　でっさ、ちょっと聞いてほしいんだけど、ここに3つコーラがあります。このうち1つだけ炭酸入ってない。事前に抜いておいた。ぶっちゃけどれだと思う？これ？なるほど？じゃあ実際、ここに炭酸が入ってない確率ってどんぐらいだと思う？3分の1？いいじゃん、パーフェクト！</p>
<p>　でっさ、こんなことをやってみよう。いま、ここに炭酸が入っていることが分かったわけなんだけど、どう？変えてみたい？選択肢。いま、こことここに炭酸が入っている確率、五分五分じゃないって言ったら、信じる？ちょっと待ってちょっと待って、めっちゃ疑ってんじゃん。絶対騙されませんよって顔。ここにあった炭酸が入っていない3分の1の確率が、全部このペットボトルに移ったんだ！</p>
<p>ほらな、えっ？喋り方が胡散臭い？こらっ。コーラだけに。</p>

この記述はHTML文書としては明らかにアンチパターンでした。字下げは装飾情報であり、インデントの存在はCSSで制御されるべきものであるためです。

では、次のように英数字前後に付いているASCIIスペースは「字間」を表現するための装飾情報なのでしょうか。

<p>CSS は World Wide Web の登場と共に考案されたスタイル情報を表現するための技術で<!--
--> Web ブラウザによって実装状況が異なります。</p>

次のExtra-Semantic-Markupを見てみましょう。

<p>
  <span data-text-format="word">CSS</span><!--
  --><span data-text-format="cjk-text">は</span><!--
  --><span data-text-format="phrase">World Wide Web</span><!--
  --><span data-text-format="cjk-text">の登場と共に考案されたスタイル情報を表現するための技術で</span><!--
  --><span data-text-format="phrase"><!--
    --><span data-text-format="word">Web</span><!--
    --><span data-text-format="cjk-word">ブラウザ</span><!--
  --></span><!--
  --><span data-text-format="cjk-text">によって実装状況が異なります。</span>
</p>

このHTMLについて、要素タグ間の改行と空白類文字を維持したまま注釈宣言を外してもよいと考えることはできないでしょうか。

<p>
  <span data-text-format="word">CSS</span>
  <span data-text-format="cjk-text">は</span>
  <span data-text-format="phrase">World Wide Web</span>
  <span data-text-format="cjk-text">の登場と共に考案されたスタイル情報を表現するための技術で</span>
  <span data-text-format="phrase">
    <span data-text-format="word">Web</span>
    <span data-text-format="cjk-word">ブラウザ</span>
  </span>
  <span data-text-format="cjk-text">によって実装状況が異なります。</span>
</p>

このようにすると、フレージング・コンテンツ（インライン・コンテンツ）間に空白類文字が挟まります。結果的に、このマークアップ例においては「Webブラウザによって実装状況が異なります」という部分が「Webブラウザ」の後ろで分断されてしまい、「ブラウザによって実装状況」といった文字列での単純な文字列検索がヒットしなくなってしまいます。

つまり、和文と和文の間には空白類文字を追加すべきではないという結論が得られます。では欧文と和文の間はどうでしょうか。「World Wide Webの登場と共に」の部分は「World Wide Webの登場」という文字列検索ができなくなってしまいますが、それが直ちに問題と言えるかは場合に依ります。欧文と和文が独立した単語・フレーズであるような場合には問題ないと考えることもできるでしょう。

しかし「Webブラウザ」の部分はどうでしょうか。これは英語を用いずに書くと通常は「ウェブブラウザ」と書くものであり、わざわざ「ウェブ・ブラウザ」と書くことは少ないはずです。

JTFの「長いカタカナ複合語は中黒または半角スペースで区切る」というルールを守るにしても、「ウェブ ブラウザ」よりは「ウェブブラウザ」と書いた方がよいでしょう。そう考えると英語を用いた場合であっても「Webブラウザ」として置いたほうがよさそうです。

同様に、日付は典型的な問題があります。「第三の理由：ライティングガイドラインの存在」でも言及しましたが、「2025 年 7 月 13 日」のように記述されていては「2025年」という文字列検索にヒットしなくなってしまいます。

数値と単位の組み合わせはどうでしょうか。これはその部分のコンテキストによって適切な表記が変わります。

• プログラムコードのコンテキストの場合
  • margin プロパティの値は 10px とする
  • 入力データは 10 px のようになっている
• 和文のコンテキストの場合
  • このテーブルは、1メートルほどの高さである
  • 私の体重は 60kg です
  • ストレージの容量は 512TB です
  • この問題の正答率は 90% であった
  • 円周率の2分の1は 90° である
• 欧文のコンテキストの場合
  • This table is about one meter high
  • My weight is 60 kg
  • Storage capacity is 512 TB
  • The correct response rate for this question was 90%
  • One-half of pi is 90°

数値と単位の組み合わせの表記については、科学や学術的なガイドラインが存在しており、欧文（英文）で書く場合には「数値と単位の間にASCIIスペースを設ける必要がある」とされています。ただし%や°など一部の尺度・単位については数値と連結すべきとされています。

ただし、そうしたガイドラインはあくまで欧文での話です。和文においては日付と同様の問題があるため、数値と単位を連結して記述した方が都合が良いことが多いでしょう。

結局のところ、和欧混植文において英数字前後にASCIIスペースを書いてしまうと、隣接する文字列を分断することになってしまい「Web ブラウザ」や「2025 年」のようにテキストデータとして不適切な文字列になってしまうケースがあるのでした。

ここまでの考察で、3つのケースがあることが分かりました。

• 文字列のコンテキストを分離すべきケース
  • 関数 getRandom は、1 以上 100 以下の整数値を返します
  • 私の体重は 60kg です
• 文字列のコンテキストを分離してもしなくてもよいケース
  • ワールドワイドウェブ
  • ワールド ワイド ウェブ
  • ワールド・ワイド・ウェブ
  • CSSはWorld Wide Webの登場と共に考案されたスタイル情報を表現するための技術です
  • CSS は World Wide Web の登場と共に考案されたスタイル情報を表現するための技術です
• 文字列のコンテキストを分離すべきではないケース
  • Webブラウザ
  • 2025年7月13日

「文字列のコンテキストを分離すべきではないケース」で英数字前後にASCIIスペースを付けた場合は、それはInline-Literalアプローチによる「字間」を表す装飾文字であると考えるのがよさそうです。

第四のポイント：ASCIIスペースを付けると字間が空きすぎるという誤解

CSS は World Wide Web の登場と共に考案されたスタイル情報を表現するための技術で Web ブラウザによって実装状況が異なります。

このように英単語の前後にASCIIスペースを付けてしまうと、HTML文書においてはブラウザで表示するときに字間が空きすぎてしまうため不適切だという意見があります。

しかし、それに対してはtext-autospaceプロパティに指定できる値replaceがあります。HTML文書を記述する上で、英単語の前後にASCIIスペースを付けることと、結果的に表示される字間が不適切になることは関係ないのです。

というか、そんなことを言ったらWorld Wide Webの単語間の字間はどうなるのでしょうか。これは明らかにASCIIスペースによって確保されている字間であり、かつこの箇所はtext-autospaceでの制御範囲外です。

関連するCSSプロパティとしてletter-spacingとword-spacingがあります。World Wide Webのような英単語の字間はword-spacingプロパティで指定できますが、text-autospaceのように「ちょうどよい字間（つまり八分空き）」を空けるキーワードは用意されていません。

欧文中の単語間の字間についてはASCIIスペースでよいのに、和文と欧文の間の字間はASCIIスペースでは空きすぎていて都合が悪いと主張するのは矛盾していないでしょうか。

text-autospaceプロパティの初期値を巡る議論

ようやく本題です。

• [css-text] Reconsider the initial value of the text-autospace property #12386
• https://drafts.csswg.org/css-text-4/#text-autospace-property

このGitHub Issueでは、CSS仕様ではtext-autospaceの初期値としてnormal（つまり英数字前後に字間がつく）と定められているのに2025年3月にリリースされたSafari 18.4では初期値がno-autospace（何もしない）となっていて、仕様と実装に差異があることについて、Safariがそうした理由を酌んでCSS仕様の方の初期値をno-autospaceに変更すべきか否かについて議論がされています。

2025年7月上旬時点の経緯については、次の記事で現状について説明されています。

text-autospaceプロパティの初期値に関する考察

(A) HTMLの記述パターン

人々がどのようにHTMLを記述しているかについては、以下の3パターンがあるでしょう。

(A1) - 英数字前後にASCIIスペースを付けている

<p>CSS は World Wide Web の登場と共に考案されたスタイル情報を表現するための技術です。</p>

<p>関数 getRandom は、1 以上 100 以下の整数値を返します。</p>

(A2) - 英数字前後にASCIIスペースを付けていない

<p>CSSはWorld Wide Webの登場と共に考案されたスタイル情報を表現するための技術です。</p>

<p>関数getRandomは、1以上100以下の整数値を返します。</p>

(A3) - Extra-Semantic-Markupを採用している

<style>
  span { margin-inline: 2px; }
</style>
<p><span>CSS</span>は<span>World Wide Web</span>の登場と共に考案されたスタイル情報を表現するための技術です。</p>

<style>
  code { margin-inline: 2px; }
</style>
<p>関数<code>getRandom</code>は、<code>1</code>以上<code>100</code>以下の整数値を返します。</p>

(B) 英数字前後の字間について期待すること

(B1) 字間を空けたくない

これを期待しているHTML著者はほとんどいないでしょう。

いるとすれば、狭い領域にぎりぎり入る大きさのテキストをなんとか折り返さないように1行で表示できるようにしている場合や、和文と欧文が隣接する際のフォントデザインを行っている場合、表示される文字幅を使った計算を行っている場合など、かなり限定的なシーンに限られるように思います。

(B2) 字間を空けたい

「第一の理由：字間の確保」で書いているケースです。特にHTML文書だけではなく、問い合わせフォームの本文やテキストメールの本文など、プレーンテキストを書いている場合に字間を確保したいと思ったらASCIIスペースを付けるしかありません。

(B3) 特に字間を空けたいとは思っていない

「第二の理由：コンテキストの分離」で書いているケースです。字間が空いてもいいけれど、字間を空けるためにASCIIスペースを挿入しているわけではないケースがあります。

(C) text-autospaceの設定値の変更をWebページ閲覧者ができるべきか

GitHub Issueのコメントで、text-autospaceプロパティの初期値に依らず、閲覧者が字間を変更したい場合にそれができるようになっているべきではないかという意見があります。

If it is turned off by default, when a user wants to turn it on, they can only rely on the website developer to turn it on, and users have no other choice.

Ideally, I think the browser should provide a setting that allows users to turn this feature on. If this is not feasible, users can only rely on browser extensions to achieve it.

デフォルトでオフになっていると、ユーザーがオンにしたいときに、ウェブサイト開発者に頼るしかなく、ユーザーには他の選択肢がない。

理想的には、ブラウザがこの機能をオンにできる設定を提供すべきだと思う。それが不可能な場合、ユーザーはブラウザの拡張機能に頼るしかない。

個人的には、この意見には同意しかねます。というより、ブラウザの機能を誤解しているように思います。CSSという機能が登場した時から、Webブラウザは「ユーザースタイルシート」というものをサポートしています。

ウェブサイト開発者に頼るしかなく、ユーザーには他の選択肢がない

ということはなく、ユーザースタイルシートを使うことで、ユーザー（閲覧者）は自由に表示しているWebページのスタイルを変更することができるのです。

この機能の存在に言及せずに、ブラウザの拡張機能に頼るしかないという考えや、ブラウザのメニューからtext-autospaceに関する設定変更ができるようにすべきだという考えはいささか早計に思います。

本件に関連してブラウザに機能改善を要求するのであれば、上記に引用して示しているような意見ではなく、ユーザースタイルシートをURLごとに設定しやすくするためのUIを提供すべきだと主張した方がよいでしょう。

(D) text-autospaceの望ましい初期値はどのように考えるべきか

後続するGitHub Issueのコメントで、「(C) text-autospaceの設定値の変更をWebページ閲覧者ができるべきか」の意見に対するコメントがついています。

If it is turned off by default, when a user wants to turn it on, they can only rely on the website developer to turn it on, and users have no other choice.

Yes, if we default to no-autospace, users who want spacing have to rely on developers to turn it on.
But then again, if we default to normal, users who don't want it also depend on developers to turn it off.
Either way, users don't have official control.
This makes me think that the default should match what most users actually prefer - but that's exactly what we're struggling to figure out. It's not realistic to gather reliable data for now, and considering the future generation, it's even more complicated.

デフォルトでオフになっていると、ユーザーがオンにしたいときに、ウェブサイト開発者に頼るしかなく、ユーザーには他の選択肢がない。

はい。もしデフォルトでno-autospaceにすれば、字間の確保を望むユーザーはWebページ開発者に頼ってそれをオンにしなければならなくなります。
しかしまた、デフォルトをnormalにすれば、字間の確保を望まないユーザーは、Webページ開発者がそれをオフにすることに依存することになります。
いずれにせよ、ユーザーは公式にコントロールできません。
このことから、デフォルトは多くのユーザーが実際に好むものに合わせるべきだと思います。今のところ信頼できるデータを集めるのは現実的ではないですし、将来の世代を考えるとさらに複雑です。

既にこの世に存在するHTML文書がどのように作られているか（A1, A2, A3のいずれなのか）、その文書の著者はどういう振る舞いを期待しているのか（B1, B2, B3のいずれなのか）、そして更に、今後新たにHTML文書を作成する著者はどう考えるのかについてデータを集めて検討することは困難でしょう。

このことから、デフォルトは多くのユーザーが実際に好むものに合わせるべきだと思います。

私はこの考えを強く否定するわけではありませんが、全く別の考えを持っています。

それは、HTML, CSSの在り方やブラウザ実装に詳しい専門家（おそらくこのスレッドで意見を交わしている我々のこと）が権威主義的（Technocracy）な方法で仕様を決定すべきであるという考えです。

かつて、Invalidなリストのマークアップが世に蔓延っている状況を加味してcounter-resetプロパティの仕様を改定したことで、本来の理想的な仕様が実現できなくなった例があります。この詳細はInvalid な HTML のせいで counter-reset の仕様が捻じ曲げられた件というブログ記事を参照ください。

その出来事の再来を危惧しているわけではありませんが、民主主義的に仕様を決めるというのは合理的に思える一方で、非効率的なことがしばしばあります。道具を正しく扱えない人のために、本来の機能を制限するというのは本末転倒です。CSS研究者としてそのような未来は避けたいと考えています。

text-autospaceプロパティの初期値に関する私の結論

理想的な状態は何か、そしてそれを制限するような現実的な問題はあるか、それらを順に考えた上で「現実的な答え」を見出すべきだと考えます。

理想的なtext-autospaceプロパティの初期値とは

HTML, CSSという技術が登場した年にtext-autospaceの導入を検討したとしたら、あなたなら初期値をどうすべきだと考えるでしょうか。これが本件の答えを出すための最初のステップです。

• 3.2.6 Handling of Western Text in Japanese Text using Proportional Western Fonts プロポーショナルな​欧字を用いた​和欧文混植処理

W3C Working Groupによる日本語組版処理の要件では、

欧字・アラビア数字の前後に配置される平仮名（cl-15），片仮名（cl-16）又は漢字等（cl-19）との字間は，四分アキとする

と定められています。

そして、[css-text-4] interscript text-spacing as default #8262では、text-autospaceプロパティの前身であるtext-spacingプロパティの初期値について、2022年時点で次のように決定されています。

• Adds ideograph-alpha and ideograph-numeric to the initial value, normal.
• Adds a UA stylesheet rule to disable text-spacing in pre, code, and tt to preserve their monospace behavior.
• Specifies that non-zero margin/border/padding inhibits autospacing.
• Clarifies that intervening characters such as spaces also inhibit autospacing.
• Defines the interscript autospace to be 1/8 of the ideographic advance (0.125ic), which is the smallest amount in the common-use range. The primary justification for using 1/8 instead of 1/6 or 1/4 is that, since we're trying to make this the default, it minimizes the layout impact on existing pages. (Note that Antenna House uses a 1/4 default.)

• 初期値 normal に ideograph-alpha と ideograph-numeric を追加。
• pre、code、tt のモノスペースの動作を維持するために、text-spacing を無効にするUAスタイルシート規則を追加。
• margin/border/padding がゼロでない場合、自動スペーシングを禁止することを指定。
• 空白のような介在する文字も自動スペーシングを禁止することを明確にしました。
• インタースクリプトの自動スペースを、表意文字アドバンス (0.125ic) の 1/8 と定義。1/6 や 1/4 ではなく 1/8 を使う主な理由は、これをデフォルトにしようとしているため、既存のページへのレイアウトの影響を最小限に抑えるためです。(Antenna House は 1/4 をデフォルトとしています）。

英数字前後にASCIIスペースがたくさん付けられたHTML文書がまだこの世にほとんど存在していないとして、CSS仕様策定者であるあなたはtext-autospaceプロパティの初期値をどうすべきだと考えるでしょうか。

1999年時点でのtext-autospaceの仕様ではIEでしか実装されていなかった状況もあり、字間のためにASCIIスペースを明示的に挿入しているHTML文書が存在していました。それらへの影響を出さないように互換性を考慮する形で初期値はnoneと定められていました。

しかし実際の理想的な挙動はどうでしょうか。text-autospaceプロパティの実装がなければWebページ閲覧者は和文と欧文の字間に「読みやすい」余白を設けることができません。読みにくいからこそASCIIスペースを明示的に挿入するというHTML著者が増えてしまったわけです。ですから、本質的には和文と欧文の字間というものは確保されるべきものでしょう。読みにくい状況が嬉しい著者も閲覧者もいませんよね。

インタースクリプトの自動スペースを、表意文字アドバンス (0.125ic) の 1/8 と定義。1/6 や 1/4 ではなく 1/8 を使う主な理由は、これをデフォルトにしようとしているため、既存のページへのレイアウトの影響を最小限に抑えるためです。(Antenna House は 1/4 をデフォルトとしています）。

上記のような考慮があることも踏まえると、normalを初期値にしない理由はありません。

理想的なtext-autospaceプロパティの初期値はnormalです。

現実的なtext-autospaceプロパティの初期値とは

ではなぜ、Safari 18.4はnormalではなくno-autospaceを初期値として実装する選択肢を選んだのでしょうか。

Safari 18.4のリリースにおける本件の背景についてのコメントがあります。

Yes, Safari 18.4 shipped text-autospace: no-autospace as the default, knowing that normal is the specified default. We did so with the awareness we can always change the default in the future.

Doing it this way is a bit more conservative, more careful, getting text-autospace into the hands of authors in one step, and potentially turning it on for all content in the future as another step. Of course, there's always a concern about compat whenever the web changes existing defaults. We are the first browser to ship support, and we took a more conservative path. We can all watch as authors use it in Safari, and ensure things are going well.

Don't misunderstand Safari 18.4 as either a mistake of incompetence or a permanent decision. It's neither.

そうです。normalが指定されたデフォルトであることを知っていましたが、Safari 18.4ではtext-autospace: no-autospaceをデフォルトとして出荷しました。私たちは、将来的にデフォルトをいつでも変更できることを意識してそうしました。

この方法は少し保守的で、より注意深く、text-autospaceを一歩で作者の手に渡し、もう一歩で将来的にすべてのコンテンツでオンにする可能性があります。もちろん、ウェブが既存のデフォルトを変更するときはいつも、互換性に関する懸念があります。私たちはサポートを提供する最初のブラウザであり、より保守的な道を選びました。作者がSafariでそれを使うのを見守り、物事がうまくいっていることを確認することができます。

Safari 18.4を無能の過ち、あるいは恒久的な決定と誤解しないでください。そのどちらでもありません。

もう一つ、取り上げるべきポイントがあります。パフォーマンスに関する懸念です。

本件のスレッドの最初の意見でパフォーマンスに関する話が書かれています。

This feature hits the performance in a lot higher degree than other similar features such as the text-spacing-trim property because it has a lot more candidate characters, spread across Unicode blocks. Implementing an optimization to skip most of the computation when not applicable succeeds less. The current Blink implementation can avoid most of the performance hits for Latin scripts, but all other scripts are impacted by 1-5% of the layout time.

In addition to the WebKit shipping "off by default", @masayuki-nakano, a Japanese Gecko engineer, also expressed a concern about the performance hit.

この機能は、text-spacing-trimプロパティのような他の類似機能よりも、Unicodeブロックにまたがって、より多くの候補文字があるため、はるかに高い程度でパフォーマンスに打撃を与えます。適用できない場合に計算の大部分をスキップする最適化を実装しても、成功率は低くなります。現在のBlinkの実装では、ラテンスクリプトのパフォーマンスヒットをほとんど回避できますが、その他のスクリプトはすべて、レイアウト時間の1～5％の影響を受けます。

WebKitが「デフォルトでオフ」で出荷されていることに加え、日本のGeckoエンジニアである @masayuki-nakano 氏もパフォーマンス・ヒットについて懸念を表明しています。

本件のGitHub Issueのコメントを見ると、パフォーマンス上の懸念もあるので初期値はno-autospaceの方がいいのではないか、という意見が出ています。

個人的には、もしもtext-autospace: normalをWebページに適用するとパフォーマンス上の問題が出るのだとしたら、初期値云々ではなくtext-autospace: normalは使い物にならないという結論に至るように思います。

「和文と欧文の字間を読みやすく調整する」という機能を提供することと、パフォーマンス上の問題を起こさずに機能を提供することは両立されるべきです。

これが両立できていない段階でtext-autospaceプロパティを提供すること自体が誤りではないでしょうか。パフォーマンス上の問題を懸念があることを理由にnormal値を初期値として採用したくないけれど、text-autospaceプロパティ自体は提供したいというのであれば、現実的なtext-autospaceプロパティの初期値はno-autospaceで良いと思います。

CSS仕様としての適切なtext-autospaceの初期値とは

text-autospaceプロパティの初期値をnormalではなくno-autospaceに変えた方がよいかもしれないという意見は、現状のブラウザに実装されたアルゴリズムではパフォーマンス上の懸念があるために初期値をnormalにするのは好ましくない、という根拠であるように理解しています。

もしパフォーマンス上の懸念がないにも関わらず初期値をnormalではなくno-autospaceに変えた方がよいかもしれないという意見が出ているとしたら、それはどういう理由でしょうか。既存のWebページの挙動が変わることを懸念しているのでしょうか。

しかしその懸念に対しては既に考慮がなされています。既存ページへの影響を最小限にするために字間の空きを1/8にしています。

CSS仕様としてのtext-autospaceの初期値はnormalであるべきと考えます。

最後の審判

本件のGitHub Issueのスレッドを作成したkojiishi氏によるコメントがあります。

Seeing more opinions wanting to turn it on is really great and helpful, thank you. It helps us to prove that our efforts to discuss, write specs, and implement, for over decades, is the right thing. I hope it also helps raising the priority of this feature for other browsers.

Forcing it on by default is a different topic. It means that we ignore authors who don't want the space. It means that we require users who don't want it to install extensions. It means that we don't care slowing down pages of other scripts, such as Arabic, Thai, Devanagari, etc.

それをオンにしたいという意見が増えることは、本当に素晴らしいことだし、役に立ちます。何十年にもわたって議論し、仕様を書き、実装してきた私たちの努力が正しいことを証明するのに役立ちます。また、他のブラウザにとっても、この機能の優先度を上げる一助になることを願っています。

デフォルトで強制的にオンにすることは、別のトピックです。それは、スペースを必要としない作者を無視することを意味します。それは、この機能を必要としないユーザーに拡張機能のインストールを要求することを意味します。アラビア語、タイ語、デーヴァナーガリー語など、他のスクリプトのページが遅くなるのを気にしないということです。

「CSS仕様としての初期値が何であるべきか」という話と、「2025年7月時点で直近リリースされるブラウザ（Safari, Google Chrome）の初期値が何であるべきか」という話を混同していませんか。パフォーマンス上の問題が発生するのはブラウザに実装する際のアルゴリズムの問題であって、text-autospaceプロパティ自体の問題ではありません。

もし本質的にtext-autospaceプロパティで実現する機能がパフォーマンス上の問題を抱えているのだとしたら、text-autospaceプロパティをサポートすべきではないですし、そんな機能はCSS仕様から排除した方がよいでしょう。

CSS仕様としてのtext-autospaceプロパティの初期値はnormal（正確にはno-autospaceではないもの）であるべきだと考えます。

将来的な話

ここからは本題から逸れます。

そもそもですが、なぜtext-autospaceプロパティは「和文と欧文の字間」しか制御できないのでしょうか。欧文間（英単語間）の字間は制御できなくてよいのでしょうか。「第四のポイント：ASCIIスペースを付けると字間が空きすぎるという誤解」でも言及していますがword-spacingプロパティとの関係性がよく分かりません。あるいは、「欧文と隣接するCJK文字の（句読点、カギ括弧などの）約物」の字間を制御する方法はないのでしょうか。

「マークアップ例 (7) - Extra-Semantic-Markupアプローチを採用する」で示した以下のようなマークアップをせずとも、任意の文字列グループ間の字間をちょうどよい感じに調整する仕組みの提案はないのでしょうかね。

<p>
  <time data-text-format="cjk-date" datetime="2025-07-13"><!--
    --><span data-text-format="digit">2025</span><span data-text-format="cjk-unit">年</span><!--
    --><span data-text-format="digit">7</span><span data-text-format="cjk-unit">月</span><!--
    --><span data-text-format="digit">13</span><span data-text-format="cjk-unit">日</span><!--
  --></time><!--
  --><span data-text-format="cjk-text">頃、</span><!--
  --><a data-text-format="url" href="...">https://github.com/w3c/csswg-drafts/issues/12386</a><!--
  --><span data-text-format="cjk-text">では</span><!--
  --><abbr data-text-format="word">CSS</abbr><!--
  --><span data-text-format="cjk-text">の</span><!--
  --><code data-text-format="css-property-name">text-autospace</code><!--
  --><span data-text-format="cjk-text">プロパティの初期値に関する議論がされています。</span><!--
  --><abbr data-text-format="word">CSS</abbr><!--
  --><span data-text-format="cjk-text">は</span><!--
  --><span data-text-format="phrase">World Wide Web</span><!--
  --><span data-text-format="cjk-parentheses-container"><!--
    --><span data-text-format="cjk-parentheses-start">（</span><!--
    --><span data-text-format="katakana-phrase"><!--
      --><span data-text-format="cjk-word">ワールド</span><!--
      --><span data-text-format="cjk-word">ワイド</span><!--
      --><span data-text-format="cjk-word">ウェブ</span><!--
    --></span><!--
    --><span data-text-format="cjk-parentheses-end">）</span><!--
  --></span><!--
  --><span data-text-format="cjk-text">の登場と共に考案されたスタイル情報を表現するための技術で</span><!--
  --><span data-text-format="phrase"><!--
    --><span data-text-format="word">Web</span><!--
    --><span data-text-format="cjk-word">ブラウザ</span><!--
  --></span><!--
  --><span data-text-format="cjk-text">によって実装状況が異なります。</span>
</p>

関連文献

1. [css-text] Reconsider the initial value of the text-autospace property #12386
2. 1999年時点のtext-autospace仕様
3. [css3-text] text-spacing プロパティ (text-trim + text-autospace)
4. MDNの日本語翻訳ガイドライン
5. Astroの日本語翻訳ガイドライン
6. JTF（Japan Translation Federation）日本語標準スタイルガイド（翻訳用）
7. 3.2.6 Handling of Western Text in Japanese Text using Proportional Western Fonts プロポーショナルな​欧字を用いた​和欧文混植処理
8. CSS text - MDN
9. word-spacing - MDN
10. text-autospace - CSS Text Module Level 4
11. text-spacingが待ち遠しい
12. ep180 Monthly Platform 202506 | mozaic.fm
    • Ship: Insert CJK inter-script spacing: the CSS text-autospace property
    • 配信再生時間：00:20:00 - 00:34:00
13. [Solved] 日本語文章中、英単語の両端にスペースをつける人
14. text-autospaceの初期値をめぐる議論と現状

おわりに

この文書に何か意見や感想があれば、QiitaのコメントかTwitter（@debiru）でご連絡ください。