手を入れていないサイトにも届くブラウザ側の変更

つくば市のホームページ制作会社

ブラウザの更新情報というと新しいCSSやAPIに目が向きがちですが、9月に出たChrome 154とFirefox 155、156の開発者向けリリースノートを読み比べると、こちらが何も変えていなくても既存サイトの見え方や動き方に関わる変更がいくつか含まれていました。新機能の紹介とは少し角度を変えて、納品済みのサイトや社内システムを抱える側が気にしておきたい項目を並べてみます。

その1 HTTPのまま開くと確認画面が出るのが既定に

Chrome 154では、暗号化されていないhttpの接続でサイトを開こうとしたとき、利用者に確認を求める動作が既定で有効になりました。管理者向けには企業ポリシーでこの既定を制御する手段も用意されています。

公開サイトの多くはすでにHTTPS化されていますが、気になるのは周辺部分です。印刷物やQRコードに載せたhttpのURL、古い記事の中に残った内部リンク、LAN内で動く機器の管理画面などは、これまで素通りだったところで一度立ち止まる形になります。httpからhttpsへの転送がきちんと効いているか、紙の販促物に刷ったURLが今どうなっているかを、この機会に確かめておくと安心です。

その2 古い鍵交換方式だけのサーバーにFirefoxがつながらなくなる

Firefox 156では、TLSの接続開始時に既定で提示する鍵交換の方式から、有限体Diffie-Hellmanのffdhe2048とffdhe3072が外れました。リリースノートによると、これらの方式しか扱えないサーバーとは接続の取り決めが成立しなくなるとされています。

ほとんどのサーバーは楕円曲線を使うECDHEに対応しているため、一般的なレンタルサーバーやCDN経由のサイトで問題になることはまずないはずです。ただ、長く更新されていない自前のサーバー、古い業務用機器の管理画面、社内の古いシステムなどはこの限りではありません。「Firefoxでだけ開けない」という問い合わせが来たときの確認項目として覚えておくと役に立ちます。

その3 ポップオーバーやダイアログが意図せず閉じにくくなった

Chrome 154では、ポップオーバーやダイアログの外側を押したときに閉じる「ライトディスミス」の判定が、押し下げと離す操作の組み合わせからクリックイベントに切り替わりました。これにより、スマートフォンで画面をスクロールしただけのときや右クリックしたときに、開いていたメニューが勝手に閉じてしまう現象が起きにくくなります。

利用者にとっては素直な改善ですが、標準のpopover属性やdialog要素の挙動に合わせて独自の処理を足しているサイトでは、閉じるタイミングが以前と少しずれる可能性があります。スマートフォンでメニューを開いたまま縦にスクロールしてみる、といった簡単な確認をしておくとよさそうです。

その4 読み込みに失敗したモジュールを後から読み直せる

Firefox 155では、ネットワークエラーやMIMEタイプの誤りで読み込みに失敗したJavaScriptのモジュールが、失敗した状態のまま記憶されなくなりました。サーバー側が復旧すれば、同じ指定で読み込み直したときに成功するようになります。JSONやCSSのモジュール、動的なimportも対象です。

サーバーの一時的な不調やデプロイ中の瞬断で、ページを開き直すまで一部の機能が動かないという状況が減る方向の変更です。逆に言えば、配信側でMIMEタイプの設定を誤っていた場合、再試行のたびに同じ失敗を繰り返すことになるので、サーバー設定の見直しは引き続き大切です。

その5 開発者ツールの表示サイズが端数まで出るように

Firefox 156の開発者ツールでは、インスペクターで要素を選んだときに出るビューポートの幅と高さが、四捨五入されずに表示されるようになりました。ブラウザの拡大率が中途半端なときや高精細なディスプレイでは、これまでの表示が実際と食い違っていたためです。

レスポンシブデザインの切り替え幅を確かめる際、境界ぎりぎりで表示が崩れる原因を追うときに小数点以下の値が見えるのは助かります。制作中に表示される数字が以前と違って見えても、不具合ではなく正確になった結果と受け止めてよいでしょう。

どれも派手な変更ではありませんが、何年も前に納品したサイトほど影響を受けやすい種類の話です。隔週で更新が届く時代になり、こうした細かな挙動の変化は今後も積み重なっていきます。新機能を追いかけるのと同じくらい、既存のサイトに何が起きうるかを定期的に拾っておくことが、運用を任される側の地道な仕事になりそうです。

Safariの新版が前面に出したのは不具合修正だった

つくば市のホームページ制作会社

