並べた要素のすき間に罫線を引く指定がブラウザに入った

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

グリッドやフレックスで要素を並べたあと、そのすき間に細い線を入れたくなる場面は多い。カード一覧の区切り、料金表の縦線、記事リストの横罫。デザインとしてはごく普通の表現なのに、CSSで素直に書ける指定がなく、制作側が毎回それらしい形に組み立ててきた領域だった。ここへ来て、その部分がブラウザ側で片付きはじめている。

すき間に線を引くために、これまでやってきたこと

いちばん多かったのは、並べた要素そのものに枠線を付ける方法だろう。カードの右側にだけ線を引き、行末の要素は擬似クラスで線を消す。三列で組んだグリッドなら、三の倍数番目を狙って消していく。動くには動くが、列数がブレークポイントごとに変わると、消す対象も一緒に書き換えなければならない。

フレックスで折り返す並びだと事情はもっと厄介になる。何番目で折り返すかは中身の幅次第なので、要素の番号を狙う書き方が成り立たない。仕方なく擬似要素を絶対配置で置いたり、親に背景色を敷いてすき間だけ透かして線に見せたり、要素の背景色との差で線を演出したりしてきた。どれも見た目は作れるが、線の色を変えたいだけの依頼で三箇所直すことになる。

背景色を敷いて線に見せる手も、条件がそろえば見た目はきれいに決まる。ただし親の背景が写真やグラデーションだと途端に成立しないし、余白の値を変えると線の太さまで一緒に動く。ダークモードの切り替えを入れると、線の色ではなく背景色を二重に管理することになり、あとから読む人には何が線で何が下地なのか分かりにくい。

要するに、線を引くための仕掛けが、線とは関係のない場所に散らばっていた。すき間そのものを指定できる手段がなかったからで、これは書き手の工夫が足りないという話ではなかった。

もともと段組みだけのものだった指定が広がった

CSSには以前から column-rule という指定がある。ただしこれは段組みレイアウト専用で、グリッドやフレックスでは効かなかった。線を引く指定は存在するのに、いちばん使いたいレイアウトでは使えない状態が続いていたわけだ。

今回入ったのは、この column-rule をグリッドとフレックスにも広げ、さらに横方向のすき間に線を引く row-rule を新しく用意する、という変更になる。Chromeの開発者向けブログによると、ChromeとEdgeのバージョン149から既定で有効になった。段組み、グリッド、フレックスのいずれでも同じ書き方が通る。

書き味としては枠線の指定とほとんど同じで、太さと線種と色をまとめて渡すだけでいい。要素の何番目かを数える必要はなく、折り返しが増えても減っても、すき間があるところに線が入る。列数をブレークポイントで切り替えても、線の指定はそのままでいい。この一点だけでも、日々のCSSの見通しはかなり変わる。

交差やはみ出しをどこまで決められるか

実際にやってみると気になるのが、細部の扱いだ。縦線と横線が交わるところをどうするか、線をすき間いっぱいまで伸ばすのか少し余らせるのか、中身の入っていない列にまで線を出してしまわないか。この手の判断は、これまで擬似要素の位置調整でごまかしてきた部分でもある。

新しい仕様では、そこにもそれぞれ指定が用意されている。交差点の処理は column-rule-break と row-rule-break、線をどこまで伸ばすかは column-rule-inset と row-rule-inset、空の行や列に線を出すかどうかは column-rule-visibility-items と row-rule-visibility-items が受け持つ。開発者向けの試用段階では伸縮の指定が別の名前だったが、仕様の側に合わせて整理された経緯がある。

加えて、線の太さや色、伸縮の量はアニメーションの対象になる。マウスを載せたときにだけ区切り線をうっすら出す、といった演出が、余計な要素を足さずに書けるということでもある。細かい話に見えるが、ここまで決められるかどうかで、回避策から本当に卒業できるかが分かれる。

使えるブラウザと、いまの構え方

現時点で対応しているのはChromiumを土台にしたブラウザで、SafariとFirefoxはまだ入っていない。ここは正直に見ておいたほうがいい。日本の中小企業サイトだとiOSのSafariの比率が高い案件も珍しくないので、いますぐ全面的に頼れる指定ではない。

ただ、この機能は使えなかったときの壊れ方が穏やかだ。対応していないブラウザでは、すき間に線が出ないだけで、レイアウトそのものは何も崩れない。区切り線が装飾として効いている程度の場面なら、対応済みのブラウザで少し丁寧に見える、という積み増しの使い方ができる。線がないと情報の区切りが読み取れない、という設計になっている場合だけ、従来の手法を残しておけばいい。

従来の手法を残す場合も、両方を無条件に書くと対応済みのブラウザで線が二重になる。対応しているかどうかで書き分ける @supports を挟んでおくと、この衝突は避けられる。新しい指定が使える環境では新しい書き方を、そうでない環境では今までの回避策を、という形にしておけば、数年後にSafariとFirefoxが追いついた時点で、古いほうのかたまりを削るだけで済む。移行の作業を先に用意しておく、という考え方に近い。

未対応のブラウザ向けのポリフィルも開発が進んでいるとされている。ただ、装飾のためにスクリプトを足すのは本末転倒になりやすいので、まずは飾りとして入れて様子を見る、という順番が現実的だと思う。

見た目の細部がCSS側に寄っていく流れ

この変更を単体で見ると、便利なプロパティが増えた、という話で終わる。ただ、ここ一年ほどのCSSの動きを並べると、同じ方向を向いた変更が続いていることに気づく。

