Chrome 157で使えるCSSとHTMLの新機能を156と比べて検証｜「…続きを読む」での省略、下線の長さ調整、HTMLを安全に足すappendHTML

2026年11月8日

11月3日（米国時間）に安定版の配信が始まったChrome 157で、CSSとHTMLで使える機能が増える

Googleは2026年11月3日（米国時間）、Chrome 157の安定版（157.0.8103.38／.39）をWindows、Mac、Linux向けに公開し、数日から数週間かけて順に配信すると告知しました。157は10月16日にデスクトップ向けのベータ版として公開され、10月22日と28日には、一部の利用者へ先に届ける早期安定版がWindowsから順に配信されていました（10月22日と10月28日の告知）。翌11月4日には、次の158の早期安定版（158.0.8127.18／.19）の配信もWindowsから始まっています（11月4日の告知）。

Chromeの新機能を一覧にしたChrome Platform Statusのリリースノートには、157で既定で有効になる機能が13件（2026年11月8日時点）載っています（Chrome Platform StatusのAPIで「Enabled by default」に分類されたもの）。この記事では、そのうちWebページを作る人がすぐに使える4つを取り上げます。はみ出した文字の末尾に好きな文字列を出す text-overflow の新しい値、下線の長さを調整する text-decoration-inset、HTMLの文字列から危ない部分を取り除いて足す appendHTML() などのメソッド、canvasの中にHTMLの要素を描く「HTML-in-canvas」です。

検証には、Googleが動作確認用に配っている「Chrome for Testing」の156.0.8078.80と157.0.8103.15を使い、同じページを両方で開いて表示と値を比べました（macOSで、画面を出さないヘッドレスモードで実行、2026年11月3日）。157.0.8103.15は、10月22日に更新されたベータ版と、同じ日に出た早期安定版の番号で、11月3日に配信が始まった安定版（157.0.8103.38／.39）より前の版です。157の機能として告知されていた角の一括指定（11月7日に提供予定が159へ変更）と、LoAF（描画が遅いフレームの記録）の新しい項目の2つが、手元の157ではフラグを付けたときだけ動いたことも後半で説明します。前回のChrome 156の記事と同じ形で、書き方、実際の表示、古いバージョンへの備えを順に見ていきます。

検証で分かったこと

Chrome 157では、省略記号と下線をCSSで調整でき、HTMLの文字列を安全に足すメソッドと、canvasにHTMLを描く機能も加わる

text-overflowの文字列

末尾を「…続きを読む」に

Chrome 156では文字の途中で切れる。ellipsisを先に書けば、156では「…」になる。

text-decoration-inset

下線を短く、長く

正の値で内側へ縮み、負の値で外側へ伸びる。transitionで動かせる。156では通常の下線。

appendHTML()など

HTMLを安全に足す

img、onerror、scriptを取り除いてから末尾に足す。156ではTypeErrorになる。

HTML-in-canvas

canvasにHTMLを描く

CSSの見た目のまま傾けて描け、描いた位置でボタンが当たり判定を受ける。156ではcanvasが空。

157の既定では無効だった2つ

角の一括指定（corner）と、描画が遅いフレームの記録（LoAF）に加わるスタイル・レイアウトの時間の内訳。LoAFはリリースノートで157の機能とされ、角の一括指定は提供予定が159に変わった。手元の157の既定ではどちらも無効で、実験的機能のフラグを付けると動いた。

text-overflowに文字列を書くと、はみ出した行の末尾が「…続きを読む」になる

1行に収まらない記事タイトルなどを「…」で切るときは、white-space: nowrap、overflow: hidden、text-overflow: ellipsis の3つを組み合わせてきました。Chrome 157からは、text-overflow に文字列を書くと、「…」の代わりにその文字列が行の末尾に出ます。Chrome Platform Statusの説明では、「(more)」のような文字列で、文字が切れていることを示す使い方が挙げられています。

.title {
  white-space: nowrap;
  overflow: hidden;
  text-overflow: ellipsis;          /* Chrome 156以前とSafari向け */
  text-overflow: " …続きを読む";    /* Chrome 157から */
}