WebKitのブログに、Safariの新しいバージョンで入った変更をまとめた記事が出た。日付は9月17日。冒頭に置かれているのは新機能の一覧ではなく、今回いちばん大きな機能は機能ではない、という一文だった。1年かけて既存機能の不具合を844件直した、という話が中心に据えられている。6月の開発者向けイベントの時点では525件と発表していたので、そこからさらに6割ほど積み増したことになる。

修正はいくつかの筋に整理されている。ひとつは互換性で、特定のサイトでヒンディー語の入力が正しく通らない、検索結果から画像が消える、といった個別の不具合を地道に潰していったもの。もうひとつは土台の作り直しで、JavaScriptのモジュール読み込み処理を新しく書き直し、CSSのzoomも作り直し、行内要素の配置をサブピクセル単位で行うようにしたという。深掘りの筋ではSVGだけで66件の修正が入り、SMILアニメーションの実装は端から端まで見直された。表組みの絶対配置まわりや、HTTPキャッシュがCache-Controlの指定にきちんと従うかどうかといった、仕様との食い違いを詰める作業も含まれている。

目を引いたのは、組み合わせという括りがあることだ。-webkit-line-clampがWebKitに入ったのは2010年、text-wrap: balanceは2024年で、どちらも単体では問題なく動く。ところが同じ要素に両方を指定すると、行のバランス調整のほうが効かなくなっていたという。それが今回直った。単体では再現せず、組み合わせたときだけ崩れる。制作の現場で原因の切り分けにいちばん時間を取られるのは、だいたいこの種類の不具合ではないだろうか。

読んでいる位置が飛ばなくなる

新しく入った機能のなかで、既存のサイトにそのまま効きそうなのがスクロールアンカリングだ。記事を読んでいる途中で、いま見ている位置より上に画像や広告、コメントが遅れて読み込まれると、読んでいた部分が下に押し出されて画面が急に飛ぶ。よくある挙動だが、読み手にとっては行き先を見失う原因になる。新しいSafariはこの場合にスクロール位置のほうを自動で調整し、読んでいた場所を画面上の同じところに保つ。制作側で何かを書き足す必要はなく、既定で有効になっている。挙動を切りたい箇所だけ、overflow-anchorというCSSプロパティにnoneを指定する形だ。

ブラウザの更新というと、新しい書き方が使えるようになったかどうかに目が行きやすい。ただ、納品してしばらく経ったサイトの表示が、こちらが何もしなくても静かに正しくなっていくというのは、保守を抱える側にとっては地味に大きい。Safariでだけ表示が少しずれるという理由で回避策を入れた案件が手元にあるなら、新しい版で一度素の状態に戻して確かめてみる価値はある。回避策は放っておくと、いつのまにか誰も理由を説明できないコードになる。

ブラウザごとの食い違いを来年の課題にする公募が始まった

つくば市のホームページ制作会社

同じHTMLとCSSを書いても、ブラウザによって表示や挙動が少しずつ違う。制作の現場では当たり前のように受け入れている面倒だが、その差を毎年少しずつ埋めていく共同プロジェクトがある。Interopと呼ばれる取り組みで、ブラウザを作っている各社が参加し、年ごとに重点分野を決めて、各ブラウザの対応状況をテストの合格率で追いかけていく。

その来年ぶんの題材を決める提案の受付が、9月3日に始まった。締切は9月23日で、GitHubのissueとして誰でも出せる。同じ日にAppleのWebKit、Googleのweb.dev、MicrosoftのEdgeチームがそれぞれ呼びかけを出していて、どんな書き方が通りやすいかの説明も添えられている。読み比べると、重なっている勘所がいくつか見えてくる。

すでに標準として固まっているか

前提として、Interopは新しい技術を発明する場ではない。W3CやTC39といった場で仕様が固まり、ブラウザベンダーからの異論が残っていないものについて、実装の食い違いだけを潰していく。過去に選ばれた機能は、少なくともどれか一つのブラウザで実装済みだったものがほとんどだとされている。

WebKitの記事は、まだ存在しない機能がほしい場合はInteropではなく、CSSであればCSS Working Groupのissueなど、その技術を決める場に持ち込むよう案内している。順番を飛ばすと、そもそも土俵に乗らないという整理だ。

テストがあるかどうかで枠が変わる

Interopの進み具合は、Web Platform Testsの合格率で測られる。裏を返すと、テストが十分にない機能は、選ばれても点の付けようがない。提案するときは、既存のテストがどれくらいあるかを調べてリンクすることが求められる。

テストや計測の仕組みが足りない領域には、重点分野とは別に調査枠が用意されている。こちらは合格率を競うのではなく、将来の改善に向けて土台を整えるための宿題という位置づけになっている。出したい機能の成熟度によって、入り口が二つあるということになる。

範囲は狭く、具体的に