たとえば、並んだ要素に少しずつ時間差を付けて動かす書き方は、長らく要素の番号を手で書き並べるか、スクリプト側で遅延を計算するしかなかった。それが、自分が何番目の兄弟かをCSSの中で数えられる関数として一部のブラウザに入りはじめている。枠線の形をもっと自由に扱うための border-shape のような提案も議論が進んでいて、CSS-Tricksあたりでは繰り返し取り上げられている。

共通しているのは、見た目のために増やしていたマークアップやスクリプトを減らす方向だということだ。区切り線のための空の div、時間差のための番号付きクラス、位置合わせのための擬似要素。こうしたものは、書いた本人以外には意図が読み取りにくく、引き継いだ制作者が触りにくい部分でもあった。指定として名前が付くと、少なくとも何をしたかったのかは残る。

受け継いだサイトを触る側から見ると

制作会社としてありがたいのは、新規で作るときの快適さより、あとから触るときの読みやすさのほうかもしれない。他社が作ったサイトを引き継いで直す仕事では、擬似要素で引かれた線の位置が微妙にずれている、といった相談がわりとよくある。中身を追うと、当時の列数を前提にした番号指定が残っていて、その後の改修で列数だけが変わっていた、という筋書きだ。

すき間に線を引く指定が一行で済むなら、こうした置き土産は減っていく。すぐに全部を書き換える必要はないし、動いているものを触るリスクのほうが大きい場面も多い。ただ、次にそのブロックへ手を入れるとき、回避策を継ぎ足すのではなく、素直な指定に置き換えられる選択肢ができたのは小さくない。

新しい指定が出るたびに全部追いかける必要はないと思う。それでも、長く回避策で埋めてきた場所が正面から解決されたときは、覚えておくと後で効いてくる。区切り線はまさにその手の場所だった。

読み込み直さない画面切り替えの速さをChromeが測れるようになった

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

サイトの表示速度を測る指標として、Core Web Vitalsはすっかり定着しました。ところが、この指標には長らく穴があると言われてきました。ページを読み込み直さずに中身だけを差し替える作りのサイトでは、最初の一回しか計測されないという問題です。Chromeの最新版で、この部分をブラウザ側で測る仕組みが正式に使えるようになりました。

Chromeの開発者向け資料によると、Soft Navigations APIと呼ばれるこの機能は、試験運用の期間を経て、2026年7月に公開された版から設定を切り替えずに利用できるようになりました。名前のとおり、ソフトナビゲーション、つまり読み込み直さない画面遷移を計測の対象にするものです。

これまで測れていなかった部分

従来のCore Web Vitalsは、ブラウザがURLを開いて新しい文書を読み込む、いわゆる通常の遷移を前提に設計されています。表示までの時間を示すLCP、レイアウトのずれを示すCLS、操作への反応を示すINPは、どれもそのページが開かれた時点を起点に集計されます。

JavaScriptで画面を組み立てる作りのサイトでは、二画面目以降はURLだけが書き換わり、文書の読み込みは起きません。ブラウザから見れば一枚のページがずっと開かれたままなので、二画面目の表示がどれだけ遅くても、最初の一枚の数字に埋もれてしまいます。逆に、最初の表示さえ速ければ全体が良好に見えてしまうこともありました。計測ツール側で独自に区切りを入れる回避策はありましたが、実装ごとに基準が違い、横に並べて比べられる数字にはなりにくい状態でした。

ブラウザはどこで区切りを判断するのか

新しい仕組みでは、ブラウザ自身が三つの条件をもとに画面の切り替わりを見分けます。利用者の操作がきっかけになっていること、利用者から見えるURLの変化を伴うこと、そしてその結果として実際に画面が描き直されること。この三つがそろったときに、ひとつの区切りとして扱われます。

あくまで推測にもとづく判定なので、公式の説明でも、サイトの作り方によっては拾いすぎたり拾いそこねたりすることがあると断っています。それでも、判定の基準がブラウザ側に統一されたこと自体に意味があります。計測ツールを乗り換えても、同じ考え方で区切られた数字が並ぶからです。

計測する側で増えたもの

開発者から見ると、パフォーマンス情報を受け取る仕組みに新しい種類の記録が追加された形になります。切り替わりそのものを表す記録と、切り替わったあとの主要な描画を表す記録が加わり、既存の各種タイミング情報にも何番目の遷移かを示す値が付くようになりました。これで、ひとつの記録がどの画面のものかを判別できます。

ただし、これらを直接扱うのはそれなりに骨が折れます。読み込み直さない遷移では最初の応答までの時間がゼロとして扱われるなど、通常の遷移とは数字の意味が変わる場面もあるためです。Googleが公開している計測用のライブラリweb-vitalsは、新しい版でこのあたりを内部で吸収するようになっており、URLの対応付けや数値のリセットを任せられます。自前で計測基盤を持っているところ以外は、ライブラリの更新に乗るほうが現実的でしょう。

今すぐ効いてくる話ではない

注意しておきたいのは、この計測結果が検索での評価にそのまま反映されるわけではない点です。実利用者のデータを集めたChrome User Experience Reportにも読み込み直さない遷移の分を加えることは目指されていますが、どのような形で反映されるかは未定とされています。対応もChromium系のブラウザに限られます。つまり現時点では、自分たちで測って改善に使うための道具という位置づけになります。

WordPressで作られた一般的な企業サイトのように、リンクを踏むたびにページを読み込み直す作りであれば、直接の影響はほとんどありません。関わってくるのは、予約や検索の絞り込み、会員向けの管理画面など、画面の一部だけを差し替える作りを取り入れている場合です。最近はView Transitionsのように、通常の遷移でもアプリらしい見せ方ができる手段が増えており、境目は少しずつ曖昧になっています。