同じページをChrome 156と157で開きました。それぞれ1つ目の箱には文字列の指定だけを、2つ目の箱には上のCSSのように ellipsis を先に書いています。文字列は表示されるだけなので、押せるようにしたいときは箱そのものをリンクにします。

CSSは、解釈できない値を含む宣言を読み飛ばします。Chrome 156は文字列の指定を丸ごと無視したため、1つ目の箱では初期値の clip（はみ出した部分をそのまま切る）が使われました。ellipsis を先に書いておけば、文字列に対応していないブラウザでは「…」、対応しているブラウザでは文字列が出ます。MDNの互換性データでは、Firefoxは早くから文字列に対応していて（Firefox 9から）、Safariはまだ対応していません。ellipsis を先に書く形にしておくと、Safariの閲覧者にも「…」が見えます。

CSSの仕様には、行の左端と右端に別々の値を書く2つの値の形（text-overflow: "[" "]" など）もあります。Chrome 157で CSS.supports()（ブラウザがその書き方に対応しているかを調べる関数）を使って調べると、この形は「対応していない」が返りました。Chromeで使えるのは、行の末尾に出す1つの文字列の形です。

text-decoration-insetで、下線を文字より短くも長くもできる

text-decoration-inset は、下線や取り消し線を、文字の両端からどれだけ内側で止めるか、または外側へ伸ばすかを決めるプロパティです。正の値で下線が内側へ縮み、負の値で文字より外側へ伸びます。値を1つ書くと両端に同じ値が入り、2つ書くと始まりと終わりに別々の値が入ります。