三社とも揃って書いているのが、提案の範囲を絞ることだ。WebKitは「タイポグラフィ」ではなくfont-size-adjustのように、一つの機能か、関係の近い小さなまとまりで出すよう勧めている。Edgeの記事も、「CSSを良くしてほしい」「フォームまわりを直してほしい」といった広い要望は評価しづらく、焦点の定まった提案のほうが選ばれやすいとしている。

実際に困った場面を書けるか

説得材料として重視されているのは、現場でどう困ったかという具体的な話だ。自分の案件で遭遇した食い違い、フレームワークやライブラリのissue、開発者アンケートの結果など、多くの人が同じ壁に当たっている証拠があると強い。

探す手がかりも用意されている。webstatus.devで各ブラウザの対応状況を確認したり、開発者からの要望を集めたリポジトリで、すでに公開されている使いどころを引いてきたりできる。数ある候補の中で、なぜこれを先に片付けるべきなのかまで書けると良いとされている。

提案を出さない人にもできること

提案文を書く時間がなくても、関われる余地はある。同じ内容のissueを二つ立てるより、すでにあるissueにコメントや反応を付けて後押しするほうが良いと、各社とも案内している。気になる提案に賛同の意思を残しておくだけでも、判断材料のひとつになる。

選ばれなかった提案も捨てられるわけではない、という説明も目を引いた。Edgeのチームは、落選した提案は開発者からの明確な要望として受け取り、長く残っている課題を整理したダッシュボードに反映していくと書いている。提案の結果が出るのは来年2月ごろの予定だという。

今年の重点分野には、View Transitions、Navigation API、アンカー位置指定、ダイアログとポップオーバー、コンテナスタイルクエリなどが並んでいる。こうした機能を数年後に「もうどのブラウザでも普通に動く」と言えるかどうかは、この時期の公募から始まっている。中小企業のサイトを作る側としても、いま回避策を書き足している場所を思い出しておくと、来年以降の道具立ての変わり方が少し読みやすくなる。

公式ドキュメントのコード例がその場で動くようになった

つくば市のホームページ制作会社

WordPressの公式ドキュメントであるCode Referenceで、掲載されているコード例をその場で実行できるようになった。9月上旬にMake WordPress Coreで告知されたもので、WordPress 7.1で最初の2件が公開され、7.2でさらに増える予定とされている。

対象になっているのは、たとえば WP_HTML_Processor::class_list() の解説ページだ。コードブロックに付いた実行ボタンを押すと、そのページの中で結果が表示される。ローカル環境を立ち上げたり、どこかにコピーして貼り付けたりする手間がいらない。ドキュメントを読みながら挙動を確かめられる、という形になった。

実行できるコード例は本体のコメントから作られる

興味深いのは、この実行できるコード例が、ドキュメント用に別途手作りされているわけではないところだ。WordPress本体のソースコードにあるDocBlock、つまり関数やメソッドの上に書かれているコメントの中に、そのまま書かれている。

通常のコード例との違いは、コードフェンスの言語指定を php interactive と書くことだけだという。書き方の詳細をまとめたハンドブックのページも、追って公開されるとされている。

ドキュメントとコードが離れた場所で管理されていると、更新のタイミングがずれて片方だけが古くなる。本体のコメントに書いておけば、コードを直した人が同じ場所で例も直せる。地味な話に見えるが、説明を長く正しい状態に保つうえでは効いてくる作りだ。

ブラウザの中でPHPを動かす仕組みが土台にある

実行を支えているのはWordPress Playgroundだ。もともとはブラウザの中でWordPress一式を動かすための仕組みで、WebAssemblyに移植したPHPが土台になっている。

この春に公開されたPlayground側の解説によると、<php-snippet> というカスタム要素が追加され、スクリプトタグをひとつ読み込むだけで、任意のウェブページに実行できるPHPの例を置けるようになったという。読者が実行ボタンを初めて押したときに、隠しiframeの中でPHPが読み込まれて動く仕組みで、ページを開いただけでは重い処理は走らない。

同じページに例が複数あるときは、条件が一致していれば同じ実行環境を使い回す。チュートリアルにサンプルをいくつも並べても、そのたびにPHP環境を立ち上げ直すことにはならないわけだ。既定のPHPバージョンは8.4、WordPressは最新版で、属性で指定すれば例ごとに変えられる。WordPressを読み込まず、PHPの言語機能だけを試す指定も用意されている。

自分たちのドキュメントに埋め込むこともできる

この仕組みはWordPress公式サイト専用の機能ではなく、外部のページでも使える。スクリプトを読み込み、要素の中にPHPを置くだけだ。実行前に想定される出力を先に表示しておく指定や、コードを別ファイルから読み込む指定、実行させずに色付け表示だけにする指定などもある。