数字が見えるようになると、これまで感覚で語られていた二画面目が重いという話を、根拠を持って共有できるようになります。制作側と運用側で改善の優先順位を決めるとき、この差は思ったより大きいはずです。

タブに添えた閉じるボタンを読み上げに伝えるARIAの新しい属性

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

Chromeの安定版151が7月28日に公開された。大型の目玉機能というより細かい追加が並ぶ回だったが、そのなかにaria-actionsという属性が入っていて、これは現場の作り方に素直に馴染みそうだと感じた。ある要素に付き添っている別の操作ボタンの存在を、スクリーンリーダーなどの支援技術に伝えるための指定である。Chromeのリリースノートによると、W3CのARIA仕様に沿った形で実装されたとされている。

想定されている典型例は、タブの見出しに小さく付いている閉じるボタンだ。マウスで操作していれば見えているので迷わないが、キーボードと読み上げでたどっている人には、そのタブに閉じる手段が添えられていること自体が伝わりにくい。メールの一覧行に並ぶアーカイブや削除のボタン、カード型のリストに乗った編集ボタンなども同じ構図になる。主となる要素と、その脇に置かれた操作との関係を機械が読み取る手がかりがなく、支援技術の側から見つけづらいことは、以前から課題として挙げられていた部分だ。近くにボタンが置いてあることは、画面上の距離では明らかでも、読み上げの順番のなかでは伝わらない。結果として、タブ移動を重ねて偶然行き当たるまで存在に気づけない、という状態が起きていた。

既存のマークアップを壊さずに足せる

使い方は他のARIA属性と似ていて、主となる要素から、関連するボタンのidを指すだけでよい。属性を足しても見た目やクリックの挙動は変わらず、対応していないブラウザは単に無視する。既存のコンポーネントに後から付け足す形で試せるので、導入の判断はしやすい。開発者ツール側でも、他のid参照型のARIA属性と同じように、参照先がどの要素を指しているかを確認できるようになっている。W3C側の仕様もほぼ固まっており、Firefoxはすでに対応済み、WebKitは試作の段階と伝えられている。ChromeはまずWindows、Mac、Linuxのデスクトップで有効になり、モバイル向けは後続になるとのことだ。

もっとも、属性を書けばすぐ読み上げが変わるという話ではない。支援技術の側がこの関係をどう利用者に案内するかは、各社の実装がこれから揃っていく段階にある。ただMicrosoftのUI部品群を手がけるチームが早い時期の取り込みに前向きだと伝えられており、部品ライブラリ経由で静かに広まっていく類の機能ではありそうだ。自前でタブやリストのUIを組んでいるなら、仕様の様子を眺めておく価値はある。

中小企業のサイトでも、同じ形はあちこちにある。予約フォームの入力欄に添えたクリアボタン、実績一覧のカードに置いた詳細ボタン、通知バーの右端にある閉じる印。どれも見えている人には自明で、見えていない人には気づきにくい。ARIAは足しすぎるとかえって読み上げを濁らせるので万能ではないが、これまで説明のしようがなかった関係を素直に書ける手段が増えたのは、地味ながらありがたい変化だと思う。

地域ごとの週の始まりや暦をブラウザ標準で引ける仕組み

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

日付まわりの表示は、サイトを作っていればどこかで必ず触ることになります。予約フォームのカレンダー、記事の投稿日、営業日の一覧。一見どれも単純ですが、対象の地域が変わると前提そのものが変わります。週の始まりは日曜なのか月曜なのか、週末はどの曜日にあたるのか、どの暦を併記するのか。こうした知識は、これまでブラウザの外から持ってくるしかありませんでした。

2026年7月、JavaScriptの国際化機能であるIntl.Localeに加わった一連のメソッドが、主要ブラウザすべてで使える状態になりました。web.devの月次まとめによると、Firefox 153が対応したことで、Baselineの「新しく利用可能」に入ったとされています。地味な機能ですが、カレンダー部品を自作したことがある人ほど、ありがたみが分かる種類の追加です。

これまでは辞書を自前で抱えていた

「この地域では週が月曜から始まる」といった知識は、CLDRという国際的なデータベースにまとめられています。ただ、ブラウザからその中身を直接引く手段が長らくなく、カレンダーの見た目を自分で組む場合は、データの一部を写し取ったライブラリを読み込むのが普通でした。週の初日を表す値ひとつのために、数十キロバイトの追加読み込みが発生することも珍しくありません。

Intl自体はかなり前からあり、Intl.DateTimeFormatを使えば日付を地域の書式に整えることはできました。ただしそれは整形済みの文字列が返ってくるだけで、UIを自分で組み立てるために必要な素の情報、たとえば曜日を並べる順番の起点までは取り出せません。今回埋まったのは、ちょうどこの隙間にあたる部分です。

Intl.Localeから引けるようになった情報

書き方は素直で、ロケールを表すオブジェクトを作ってメソッドを呼ぶだけです。new Intl.Locale("ja-JP").getWeekInfo() のように書くと、週の始まりの曜日、週末にあたる曜日、その年の最初の週とみなすための最小日数がまとめて返ってきます。曜日は1が月曜、7が日曜という決まりになっています。

同じ要領で、その地域で使われる暦の一覧を返す getCalendars()、時刻を12時間制と24時間制のどちらで扱うかを返す getHourCycles()、文字を左から右に並べるか右から左に並べるかを返す getTextInfo()、地域に結び付いたタイムゾーンの一覧を返す getTimeZones() が用意されています。ほかに数字の表記体系や並べ替えの規則を返すものもあり、いずれも MDNのIntl.Localeのページに一覧があります。