a    { text-decoration: underline 3px #f59e0b; }
.in  { text-decoration-inset: 0.4em; }   /* 両端を0.4emずつ縮める */
.out { text-decoration-inset: -0.3em; }  /* 両端を0.3emずつ伸ばす */

この値は transition で動かせます。手元では、0.5em（12px）から-0.25em（-6px）へ一定の速さ（linear）で1秒かけて切り替えると、0.5秒後の値はちょうど中間の3pxで、途中の値を通って変わりました。次のように書くと、マウスを重ねたときに下線が左右へ伸びます。リンクの下線が伸びる動きは、これまで背景のグラデーションや疑似要素で作ってきました。157からは下線そのものを動かせます。

a {
  text-decoration: underline 2px;
  text-decoration-inset: 0.5em;
  transition: text-decoration-inset .3s;
}
a:hover { text-decoration-inset: -0.25em; }

対応していないブラウザでは指定が無視され、文字の幅どおりの下線になります。表示が崩れる心配がないので、飾りとしてそのまま書き足せます。MDNの互換性データでは、FirefoxはFirefox 146から対応し、Safariは開発者向けの試験版（Safari Technology Preview）で対応しています。

appendHTMLは、HTMLの文字列から危ない部分を取り除いてから足す

JavaScriptでHTMLの文字列を要素に足すとき、これまでは innerHTML や insertAdjacentHTML() を使ってきました。この2つは文字列をそのまま組み立てます。利用者の入力や外部から受け取った文字列を混ぜると、onerror のような属性に仕込まれたスクリプトが動くおそれがあります（クロスサイトスクリプティング、XSSと呼ばれる攻撃）。

Chrome 157では、文字列を足す場所ごとのメソッドがまとめて加わりました。末尾に足す appendHTML()、先頭に足す prependHTML()、要素の前後に足す beforeHTML() と afterHTML()、要素を置き換える replaceWithHTML() です。どれも、Chrome 156にもある setHTML() と同じく、ブラウザに組み込まれた無害化（サニタイズ）の仕組みを通してから足します。手元で数えると、157では要素（Element）のメソッドが22個増えていました。5つの位置、無害化するかどうか、一度に足すかstreamで足すかの組み合わせで20個、中身を入れ替える streamHTML() と streamHTMLUnsafe() で2個です。仕様の説明書は、setHTML() と setHTMLUnsafe() を合わせた24個を、次の3つの軸の組み合わせとして整理しています。

どこに足すか

append：末尾
prepend：先頭
before／after：要素の前／後ろ
replaceWith：要素と置き換え
set：中身を入れ替え（setHTML() と setHTMLUnsafe() は以前から、stream版は157から）

無害化するか

appendHTML()：無害化してから足す
appendHTMLUnsafe()：文字列のまま足す。runScripts: true を渡したときだけscriptも実行

一度に足すか

appendHTML()：文字列を一度に足す
streamAppendHTML()：少しずつ届く文字列を、届いた順に書き込む

出典：WICGの仕様の説明書「Dynamic markup - revamped」。メソッド名はChrome 157.0.8103.15で確認。

同じ文字列を3つのメソッドに渡して、結果を比べました（appendHTMLUnsafe() は runScripts: true の有無で2通り試したので、表は4行です）。文字列には、画像の読み込みに失敗すると処理を動かす onerror 付きの <img> と、<script> を入れています。

無害化の初期設定では、<img> や <iframe>、style 属性、javascript: で始まるリンク先も取り除かれました。https:// で始まるリンクの <a> や、太字の <b> は残ります。初期設定に画像だけを足したいときは、new Sanitizer() で初期設定の無害化の設定を作り、img 要素と src・alt 属性を許可して渡します。

const html = '<p>本文<b>太字</b><a href="https://example.com/">リンク</a>'
           + '<img src="a.png" alt="写真" onerror="…"></p>';

el.appendHTML(html);
// el に足される部分 → <p>本文<b>太字</b><a href="https://example.com/">リンク</a></p>

const s = new Sanitizer();   // 初期設定から始める
s.allowElement('img');
s.allowAttribute('src');
s.allowAttribute('alt');
el2.appendHTML(html, { sanitizer: s });
// el2 に足される部分 → <p>本文<b>太字</b><a href="https://example.com/">リンク</a><img src="a.png" alt="写真"></p>

設定を { elements: ['p', 'img'], attributes: ['src', 'alt'] } のように elements の一覧で渡すと、その一覧がそのまま許可する要素の全部になります。手元で試すと、一覧に書かなかった <b> と <a> は中の文字ごと取り除かれ、<p>本文<img src="a.png" alt="写真"></p> になりました。初期設定に足したいときは、上の new Sanitizer() の書き方を使います。

名前にUnsafeの付かない appendHTML() では、allowAttribute('onerror') で onerror を許可しても、onerror は取り除かれました。設定で残せるのは、スクリプトを動かさない要素と属性です。

名前に stream が付くメソッドは、少しずつ届く文字列を順に書き込むためのものです。streamAppendHTML() が返すストリームから getWriter() で書き込み用のオブジェクトを取り出し、<li> を開いたまま要素の途中で区切った3つの断片を0.15秒おきに書き込みました。1つ目を書き込んだ時点で2行目の要素ができ始め、最後に3行の一覧になりました。3つ目の断片に入れた onclick は取り除かれています。サーバーから少しずつ届くHTMLを、届いた分から表示するときに使えます。次のコードは、type="module" のスクリプトか async 関数の中で書きます。

const writer = list.streamAppendHTML().getWriter();
await writer.write('<li>1つ目の断片で届いた行</li><li>2つ目の');
await writer.write('断片で閉じた行</li>');   // 検証では0.15秒おきに書き込んだ
await writer.write('<li onclick="alert(1)">3つ目の断片の行</li>');
await writer.close();
// → 3行の一覧。onclick は取り除かれる

Chrome 156以前やほかのブラウザでは、新しいメソッドを呼ぶとTypeErrorになります。MDNの互換性データでは、appendHTML() に対応しているのは今のところChrome 157だけです。setHTML() があるブラウザ（MDNではChrome 146以降、Firefox 148以降）なら、<template> の中で無害化してから足すと、Chrome 156でも157の appendHTML() と同じ結果になりました。

function appendSafe(el, html) {
  if ('appendHTML' in el) {          // Chrome 157から
    el.appendHTML(html);
  } else if ('setHTML' in el) {      // Chrome 146以降、Firefox 148以降
    const t = document.createElement('template');
    t.setHTML(html);
    el.append(t.content);
  } else {
    // どちらもないブラウザでは、文字列を使わずに
    // createElement() と textContent で要素を作る
  }
}

HTML-in-canvasで、canvasの中にHTMLの要素をそのまま描ける

canvasは、図形や画像をJavaScriptで自由に描ける要素で、グラフやゲーム、画像編集の画面によく使われます。文字を描くには fillText() で1行ずつ位置を決める必要があり、折り返し、1行の中で書体や色を変える表示、画面読み上げへの対応は自分で用意してきました。HTML-in-canvasの仕様の説明書も、canvasで作った画面がアクセシビリティや多言語の表示で不利になる理由として、この点を挙げています。

HTML-in-canvasでは、canvasの子要素に置いたHTMLを、CSSを当てた見た目のままcanvasへ描けます。Chrome Platform Statusによると、Chrome 148からオリジントライアル（申し込んだサイトだけで試せる仕組み）で試せるようになり、157から既定で使えます。書き方は次のとおりです。canvasに content="drawable"、描く子要素に drawable を付けます。

<canvas id="c" width="420" height="190" content="drawable">
  <div id="card" drawable>
    canvas に描いた <b>HTML</b> の要素
    <button id="btn" type="button">ボタン</button>
  </div>
</canvas>
<script>
  const c = document.getElementById('c');
  const ctx = c.getContext('2d');
  c.onpaint = () => {          // 子要素の見た目が記録されたあとに呼ばれる
    ctx.reset();
    ctx.translate(96, 40);
    ctx.rotate(-0.1);          // 少し傾けて描く
    ctx.drawElementImage(document.getElementById('card'), 0, 0);
  };
  c.requestPaint();            // 次の画面の更新で paint イベントを起こす
</script>

仕様の説明書によると、drawable の付いた子要素の見た目は画面の更新のたびに記録され、drawElementImage() はその記録を描きます。最初の記録より前に呼ぶと例外になるため、描画は paint イベントの中で行います。上のコードをCSSなしでそのまま開くと、Chrome 157では文字とボタンが傾いて描かれました。

2Dのcanvasでは、drawElementImage() で描いた位置に、要素の位置情報も移ります。手元では、ボタンの getBoundingClientRect() が描いた位置を返しました。その位置にある要素を返す elementFromPoint() を、描いたボタンの上で呼ぶとボタンが返り、canvasの子要素として置かれていた元の位置で呼ぶとcanvasが返りました。描いた見た目と、当たり判定を受ける要素の位置が一致します。仕様の説明書によると、この位置情報は画面読み上げなどの支援技術にも渡ります。

Chrome 156では、canvasの子要素は表示されず、canvasは空のままでした。対応していないブラウザに備えるには、'drawElementImage' in CanvasRenderingContext2D.prototype で確かめ、ない場合はcanvasを使わずにHTMLとして表示する分岐を用意します。

角の一括指定とLoAFの新しい項目は、手元の157では実験的機能のフラグを付けたときだけ動いた

Web制作に関係する機能で、157の機能として告知されていたものがほかに2つあります。角の丸みと形を1つの指定でまとめて書ける corner などの一括指定と、描画に時間がかかったフレームを記録するLong Animation Frames（LoAF）に、スタイルの計算とレイアウトにかかった時間の内訳を加えるstyleDuration などの項目です。角の一括指定は、11月7日にChrome Platform Statusで提供予定が159に変わり、157のリリースノートから外れました。

手元の157.0.8103.15では、どちらも既定では使えませんでした。CSS.supports('corner', '28px squircle')（角を28pxの大きさで、なめらかにふくらんだ形にする指定）は、値の書き方を7通り変えても「対応していない」を返し、LoAFの記録にも新しい項目は現れません。Chromeの起動時に実験的な機能をまとめて有効にするフラグ（--enable-experimental-web-platform-features）を付けると、どちらも動きました。

Chromiumのソースで機能の既定の状態を決めているファイル（runtime_enabled_features.json5）を見ると、2つは11月3日に配信が始まった安定版（157.0.8103.38）でも「experimental」（実験的機能のフラグで有効）のままでした。今回取り上げた4つの機能は「stable」（既定で有効）です。158の早期安定版（158.0.8127.18）では、LoAFの項目が「stable」に変わり、角の一括指定は「experimental」のままです。

角の一括指定（corner）

Chrome 156：使えない
Chrome 157（既定）：使えない
Chrome 157＋フラグ：使える
Chromiumのソースでの既定：157の安定版、158の早期安定版とも実験的機能（experimental）

LoAFの時間の内訳（styleDurationなど）

Chrome 156：項目なし
Chrome 157（既定）：項目なし
Chrome 157＋フラグ：styleDurationとlayoutDurationが現れる
Chromiumのソースでの既定：157の安定版は実験的機能（experimental）、158の早期安定版は既定で有効（stable）

角の形だけの指定（corner-shape）

Chrome 156：使える
Chrome 157：使える
border-radius: 28px; corner-shape: squircle; のように組み合わせて、今のChromeで角の形を変えられる

Chrome for Testing 156.0.8078.80と157.0.8103.15で確認（2026年11月3日）。ソースの設定はChromiumのruntime_enabled_features.json5（157.0.8103.38、158.0.8127.18。2026年11月8日に確認）。

Chrome Platform Statusでは、角の一括指定の提供予定が2026年11月7日に159へ変わりました。角の一括指定を使うかどうかは、Chromeのバージョン番号で決めずに、@supports (corner: 28px squircle) で確かめてから決めます。それまでは、border-radius と corner-shape を別々に書く形で角の形を変えられます。

Chrome 157の新機能を取り入れるときの3つのポイント

デスクトップ版のChrome 157の安定版は、11月3日（米国時間）に配信が始まりました。Googleの告知どおり数日から数週間かけて順に配信されるので、しばらくは古いChromeを使う閲覧者も残ります。MDNの互換性データでは、今回の4つの機能はSafariの正式版ではまだ使えません（text-decoration-inset は開発者向けの試験版だけ）。ここまでの検証をもとに、取り入れるときのポイントを3つにまとめます。

1. 省略表示と下線は、対応していないブラウザでも崩れない形で書く

text-overflow は ellipsis を書いたあとに文字列を書く。Chrome 156以前とSafariでは「…」、Chrome 157とFirefoxでは文字列が出る。下線の text-decoration-inset は、対応していないブラウザでは通常の下線になるので、そのまま書き足せる。

2. appendHTML()は、メソッドの有無の確認と代わりの処理を組にする

'appendHTML' in el で確かめ、ない場合は setHTML() と <template> で足す。初期設定に画像を足すなら、new Sanitizer() に allowElement('img') と src・alt の許可を足して渡す。設定を elements の一覧で書くと、書いた要素以外は中の文字ごと消える。

3. バージョン番号より、CSSは@supports、JavaScriptはメソッドの有無で確かめる

HTML-in-canvasは drawElementImage があるかで、角の一括指定は @supports (corner: 28px squircle) で確かめる。リリースノートに157と載っていても、手元の157では既定で有効になっていない機能があった。

text-overflow の文字列と text-decoration-inset は、対応していないブラウザでも読める表示のまま残るので、今日から書き足せます。まずは記事一覧のタイトルやリンクの下線に当てて、Chrome 157とほかのブラウザで見比べてみてください。

参考資料

• Chrome Beta for Desktop Update（Chrome Releases、2026年10月16日）
• Early Stable Update for Desktop（Chrome Releases、2026年10月28日）
• Stable Channel Update for Desktop（Chrome Releases、2026年11月3日）。157.0.8103.38／.39の安定版の配信開始
• Early Stable Update for Desktop（Chrome Releases、2026年11月4日）。158.0.8127.18／.19の早期安定版
• Chrome 157 release notes（Chrome Platform Status）
• Dynamic markup - revamped（WICG）
• HTML-in-Canvas（WICG）
• browser-compat-data（MDN、2026年11月3日に参照）