Blueprintという設定用のJSONを併用すれば、実行前にmu-pluginを置いたり、オプションを設定したり、サンプルの投稿を用意したりといった下準備もできる。複数の例で同じBlueprintを共有すれば、環境を一度だけ用意して順に実行させられる。

導入時の注意点も挙げられている。Content Security Policyを厳しく設定しているサイトでは、Playground側から配信されるスクリプトと隠しiframe、そこから読み込まれる各種ファイルを許可する必要がある。それが難しい環境では、スクリプトを自前で配信して参照先を切り替える方法も案内されている。うまく動かないときは、開発者ツールで失敗している通信を確認するのが早い。

手元に環境がない相手に説明するときに効く

制作会社の立場で考えると、使いどころは社外向けの説明だろう。クライアントや外部の協力者に「この関数はこう動く」と伝えたいとき、手順書を書いてローカル環境の構築から始めてもらうのは相手の負担が大きい。動くものをページに置いておけば、読む側は押して確かめるだけで済む。

自社の技術メモや、配布しているプラグインの説明ページに、短いサンプルを実際に動かせる形で残しておくのも現実的だ。文章で説明した挙動と実際の出力が食い違っていないか、書いた側が自分で確かめられる点も含めて、書く手間に見合うものはありそうに思える。

納品したデザインを崩されない仕組みがテーマ側に増えた

つくば市のホームページ制作会社

WordPressのブロック開発まわりの月次まとめが公開されていて、9月分にはテーマを書く側や制作会社の実務に効きそうな変更がいくつか入っていた。派手な新機能というより、納品したあとのサイトをどう保つかに関わる調整が多い。

背景として、8月に出たWordPress 7.1では、ホバーやフォーカスといった状態のスタイルと、画面幅ごとのスタイルを管理画面から指定できるようになった。CSSを書かずに見た目を触れる範囲が広がったわけだが、これは同時に、制作側が整えたデザインを運用側が意図せず崩せる範囲も広がったということでもある。

状態スタイルの編集をテーマ側で閉じられる

Gutenberg 23.8で、ブロックの状態スタイル編集と、画面幅ごとの編集のそれぞれにオプトアウトの設定が追加された。blockStatesEditingEnabledとresponsiveEditingEnabledの2つで、どちらも既定は有効、block_editor_settings_allフィルターからfalseにできる。

使えると感じたのは、無効にしても表示が壊れない点だ。theme.jsonやグローバルスタイル、ブロックのstyle属性ですでに定義してあるスタイルは、どちらの設定でもそのまま出力される。編集画面から触れなくなるだけなので、作り込んだデザインを保ったまま運用担当者に渡せる。サイトを納品して、その後の更新はお客様側で、という進め方をしている案件では出番がありそうだ。

運用者が見る画面まわりでは、投稿の編集画面とウィジェット編集画面が、管理画面で選んだ配色を引き継ぐようになった。あわせてgetAdminThemeColors()が公開の関数として使えるようになっていて、管理画面の本文クラスから配色を読み取り、主要色と背景色を返す。独自の管理画面を追加しているプラグインでも、同じ二行の囲みを入れておけば利用者が選んだ配色に合う。細かい話ではあるが、追加した画面だけ色が違うという座りの悪さは減らせる。

グローバルスタイルで扱える要素が広がった

Gutenberg 23.9では、theme.jsonの要素スタイルにlabelが加わった。styles.elements.labelで指定でき、label要素を出力するマークアップ全般に効く。コアでは検索、フォーム入力、コメントフォーム、アーカイブ、カテゴリーの各ブロックが対象で、サードパーティ製のブロックにも適用される。

引用元表示のcite、テキスト入力、セレクトの3つは、以前からtheme.jsonでは指定できたものの、エディター上のスタイル画面からは触れなかった。これがタイポグラフィと色のパネルから編集できるようになっている。グループブロックはブロック間隔の対応を縦横それぞれに宣言するようになり、theme.json側では文字列だけでなくtopとleftを持つオブジェクトも受け取る。リストブロックの幅広と全幅、クエリーループのブロック間隔といった細かい対応追加も入った。

theme.jsonが無効扱いされる場面が減る

7.1で入った状態スタイルは、記述を検証するスキーマのほうが追いついていなかった。Gutenberg 23.8では、スタイルバリエーション向けの状態、状態が要素ではなくブロックに固有である点、擬似クラス指定の誤りといった箇所に修正が入っている。コードエディターでtheme.jsonを開いたときに、正しい記述が無効として警告される場面が減るという話だ。地味な変更だが、テーマを書いている時間にはそのまま効いてくる。

公式ドキュメントの例をその場で動かせる