返ってくるのは配列や小さなオブジェクトなので、そのまま画面に出すというより、自分のUIの初期値として使う性格のものです。

日本語のサイトで効いてくる場面

日本のロケールで getCalendars() を呼ぶと、グレゴリオ暦と和暦の識別子が返ってきます。行政関連の書類を扱うサイトや、年号の併記が求められる申込フォームでは、この結果を起点にIntl.DateTimeFormatへ和暦を指定する、という流れが自然に組めます。和暦を出すかどうかを地域の慣習として扱えるので、判定を自前のif文で書き分けずに済みます。

週の始まりも実務的です。日本語圏では日曜始まり、英国では月曜始まりというように、カレンダーの見た目は地域で割れます。多言語対応のサイトで同じカレンダー部品を使い回すとき、対応表を自分で抱えなくてよくなるのは負担が減るところです。予約カレンダーや営業日の表示は、中小企業のサイトでも決して珍しい要素ではありません。

使う前に確認しておきたいところ

Baselineの「新しく利用可能」は、主要ブラウザの最新版で動くという意味であって、少し前の端末まで含めて安全という意味ではありません。企業サイトの訪問者には更新の止まった端末も混ざりますから、メソッドがあるかどうかを確かめて、無ければ従来どおりの既定値を使う、という組み方が現実的です。値が取れなくても表示が壊れないようにしておけば十分です。

もう一点、以前の実装ではメソッドではなくプロパティとして提供されていた時期があります。古い解説記事のコードをそのまま持ってくると動かないことがあるので、参照する情報の新しさには注意しておきたいところです。

外部ライブラリに頼っていた小さな機能が標準側に移ると、依存パッケージがひとつ減り、更新の手間もその分軽くなります。派手さはありませんが、次にカレンダーまわりを触る機会があれば、置き換えられる部分がないか見ておく価値はありそうです。

日本語を含むメールアドレスへの対応が次期WordPressで見送られた

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

WordPressの次のバージョンにあたる7.1のベータ3が7月22日に公開された。71件を超える修正が入った通常のベータ更新だが、告知の中に少し珍しい一文が混ざっていた。いったんコアに取り込まれていた、アルファベット以外の文字を含むメールアドレスへの対応が、7.1には入らないことになったという内容だ。

対象になっていたのは、@より前のローカル部分に日本語や各国の文字が入ったアドレスである。ドメイン側はPunycodeという変換の仕組みで以前から扱えていたが、ローカル部分は長く対象外で、WordPressの検証関数が不正なアドレスとして弾いていた。今回の変更では、データベースの文字コードがutf8mb4であればis_email()やsanitize_email()が非ASCIIのアドレスを受け付けるようになり、アドレスをローカル部とドメイン部に分けて扱えるWP_Email_Addressというクラスも加わっていた。元になったチケットが立てられたのは2015年で、11年越しで前に進んだ案件でもある。

取り込んだあとで外すという判断

その機能が、コアにマージされてから6週間ほどで外された。挙げられている理由は、Unicodeを受け入れることで確認しなければならない範囲が一気に広がることと、それに伴うセキュリティ面の影響だ。Unicodeには見た目がほとんど区別できない別の文字が数多くあり、ログイン用のアカウントや通知メールの宛先が絡む場所では、取り違えやなりすましの入口になりうる。公式の告知では、開発はコミュニティプラグインとして続け、互換性やセキュリティ、データの扱いをより広くテストしていくとされている。

日本の制作現場への直接の影響は、いまのところ小さい。国内で非ASCIIのメールアドレスを実際に運用している取引先はほとんど見かけないし、7.1に入らないのであれば当面の挙動も変わらない。気に留めておきたいのは、問い合わせフォームや会員登録の入力チェックを自前の正規表現で書いているサイトのほうだ。将来コア側が受け入れる文字の範囲が広がったとき、フォーム側だけが古い基準で弾き続ける、という食い違いが起きうる。プラグインとして先に試せる形になるのであれば、その前に手元で挙動を確かめておける。

もうひとつ、この話が示しているのは、メールアドレスの扱いがWordPress単体で完結しないことだ。仮にコア側が受け付けても、その先の送信サーバーやメール配信サービス、受け取る側のメールソフトがそろって対応していなければ、通知が届かないという形で問題が出る。ウェブ側だけを新しい仕様に合わせても意味がない領域で、慎重に進める判断そのものは理解しやすい。

11年動かなかった機能が入り、6週間で外れる。読んでいて印象に残るのはむしろ判断の速さのほうで、世界中のサイトが乗っている土台に何を入れるかという線引きが、機能の完成度とは別の基準で引かれていることがよく分かる。7.1そのものは8月19日の公開予定で、こちらは通常どおりの日程で進んでいる。

カメラとマイクの許可をブラウザに任せるHTMLの新要素

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

ウェブサイトでカメラやマイクを使う場面は、ここ数年で少しずつ増えてきました。オンライン相談の入口、動画で送るお問い合わせ、現場のスタッフが撮影してそのまま投稿する仕組みなど、業種を問わず出てきます。その手前に必ず挟まるのが、ブラウザが表示する「カメラの使用を許可しますか」という確認です。

Chrome 151が2026年7月28日に公開され、この確認の出し方そのものを見直す新しいHTML要素、usermedia要素が使えるようになりました。JavaScriptから許可を求めるのではなく、ブラウザが仲立ちする部品を押してもらう形に変わります。