もうひとつ、開発者向けリファレンスに載っているコード例が、ブラウザ上で実行できるようになった。関数のページで実行ボタンを押すと、Playgroundで動く本物のWordPressに対してスニペットが走る。例はDocBlockの中にphp interactiveという名前のコードフェンスで書かれていて、ドキュメントと関数の定義が同じファイルに並ぶ形になっている。挙動を確かめるために手元へ環境を作らなくてよくなる分、調べ物の往復は短くなるはずだ。

次のWordPress 7.2は、ベータ版が10月下旬、正式版が12月上旬の予定とされている。独自ブロックを持っている場合、内部ブロックのテンプレート指定がInnerBlocksのプロパティからブロックタイプの設定へ移り、従来の書き方は非推奨になった点は早めに手を入れておきたい。複数人が同時に編集する機能への対応が理由とされていて、今後この種の書き換えはもう少し続きそうだ。

WordPressの修正版はこうして準備されている

つくば市のホームページ制作会社

WordPress 7.1が公開されたのは8月19日だった。それからひと月も経たないうちに、次に来る修正版である7.1.1の日程が公表されている。9月2日に出た告知には、バグを仕分ける作業日の日取りから一般公開の予定日までが一覧で並んでいる。大きな更新のニュースは目にしても、その後始末の予定まで公開されていることは意外と知られていない。

修正版の日程は前もって示される

公表された予定では、9月3日と4日、8日、9日、15日にバグの棚卸しにあたる作業日が置かれ、9月10日にリリース候補版、9月17日に7.1.1の一般公開という並びになっている。時刻はいずれも協定世界時での目安で、実際の時間は担当者の都合によって前後する可能性があるとも添えられている。

この予定が出る前、8月20日の時点では「9月1日から24日のあいだ」という幅のある見通ししか示されていなかった。報告されたバグの深刻さと数を見てから時期を決めるという方針があるためだ。公開後に寄せられた報告の量と深刻さから、修正版は習慣的に準備すべきだと判断された、という書き方になっている。幅のある見通しが具体的な日付へ絞り込まれていく過程が、そのまま外から追える状態に置かれている。

入るものと入らないものが決まっている

7.1.1はバグ修正だけの修正版だと明記されている。対象になるのは7.1の開発期間中に持ち込まれた不具合か、7.1の締め切りの時点で意図的に先送りされた項目に限られる。新しい機能はここには入らない。何が候補になっているかは、不具合の追跡システムの一覧や編集画面まわりの作業ボードから追えるようになっている。

7.1は機能の追加が多い版だった。表示まわりでは画面幅ごとの指定が入り、切り替えの基準となる幅をテーマ側で決められるようになっている。投稿の編集画面も枠内で読み込む形に一本化された。触る範囲が広い更新のあとに報告が集まりやすいのは自然なことで、修正版の枠が早めに用意されるのはその裏返しでもある。

目を引くのは、9月8日の作業日に7.1.2の枠を開き、そこで一部の項目を先送りすると最初から告知している点だ。締め切りに間に合わないものは次に回すという判断が、あらかじめ日程に組み込まれている。直すべきものを溜め込まず、期限で区切って次の枠へ送る。規模の小さい制作現場の案件管理にも、そのまま持ち込める考え方だと思う。

少人数で回っている工程

大型更新の体制と比べると、修正版のチームはかなり小さい。担当者は1人から3人程度になることが多いと説明されている。仕事の中身は、コミッターや各機能の担当と連携してバグを仕分けること、公開のお知らせを書くこと、公開当日の作業を準備して進めること、そして次回のために手順書を更新することとされている。

大型更新に関わった人がそのまま残ることが多いものの、必須ではなく、大型更新の経験がなくても志願できると書かれている。バグの棚卸しは公開された相談部屋で行われ、自分で棚卸しの場を開いてもよいとされている。翻訳が足りていない言語があるという案内も添えられていた。ふだんは使うだけの側から見ると、公開までの手順がここまで読める状態になっていること自体が珍しい。

受け取る側の準備

小さな更新は自動で当たる設定のまま運用しているサイトが多いはずだ。実際、7月17日に出た7.0.2では深刻度の高い問題が含まれていたため、影響を受けるバージョンに対して強制的な更新が実施されている。8月6日の7.0.3では、さらに十数件の修正が入った。放っておいても当たる前提で組まれている以上、現場の役目は「更新するかどうか」ではなく「当たったあとで崩れていないか」を見に行くほうへ寄る。

更新の当たり方はサイトごとに違う。保守を受けている環境では自動更新を止めている場合もあるし、逆に管理する側で一括して当てている場合もある。どちらであっても、修正版が出る日が前もって分かっていれば、確認の予定をその前後に寄せておける。

その意味で、リリース候補版が出る9月10日から一般公開までのおよそ一週間は、手元のプラグインやテーマを新しい版に当てて試せる期間でもある。7.1では、投稿一覧の表で見出しにあたるセルの位置が長年の形から変わるといった、地味ながら影響範囲の広い変更も入っていた。修正版でどこが動くのかを先に眺めておけば、公開後に原因を探して回る時間は減らせる。日々の運用を預かる立場なら、公開日の前後で表示と管理画面を一度通しで確認しておくくらいの構えでちょうどいい。

Chromeの新版が隔週で届く体制に変わる

つくば市のホームページ制作会社

Googleが今年3月に告知していたChromeのリリース間隔の変更が、いよいよ実際の運用に入る。9月8日に安定版として公開されるChrome 153から、新しい版が2週間ごとに届く体制へ切り替わる。2021年から続いてきた4週間ごとの更新サイクルが、ここで半分の長さになる計算だ。

変わるのはベータ版と安定版で、デスクトップ、Android、iOSのすべてが対象になる。開発者が先行して動作を試すDevとCanaryのチャンネルには変更がない。Googleの説明によると、更新が頻繁になる代わりに一回あたりの変更範囲が小さくなるため、公開後に問題が出たときの切り分けがしやすくなるとされている。2023年に導入した週次のセキュリティ更新や、安定版を少し早めに配る仕組みと同じ流れの延長にある調整だという。実際、旧来の予定ではChrome 153の安定版公開は9月22日、次のChrome 154は10月20日だったが、新しい予定ではそれぞれ9月8日と9月22日に前倒しされている。

検証のリズムが変わる

制作の現場でまず効いてくるのは、動作確認のタイミングだろう。ベータ版は安定版の3週間前に出るとされているので、これまで月に一度まとめて追っていたリリースノートの確認は、間隔を詰めて拾う形に変わる。Googleも、サイトやアプリに影響しそうな変更を早めにつかむためにベータ版での検証を勧めている。追いかける先としては、機能の予定が並ぶChrome Statusのロードマップや、ベータ公開のたびに出る解説記事あたりが現実的なところだ。不具合の報告を受けたときに「どの版で試したか」を残しておく習慣も、以前より意味を持つようになりそうだ。ブラウザの版が違うだけで再現しない、という話は今後さらに起きやすくなる。

バージョン番号の刻みが速くなる点も、地味に効いてくる。ユーザーエージェントの数字を条件にした古い分岐や、特定のバージョンを前提にした社内の検証手順書が残っていれば、この機会に洗い出しておきたい。一方で、企業向けに用意されているExtended Stableは8週間のサイクルのまま据え置かれ、Chromebookについても専用の検証を経てから配信する形は変わらないとされている。管理された端末を配っている組織では、更新の速い一般の環境と、ゆっくり進む環境が並走することになる。取引先の社内向け画面やイントラのシステムを預かっているなら、どちらの前提で作られているかを一度確認しておくと、後で食い違いが出にくい。

直前のChrome 152は8月25日の公開で、旧サイクル最後の版になった。日々の制作がいきなり立ち行かなくなる種類の変更ではないが、ブラウザの機能が使えるようになる時期は全体として早まっていく。中小企業のサイトを預かる立場としては、新機能を先回りして追うより、確認の頻度を少し上げておくくらいの構えがちょうどよさそうだ。少人数で回している制作の現場ほど、更新の速さそのものより、気づける仕組みを持っているかどうかで差が出る。

開発者ツールの更新で通信の再送と要素確認が楽になる

つくば市のホームページ制作会社

ブラウザに入っている開発者ツールは、毎日のように開いているわりに、更新内容を追いかける機会の少ない道具です。Chrome 152 に含まれた開発者ツールの更新には、通信の調査まわりを中心に、現場の手数をそのまま減らすものがいくつか入っていました。派手な新機能ではありませんが、知っているかどうかで不具合を追うときの段取りが変わります。

通信を作り直さずに送り直せる

ネットワークパネルの右クリックにあった Replay XHR という項目が Resend に変わりました。名前が変わっただけではなく、対象が XHR に限られなくなり、取得できる通信全般を送り直せるようになっています。標準の通信は fetch の呼び出しに変換されたうえで再送され、その通信がどの実行文脈から出たのか、コンソールのどこが発端だったのかも表示されます。フォーム送信やAPIの応答がおかしいときに、画面の操作を最初からやり直さずに再現できる場面が増えます。