スクリプトから許可を求める方式のつまずき

これまでカメラやマイクを使うには、JavaScriptでgetUserMediaという命令を呼び、その瞬間にブラウザが許可の確認を出す形が標準でした。書き方としては素直ですが、実際の現場では困りごとがついて回ります。

ひとつは、確認が出るタイミングを利用者が予想しにくいことです。ページを開いた直後に何の脈絡もなく確認が出れば、多くの人はとりあえず拒否します。もうひとつは、拒否したあとの復帰が難しいことです。いったん拒否すると次からは確認すら出ず、ブラウザの設定画面を自力で開いて権限を戻す必要があります。制作側からは、その設定画面への案内文を書き添えるくらいしか打つ手がありませんでした。

迷惑な確認を減らすため、ブラウザ側が自動的に確認を抑え込む挙動も広がっています。まっとうに作ったページが、その網に引っかかって何も起きないという事故も起こり得ます。

ボタンを包むだけの書き方

usermedia要素は、押してもらうボタンをこの要素で包むだけで使えます。中に置いたボタンの見た目はこれまでどおり自由に整えられ、押されたあとの段取りをブラウザが引き受けます。

結果の受け取りは、要素が発火する3種類の出来事を見張る形です。許可されたときのstream、失敗したときのerror、利用者が確認を閉じたときのcancelの3つで、映像や音声の本体はstreamから受け取ります。解像度やエコー除去といった希望は、押される前にsetConstraintsで指定しておきます。従来の書き方で必要だった成功と失敗の分岐や状態管理のコードは、かなり減らせます。

目に見えて変わるのは、確認が出る条件です。従来はスクリプトの都合で確認を出せましたが、この要素ではブラウザが用意した部品が実際に押されるまで確認は出ません。裏を返せば、勝手なタイミングで確認を出す作りが成立しなくなるということでもあり、利用者側から見た予測しやすさは上がります。

拒否されたあとに戻ってこられるかどうか

この要素の効き目がはっきり出ているのが、一度拒否されたあとの復帰です。Chromeの開発者向け情報によると、試験導入に参加したCiscoの計測では、従来の方式で復帰できた人がおよそ1割だったのに対し、新しい要素では6割を超えたとされています。Zoomでは撮影や録音の失敗が約47パーセント減り、Google Meetでは「マイクが動かない」という申告が約17パーセント減ったという数字も挙がっています。

理由は単純で、利用者が自分でボタンを押したという事実をブラウザが確実に把握できるからです。押した本人の意思がはっきりしているぶん、ブラウザは自動的な抑制を回さずに済み、拒否済みの状態からその場で復帰させる専用の流れを出せます。設定画面まで手順を案内しなくてよくなるのは、問い合わせ対応の手間という面でも小さくありません。

今すぐ全面的に置き換えるものではない

現時点で動くのはChrome 151以降で、他のブラウザはこれからです。仕様はW3Cのメディアキャプチャ拡張仕様に載っており、将来はカメラ用、マイク用といった用途別の要素も検討されています。

対応しているかどうかは、HTMLUserMediaElementという名前がブラウザ側に存在するかで判定できます。対応していないブラウザでは要素の中に書いた内容がそのまま表示されるので、中に従来のgetUserMediaを呼ぶボタンを置いておけば、ひとつの記述で両方の環境をまかなえます。新規に組むならこの入れ子の形から始めておくと、対応ブラウザが増えたときに書き直さずに済みます。

カメラやマイクを扱うページは、動くかどうかが問い合わせ件数に直結します。実装の難しさよりも、拒否したまま戻れなくなった利用者をどう救うかが実際の課題だった現場は多いはずで、そこにブラウザ側から手が入ったという意味で、頭の片隅に置いておく価値のある変化です。

Safariの新しい版で使えるようになるフォームと表示まわりの指定

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

Safariの次の版のベータが公開され、58件の新機能と525件の修正が入るとされています。WebKitの発表を読むと、目新しい機能を数多く並べるというより、既存の機能の細かい挙動を揃える作業に重心が置かれているのが分かります。

とはいえ、制作の現場ですぐ効きそうな追加もいくつか含まれています。中小企業のサイトでも出番がありそうなものを、順に並べてみます。

セレクト要素の見た目を組み直せるようになる

フォームのセレクトボックスは、ブラウザごとに見た目が違ううえ、選択肢の並びに手を入れられない部分が長く残っていました。デザインに合わせたい場合、select要素を捨ててdivとJavaScriptで作り直すのが定番の回避策です。

今回のベータではappearance: base-selectに対応し、本来の要素のまま見た目だけを組み直せるようになります。キーボード操作や読み上げ、フォーム送信の挙動は標準のまま残るので、作り直したときに抜けがちな部分を自前で用意しなくて済みます。問い合わせフォームのように、崩れると直接損をする箇所ほど恩恵が大きいところです。

遅れて読み込まれた要素で読む位置がずれない

記事を読んでいる途中で、画面の上のほうにある画像や埋め込みが遅れて表示され、本文が下に押し出される。よくある不快な挙動です。スクロールアンカリングは、こうしたときに表示位置を自動で補正して、読んでいた行を保ちます。

他のブラウザではすでに動いていた機能なので、Safariが加わることで挙動の差が縮みます。ただし、画像に幅と高さを書いておくといった基本の対策が不要になるわけではありません。ブラウザ側の補正はあくまで最後の受け皿と考えておくのが安全です。

見出しをまとめて指定できる疑似クラス