一覧の見え方も整理されました。通信の連番を示す列が先頭に固定され、あとから特定の通信を指し示しやすくなっています。フィルタ欄にドメインやホスト名、ポート番号を入れたときに、同じサイト内の通信が正しく絞り込まれるようになった点も地味に効きます。ペイロードのタブには Base64、16進数、UTF-8 という復号方法の切り替えが加わり、バイナリや圧縮された送信内容の中身も読めるようになりました。クエリやフォームの値は、はじめから復号された状態で表示されます。

先読みの扱いも分かりやすくなりました。その通信が投機的な先読みによって始まったものかどうかを示す列が追加され、右クリックからは、そのまま HTML に貼れる先読み用の link 要素の記述をコピーできます。Early Hints は発信元の列にまとめられました。表示速度の改善を頼まれたときに、いま何が先読みされているかを一覧で確かめられるのは便利です。

要素パネルがカスタム要素と入れ子のCSSに追いついた

ハイフンを含む独自のタグや、組み込み要素を拡張した書き方をしている要素には、DOM ツリー上に目印のバッジが付くようになりました。ブロックエディタやフレームワークが吐き出したマークアップを読むときに、素の HTML との区別が一目で付きます。

入れ子で書かれた CSS の親セレクタにカーソルを合わせると、該当する要素がページ上で強調され、スタイルタブの絞り込みにも反応するようになりました。入れ子の宣言に対する詳細度の説明も出ます。擬似要素まわりも改善され、DOM ツリーで before や after を選ぶと、コンソールの直前選択の変数にその擬似要素が入るので、そのまま JavaScript から確かめられます。text-wrap の値の候補表示や、画像の値を取るプロパティの補完も加わりました。ボックスモデルの図も、スクロールバーが出ている要素の内容領域を正しく計算するようになっています。

調べた結果を外に持ち出しやすくなった

コンソールで表として出力した内容を、Markdown か CSV の形式でそのままクリップボードに写せるようになりました。調査結果を社内の共有ドキュメントや課題管理に貼るまでの手間が減ります。デバッガで停止中にカーソルを合わせて式を評価する動作についても、新しいオブジェクトの生成や動的な読み込み、削除などを含む式は評価されないよう守りが入りました。調べているつもりが状態を書き換えてしまう事故を防ぐ変更です。

アクセシビリティまわりの改善も入っています。アクセシビリティツリーのノードや、その配下のまとまりをテキストとしてコピーできるようになり、要素パネルとアクセシビリティツリーの行き来も右クリックからできるようになりました。暗い配色のときに検索結果の強調が見えにくかった問題も直っています。画像の遅延読み込みを指定しているのに幅と高さの指定がない場合には、警告が出るようになりました。遅延読み込みだけ入れて寸法を書き忘れ、読み込み中に表示がずれるというのはよくある型なので、指摘してもらえるのは助かります。

そのほか、ファイルを開くときに手元の作業ディレクトリのファイルが上位に来るようになった点、保存データの削除まわりの設定が一箇所にまとまった点、回線速度の制限について既定の設定と自作の設定が別の欄に分かれた点なども、細かいながら毎日の操作に効いてきます。

更新の届く間隔そのものも短くなる

こうした改善の届き方も変わります。Chrome は9月8日の安定版から、これまで4週間だった更新の間隔を2週間に縮めます。1回あたりの変更の幅は小さくなる見込みですが、開発者ツールの項目名や場所が以前より短い周期で動くことになります。すぐに追随できない管理環境向けには、8週間ごとの Extended Stable がこれまでどおり用意されます。

中小企業のサイトを預かる保守作業では、不具合の再現と確認にかかる時間がそのまま作業量に響きます。使い慣れた道具ほど更新内容を見落としやすいので、手が空いたときに一度、いつも使っているパネルを開いて何が変わったかを眺めておくと、次に慌てる場面で効いてきます。

外部から預かった記事枠の見られ方が整理された

つくば市のホームページ制作会社

Googleの検索品質チームが8月28日付で、サイトの評判に関するポリシー(site reputation policy)の運用を見直すと公表した。あわせて、スパムポリシーの文書側にも、判断で見る観点が書き足されている。他社から持ち込まれた記事やコンテンツ枠を自社ドメインに載せているサイトにとっては、目を通しておく価値のある更新だと思う。

このポリシーはもともと、信頼を積んだサイトの評価に相乗りする目的で第三者のコンテンツを載せる行為を対象に、2024年に導入されたものだ。今回の文書では、第三者の記事があること自体は問題ではなく、そのサイトが既に持っている評価を当て込んで載せている場合だけが対象になる、と改めて念を押している。通信社の配信記事、フォーラムやコメント欄のような投稿型の場、寄稿やコラムなど編集上の性格を持つもの、そして記事広告のうち読者に直接届けることが目的のものは、対象外として名指しで挙げられた。

人の目で確かめられる観点

興味深いのは、人による確認で何を見るのかが箇条書きで示された点だ。挙がっているのは、見せ方(デザインや組み方、文字まわりが本体と揃っているか)、品質(本体側では出てこない品質の問題がそのページにないか)、書き手の明示(誰が責任を持つのかが書かれているか、それを疑わせる材料がないか)、そして同じ内容がほぼそのまま他のサイトにも載っていないか、の四つ。どれか一つで決まるものではなく、状況に応じて重みが変わるとも添えられている。

具体例も併記されている。提携先と組んだクーポン欄でも、本体から辿れる場所にあり、責任の所在と問い合わせ先が示され、独自の分類や編集の手が入っていれば対応の対象になりにくい。逆に、書き手も担当編集も分からず、本体の各セクションから辿れず、外部の販売サイトと同じ文面をなぞっただけのアフィリエイト記事は、対応の対象になりやすいとされている。判断の軸が、掲載の形式ではなく編集の関与の度合いに置かれていることが読み取れる。

もう一点、8月30日から、このポリシーに基づく手動対策の効き方が欧州経済領域(EEA)の内と外で変わる。域外では従来どおり該当部分の検索結果に影響し、域内では手動対策の影響を適用せず、その区画を本体と切り離して単独で評価する形にするという。欧州委員会との協議を踏まえた措置で、通知はいずれもSearch Console経由で届き、再審査リクエストの窓口も残る。

日本国内のサイトは域外の扱いになるので、実務上の見え方はこれまでと変わらない。ただ、提携先から預かるクーポン欄や、外部の書き手による特集ページを持っているなら、書き手の明記、本体と揃った見せ方、他所と同じ文面の使い回しを避けること、この三点はそのまま点検項目になる。サイトの一角を外部に貸す形の企画は中小企業のサイトでも珍しくないので、運用の担当者と共有しておくと安心だ。

横に長い表で見出しを固定しやすくなるCSSの指定

つくば市のホームページ制作会社

横に長い表を作るとき、見出し行や左端の項目名をどう固定するかで手が止まった経験は多いと思う。Chromeの開発者向けブログに8月20日付で公開された次期版の先行情報によると、その悩みに直接効く変更がブラウザに入る。overflowプロパティで縦と横に別々の値を組み合わせられるようになるというもので、たとえば横はスクロールさせ、縦は切り取り(clip)にする、という書き分けが指定どおりに扱われる。ひとつの軸だけがスクロールする箱、という考え方をCSSの側で素直に表せるようになる。まだ先行版の段階なので、正式版で使えるようになるのはもう少し先になる。

これまでのCSSは、片方の軸にスクロール系の値を指定すると、もう片方も実質的にスクロール可能な箱として扱っていた。clipと書いても内部的にはhiddenへ変換されるため、その中でposition: stickyを使った要素は、思っていたのとは別の箱を基準にして固定される。表の上端と左端の両方を固定したかったのに片方しか張り付かない、という現象の正体はここにあった。公開されている提案文書でも、この扱いが出発点の課題として説明されている。スクロールのたびに位置を計算しなおす回避策もあったが、電池を消費し、保守も面倒で、スクロールが非同期である以上ぴったり合わせるのは難しかったとされている。

表とカルーセルで違いが出る

提案文書が挙げている例は二つある。ひとつは、上に見出し、左に項目名を並べた表を、スマートフォンから縦にも横にも動かして読む場面。表を包む要素にoverflow: scroll clipを書いておけば、どちらのラベルも見えたまま奥まで読み進められる。もうひとつは横並びのカルーセルで、縦方向は見た目の上で隠してあっても、スクリプトからscrollIntoViewを呼んだ拍子に縦へずれてしまうことがある。hiddenは利用者が触れないだけで、スクリプトからは動かせるためだ。しかも利用者の側は手で戻せないので、ずれたままになる。clipを指定した軸は動かないと決められる、という整理になっている。

気をつけたいのは互換性で、以前はoverflow: scroll clipと書いてもscroll hiddenとして解釈されていた。古いコードにこの書き方が残っているサイトでは、見え方が変わる可能性がある。同じ先行版には、斜めに動かしたいのにブラウザが勝手に一方向へ寄せてしまうのを止めるscroll-axis-lockという指定も入っており、スクロールまわりの細かい要望が続けて拾われている印象がある。料金表や仕様一覧のように横へ広がる表は、中小企業のサイトでも珍しくない。JavaScriptで位置を合わせていた部分をそのまま減らせる場面は出てくるはずなので、正式版に降りてくる時期を見ながら、手元の表がどの箱に閉じ込められているかを一度確かめておきたい。