:headingは、h1からh6までをまとめて指す疑似クラスです。これまではセレクタに六つ並べて書くのが普通で、余白や行間を揃えたいだけの場面では冗長でした。

書く量が減るだけの小さな追加に見えますが、見出しの階層が増えたり減ったりする構成では、書き漏らしを防ぐ意味もあります。ブログのように書き手が複数いるサイトでは、想定していなかった深さの見出しが入ることも珍しくありません。

余白まで含めて幅を伸ばすstretchという値

幅や高さの指定にstretchという値が使えるようになります。親の中で余白の分まで含めて伸ばす指定で、これまでcalcを使って余白を引いて調整していた場面を素直に書けます。

あわせてrevert-ruleというキーワードも入りました。そのルールが当たる前の状態まで戻す指定で、後から足したCSSが積み重なって入り組んだサイトの調整に向きます。どちらも派手さはありませんが、既存サイトに手を入れる仕事では出番がありそうです。

画像のsizes属性をブラウザに計算させる

遅延読み込みを指定した画像で、sizes属性にautoと書けるようになります。実際のレイアウト幅をブラウザが測り、srcsetに並べた候補から適したものを選びます。

これまでは画面幅ごとの表示幅を自分で書き並べる必要があり、レイアウトを変えるたびに書き直す手間がありました。書いた値が実際のレイアウトと食い違うと、必要以上に大きい画像を読み込んでしまいます。手作業の当て推量が減るのは、表示速度の面でも助かります。

同じ時期に出たChromeの新しい安定版には、矢印キーでの項目移動を属性の指定だけで有効にできるfocusgroupが入っています。片方は新しい書き方を先に出し、片方は既存の機能の足並みを揃える。方向は違いますが、どちらも自前のスクリプトで埋めていた部分を標準側に寄せる動きです。実務では、対応が片方だけの機能はしばらく補助的に添える程度にとどめ、両方に入ったものから本番へ回すのが無難だと思います。

JavaScriptで組んでいた部品がHTML側に移りつつある

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

ウェブ制作の現場で長く続いてきた作業のひとつが、ブラウザに足りない機能をJavaScriptで補うことでした。開閉するパネル、画面全体に出るダイアログ、装飾された選択メニュー。本来はただの部品なのに、ライブラリを読み込み、初期化のコードを書き、キーボード操作や読み上げの面倒まで見て、数年後の保守で頭を抱える。制作に関わっていれば、たいてい心当たりのある流れだと思います。

ここ数年、その前提が少しずつ変わってきています。7月28日に安定版が出たChromeの最新版の変更点を眺めると、方向がかなりはっきり見えます。カメラとマイクの扱い、Shadow DOMの組み立て、画面切り替えの計測。どれもこれまではJavaScriptの領分だったものが、HTMLの要素や属性、あるいはブラウザ標準の計測項目として整理されつつあります。今回はこの流れを、直近のブラウザ各社の動きと並べて眺めてみます。

カメラとマイクの入口がHTMLの要素になる

目を引くのは usermedia という新しい要素です。ブラウザが用意した操作部品として画面に置かれ、そこからカメラやマイクの利用が始まります。Chromeの開発者向けブログによると、利用者の意図をはっきりさせた上で許可を求め、映像や音声のストリームを受け取るところまでを、この要素が受け持つとされています。

従来はJavaScriptから取得用の関数を呼ぶと、いきなりブラウザの許可ダイアログが出る作りでした。押した覚えのないタイミングで「カメラを使いますか」と聞かれれば、多くの人はまず拒否します。そして一度拒否されると、設定から手で戻してもらうしかない。許可の取りこぼしは技術の問題ではなく導線の設計の問題で、その導線をブラウザ側に寄せるという判断は理にかなっています。

使いどころとしては、オンライン相談の受付ページ、採用ページで応募者に短い動画を録ってもらう仕組み、業務用の写真アップロードなどが考えられます。ただし現時点ではChromeだけの機能なので、これ抜きでも成立する作りにした上で、対応ブラウザでは体験が良くなる、という積み方が現実的です。

影の中の差し込み口も属性で書ける

同じ版では、template 要素に shadowrootslotassignment という属性が加わりました。Shadow DOMの中で、どの中身をどの差し込み口に入れるかを手動で割り当てる指定です。これまでは JavaScript から Shadow DOM を作るときにオプションで渡すしかなく、スクリプトが動くまで組み立てが完了しませんでした。

地味な変更に見えますが、意味は小さくありません。サーバー側が吐き出したHTMLだけで部品が完成するなら、最初の表示が崩れて後から整うという、あの落ち着かない一瞬が減ります。PHPでHTMLを組み立てるWordPressのような環境とも相性が良く、ブロックやテーマの作り込みで恩恵を受ける場面はありそうです。

見た目の調整からスクリプトが抜けていく

この半年ほどの各ブラウザの更新を並べると、同じ傾向がもっと広い範囲で起きていることが分かります。グリッドやフレックスの隙間に線を引く指定、箱の幅に合わせて文字の大きさを自動調整する指定、入力欄が中身の量に応じて伸縮する指定。最後のものはFirefoxが対応したことで、主要なブラウザエンジンすべてで使える状態になりました。矢印キーでの移動先をまとめて宣言できる属性も加わっています。

どれも、かつては手で書いていた処理です。文字幅を測って収まるまで縮めるコード、入力のたびに高さを再計算するコード、キーボード操作を自前で組み立てるコード。案件ごとにコピーして、少しずつ挙動が違う状態で増えていく類のものでした。それが数行のCSSや属性ひとつに置き換わるなら、書く量が減るだけでなく、動作の説明もしやすくなります。

制作者側の実利は、たぶん「新しい表現ができる」よりも「消せるコードが増える」ところにあります。納品後に触る人が読む量が減るのは、それ自体が品質です。

足並みがそろわない例もある

とはいえ、宣言的に書ける方向へ一直線に進んでいるわけではありません。分かりやすい例が、選択メニューの見た目を自由に整えられる仕組みです。Chromeでは去年のうちに安定版に入り、Safariは開発者向けの先行版で確認できる段階、Firefoxは試験版でフラグを立てて試す段階。MDNの解説でも、広く使われるブラウザの一部で動かないため安定して使える状態には達していない、という位置づけになっています。

ブラウザごとの歩幅の違いも、この7月にそのまま表れました。Chromeが新しい要素を入れた前日にはSafariの更新版が出ていますが、こちらはWebAssemblyまわりの小さな追加と、CSSや通信の不具合修正が中心です。文字の大きさの単位が拡大表示でずれる問題や、要素の配置指定が意図した位置に戻らない問題が直されています。新機能を並べる回もあれば、土台を固める回もある、というだけの話ですが、対応状況を「だいたい揃った」で済ませられない理由ではあります。

ブラウザ間の差を埋める取り組みとしては、Apple、Google、Igalia、Microsoft、Mozillaが共同で進めるInterop(相互運用性)のプロジェクトがあります。今年の重点領域は二十近く挙げられており、テストの通過率がダッシュボードで公開されているので、気になる機能の足並みを自分で確かめられます。営業資料に「最新の書き方に対応」と書く前に、こういう一次情報で裏を取る癖をつけておくと安全です。

体感速度の測り方も追いついてきた

もうひとつ、Chromeの最新版には計測まわりの追加があります。画面を読み込み直さずに表示を切り替える作りで、その切り替えを一区切りとして扱い、操作をきっかけに描かれた主要な内容が出るまでを測れるようになりました。

これは長く空いていた穴です。表示速度の指標は最初の一画面に強い一方、その後の画面遷移は測りにくく、「最初は速いのに使い始めると重い」という感想を数字で示せませんでした。予約フォーム、商品の絞り込み、地図の切り替えなど、中小企業のサイトでも読み込みを挟まず描き替える作りは増えています。改善の順番を決めるときに、体感に近い数字が手元にあるかどうかは大きな差になります。

もっとも、指標が増えれば追う手間も増えます。全部を見るのではなく、その画面で一番使われる操作をひとつ決めて、その前後だけ測るくらいでも十分に判断材料になります。

どこから取り入れるか

実務での見極めは、三つに分けて考えると迷いません。まず、主要なブラウザすべてで使える状態になったものは、素直に置き換えの候補にできます。入力欄の伸縮や要素同士を結びつける配置指定はこの段階です。次に、特定のブラウザだけで動くものは、無くても成立する上乗せとして扱う。カメラの新しい要素は今のところここに入ります。最後に、置き換えによって読み込んでいるライブラリやプラグインを一つ減らせるかどうかを見る。減らせるなら優先度は上がります。

この最後の観点が、長く運用するサイトでは一番効きます。数年前に選んだライブラリの更新が止まり、依存関係の警告だけが増えていくという話は珍しくありません。ブラウザに入った機能は簡単には消えないので、同じことができるなら標準の側に寄せておくほうが、後々の手間は少なくて済みます。

新機能の一覧を追いかけるのは楽しい作業ですが、実利という意味では逆向きの棚卸しのほうが効くのかもしれません。いま抱えているJavaScriptのうち、どれがすでにHTMLやCSSで書けるようになっているのか。手元の案件をひとつ開いて、読み込んでいるファイルを上から見ていくだけでも、消せる候補はいくつか見つかるはずです。

ふりがなが隣の文字に重なるのを抑えるCSSの新しい指定

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

日本語のページを組んでいると、ふりがな、つまりルビの扱いで地味に手を取られることがある。難読の地名や人名に読みを添えたい、子ども向けや自治体のページで漢字に読みを振りたい、といった要望は今も普通に出てくる。HTMLにはもともと ruby 要素があり、<ruby>石動<rt>いするぎ</rt></ruby> のように書けば親字の上に読みが乗る。ところが実際に組んでみると、読みのほうが親字より長いときの見え方がブラウザまかせになりがちで、そこを細かく指定する手段が長らく足りていなかった。Chromeのベータ版に入った新しいCSSプロパティは、その足りなかった部分をひとつ埋めるものになっている。

ルビは日本語サイトの地味な難所

ルビの厄介さは、親字と読みの長さが一致しないところにある。二文字の漢字に四文字の読みを振れば、読みの側が横にあふれる。ブラウザはこのあふれた分を隣の文字の上に少しはみ出させて表示することが多い。行がむやみに間延びしないので、組版としてはむしろ自然な処理だ。

問題は、そのはみ出しが常に望ましいとは限らないことだった。隣にリンクや強調が続いていると読みが重なって見えづらくなる。狭いカラムや表のセルの中では、はみ出しのせいで折り返し位置が予想と変わる。逆にはみ出しを一切許さないと、親字と読みの幅を揃えるために文字間が広がり、本文の中でその部分だけ間延びして見える。どちらを選ぶかは文脈次第で、これまではCSSからその判断を伝える標準的な手段がなかった。制作側は文字サイズを下げる、ルビを画像にする、そもそもルビをあきらめるといった回り道をしてきた。

はみ出しの許し方を選べるruby-overhang

Chrome 151のベータで加わったのが ruby-overhang というプロパティで、ルビが隣にはみ出すことを許すかどうかを書き手が指定できる。初期値は auto で、これは従来どおりブラウザの判断ではみ出しを許す振る舞いにあたる。隣にも別のルビが並んでいる場合など、重なると読めなくなる状況では自動的にはみ出さない、といった配慮も仕様に含まれている。

もうひとつの値が spaces で、はみ出してよい相手を空白と約物、つまり句読点やかっこの類に限る。隣が普通の文字なら、はみ出さずにその手前で止まる。Chromeの説明によれば none は spaces の別名として扱われ、はみ出しを完全に禁じた結果として不自然な隙間ができるのを避ける形になっている。この none の解釈は資料によって記述が揃っていない段階なので、実際の見え方は手元で確かめておきたいところだ。

書き方そのものは短い。読みが隣の文字に重なると困る箇所に ruby-overhang: spaces; を当てるだけで、あとはブラウザが処理してくれる。JavaScriptで文字幅を測って調整する、といった作業はいらない。

位置や揃え方を決める指定との組み合わせ

ルビまわりのCSSは、これが最初というわけではない。読みを親字の上に置くか下に置くかを決める ruby-position、親字に対して読みをどう割り付けるかを決める ruby-align は以前から使える。縦書きで読みを右側に出したい、読みを親字の幅いっぱいに散らしたい、といった調整はこれらが受け持つ。

今回の指定は、そこに「隣との境界をどう扱うか」という軸を足すものだと考えるとわかりやすい。位置と揃え方を決めたうえで、あふれた分を外に出してよいかどうかを別に決められる。組み合わせると、たとえば見出しの中のルビははみ出しを許して行の高さを保ち、本文の狭い箇所でははみ出しを止める、といった使い分けができる。

現時点で試すときの構え

ruby-overhang は主要ブラウザすべてに揃った状態ではなく、Baselineの対象にもなっていない。Chromeでもまだ安定版ではなくベータの段階にある。今すぐ本番の見た目を左右する前提で組むものではない、というのが正直なところだ。

とはいえ、対応していないブラウザではこの指定が無視されるだけで、ルビ自体は従来どおり表示される。壊れるのではなく、これまでの見え方に戻るだけなので、段階的に足していける類の機能になる。ルビを多用しているページがあるなら、対応済みのブラウザで spaces を当てたときにどう変わるかを一度見ておくと、将来の判断が早くなる。

中小企業のサイトでルビが主役になる場面は多くないが、社名や商品名の読み、地域名、業界特有の用語など、読みを添えたい単語は意外とある。読みを振ると崩れるから避ける、という選択をしてきた現場ほど、こうした指定が揃ってきたことの意味は大きい。日本語の組版に関わる指定がウェブ標準の側で少しずつ整っていくのは、地味だが歓迎したい流れだ。

SNSや動画の投稿の検索での見え方をSearch Consoleで追える

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

Googleが今月、Search Consoleに「プラットフォームプロパティ」という新しい種類のプロパティを追加したと公式ブログで発表した。InstagramやTikTok、X、YouTubeに投稿したコンテンツが、Google検索やDiscoverでどのように表示され、どんな検索語句から人が来ているのかを、Search Consoleの画面の中で確認できるようになるというもの。すぐに全員が使えるわけではなく、数週間かけて段階的に開放されると案内されている。

これまでのSearch Consoleは、ドメインやURLの所有権を確認したうえで使うツールだった。自分で管理していないSNS上の投稿は、検索結果に出ていたとしても計測する手段がなく、実質的に見えない領域として残っていた。今回のプラットフォームプロパティは、サイトを持っていなくてもアカウントを連携するだけで登録できる点が従来と大きく違う。プロパティを追加する操作自体は既存の流れと同じで、追加画面から対象のサービスを選び、連携を承認していく形になる。

用意されているレポート

見られるのはパフォーマンスとインサイトの二種類のレポートとされている。パフォーマンスのほうは、クリック数や表示回数といったおなじみの数字に加えて、どの投稿とどの検索語句が実際の流入につながっているかを絞り込んで確認できる。インサイトのほうは、直近の傾向や反応の良かった投稿、検索から自分のアカウントがどう見つけられているかを大づかみに把握するための画面という位置づけになっている。ウェブサイトのプロパティで見慣れている画面構成にかなり近いので、普段からSearch Consoleを開いている人なら戸惑うところは少なそうだ。サイトを持たずに発信している人にも数字が届くようにしたい、という意図が説明されている。

気をつけたいのは、ここに出てくるのはあくまでGoogle検索とDiscover経由の数字で、各サービスのアプリの中で見られた分は含まれないという点。SNSの管理画面が出す数字とは母数がまったく違うので、単純に足したり、どちらが正しいかを比べたりするような使い方には向かない。あくまで検索という入口からの流入を見るための道具として、別枠で扱うのが無難だと思う。連携そのものも各サービスの認証を通す形になるので、誰のアカウントを誰が繋ぐのか、社内で運用担当が分かれている場合は先に決めておいたほうがあとで混乱しない。

中小企業のサイト運営という視点で見ると、これは「SNSは検索とは別のもの」という前提を少し見直す材料になりそうだ。店名やサービス名で検索したときに、自社サイトより先にSNSの投稿が並んでいるケースは珍しくない。どの投稿がどの語句で拾われているのかが分かれば、サイト側でどんな情報を厚くすべきかの判断もしやすくなる。連携できるアカウントを運用しているなら、自分のところに機能が届いたタイミングで一度のぞいてみる価値はあると思う。