横に長い表で見出しを固定しやすくなる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で位置を合わせていた部分をそのまま減らせる場面は出てくるはずなので、正式版に降りてくる時期を見ながら、手元の表がどの箱に閉じ込められているかを一度確かめておきたい。

プラグインを配る側に求められる脆弱性報告の手順

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

プラグインやテーマは「使うもの」で、「作って配るもの」ではない。制作の現場ではそういう感覚が普通かもしれません。ただ、案件ごとに小さな自作プラグインを納品したり、テーマを配ったりしている会社は少なくないはずです。欧州連合で動き始めた新しい規則は、そうした立場の人にも関わってきます。

Cyber Resilience Act(サイバーレジリエンス法、CRA)という規則です。欧州委員会の説明によると、2024年12月10日に発効し、主な義務は2027年12月11日から適用されます。そして脆弱性などの報告義務については、それより早い2026年9月11日から適用が始まります。先に動き出すのは報告の部分だ、という順番になっています。

先に始まるのは報告のほう

CRAは、ネットワークにつながるハードウェアとソフトウェア全般を対象に、計画・設計・開発・保守の各段階で安全性を確保することを製造者に求める規則です。欧州委員会は、製品を出したら終わりではなく、製品の寿命が続くあいだ脆弱性を扱い続けることも要件に含まれると説明しています。要件を満たした製品にはCEマークが付き、各国の市場監視当局が運用を見ます。

先行して適用される報告義務は、悪用が確認されている脆弱性や重大なインシデントを、決められた期限内に当局へ知らせるというものです。欧州委員会は2026年7月27日に、規模を問わず事業者が義務を果たせるようにするための実務的な手引きを公開しています。読む側にとっては、9月の適用開始前に手順を確かめておくための材料ということになります。

WordPressの世界ではだれが対象になるのか

WordPressサイトの保守サービスを手がけるWP Umbrellaの解説によると、プラグイン作者はCRAの文脈では製造者にあたります。有料版がある、データを扱っている、会社として保守している。そうした商業的な意図があれば、無料で配っていても対象になり得るという整理です。オープンソースだから関係ない、とは言い切れないわけです。

同じ解説は、コードを書かない制作会社も無関係ではないとしています。第三者のプラグインを選んで納品する立場は流通側にあたり、使っている部品の一覧(SBOM、ソフトウェア部品表)がどこにあるか、セキュリティ更新がどう配られているかを把握しておくことが期待されます。EU向けの案件に自作モジュールを納めていれば、それは自社が作った製品という扱いです。

もっとも、WordPressの構造には難しさもあります。WordPress.orgから配布したプラグインの場合、作者は誰が使っているかを知りません。それでも利用者への通知が求められる、という食い違いが残っている。この点は個々の作者が解決できる話ではなく、配布側の仕組みが変わっていく必要がある、というのが同解説の見立てです。

技術的な中身はまだ標準づくりの途中

Help Net Securityが2026年8月14日に伝えたところでは、CRAの技術的な詳細を埋める17本の標準の草案が、いま意見募集にかけられています。法律は「何を達成すべきか」を定めるだけで「どうやるか」までは書かないため、標準化団体がその部分を担う。CRAを担当する部会の議長は、そうした役割分担だと述べています。

示された草案に沿って作れば適合しているとみなされる仕組みで、今回の対象はパスワード管理ソフトやウイルス対策ソフト、スマートホーム機器、つながる玩具など、リスクが高いとされる区分です。意見を出せるのは欧州経済領域の標準化機関を含む41の加盟組織と、消費者や中小企業の立場を代表する四つの団体で、締め切りは分野ごとに9月半ばから11月半ばの間に置かれています。文言がまだ動くうちに意見が入る、という段取りです。

制作の現場で先にできること

日本の制作会社が明日から欧州の当局に何かを届け出る、という話ではありません。ただ、CRAが求めている作業の中身は、EU向けかどうかに関係なく手元の運用を整えるものでもあります。変更履歴を残す。更新にセキュリティ修正が含まれるときはそれとわかるように書く。脆弱性の連絡先をひとつ決めて公開しておく。可能なら機能追加とセキュリティ修正を分けて出す。WP Umbrellaの解説が挙げているのは、そうした地味な項目です。

保守を請け負っている場合は、どのサイトにどのプラグインが入っていて、いつ更新したかを追える状態にしておくことが効いてきます。何年も更新の止まったプラグインを使い続けている案件があれば、そこは規則以前の問題として見直しどころです。欧州の規則という遠い話に見えて、点検の項目自体は、いま抱えている保守案件にそのまま当てはまります。

ルビや余白の指定がSafariの先行版に増えた

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

WebKitが公開しているSafari Technology Previewの最新版に、文字の見え方を細かく決めるCSSの追加がまとまって並んでいた。先行版のリリースノートは地味な項目の羅列になりがちだが、今回は日本語の組版に直接関わるものが混じっていて目に留まった。正式版に入る前の段階とはいえ、どこへ向かっているかは読み取れる。

ひとつはルビの張り出しを扱う ruby-overhang というプロパティだ。ルビは親文字より横に長くなることがあり、既定でははみ出した分が隣の文字に少しかぶる。指定できる値はこれまで、ブラウザの判断に任せる auto と、はみ出しを一切許さない none の二つだった。リリースノートによると、ここに spaces という値のサポートが加わり、張り出してよい相手を隣り合う空白や約物に限る、という中間的な指定ができるようになった。none は spaces の別名という扱いに変わっている。MDNのリファレンスでも、このプロパティの形式的な構文はすでに auto と spaces の二つで書かれていて、仕様側で進んでいた整理が実装に降りてきた形になる。

あわせて white-space-trim も入った。これは white-space を構成するプロパティのひとつで、要素の前後や内側に残る空白を捨てるかどうかを指定する。値は discard-before、discard-after、discard-inner を組み合わせて使う。テンプレートの改行やインデントがそのまま余白として出てしまう場面を、HTMLの書き方を詰めて回避するのではなく、CSS側で処理できるようにするものだ。MDNの white-space のページには、この構成プロパティはまだどのブラウザにも実装されていない、という注記が残っている。先行版に限った話とはいえ、実装が一つ出てきたことになる。

ほかにも、下線の位置をずらせる text-decoration-inset、箇条書きの記号そのものに content を指定できるようになった ::marker、要素の内側での折り返し方を扱う wrap-inside が並んでいる。修正の側にも、::selection に指定した text-decoration が描画されない問題や、直交する書字方向の子要素を持つブロックの幅がつぶれる問題が挙がっている。どれも派手さはないが、縦組みや細かな文字詰めを一度でも触ったことがあれば思い当たる類の話だ。

いま使うというより、頭の隅に置く段階

ここで挙げたものはSafariの先行版に入った段階で、正式版や他のブラウザで使えるかどうかはこれからの話になる。中小企業のサイトで来週から使う、という性質のものではない。ただ、ルビや余白の詰めは、これまで全角スペースの調整やJavaScriptでしのいできた領域でもある。ブラウザ側で素直に扱える方向へ仕様が動いていることを知っておくと、次に組版で困ったときに探す場所が一つ増える。リリースノートは項目ごとに短くまとまっているので、気になる分野だけ拾い読みしておくのでも十分だろう。

スパム対策の更新が終わったあとに確かめたい場所

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

Googleが8月18日に「August 2026 spam update」の展開を始め、2日16時間ほどで完了しました。検索セントラルのランキング更新履歴に記録されているとおり、対象は全言語・全地域です。お盆明けに検索からの流入が少し動いた、という心当たりのある方もいるかもしれません。

スパムアップデートという名前は身構えさせますが、内容はGoogleがすでに公開しているスパムポリシーに沿って、違反を見つける自動システムを調整するものです。新しい違反の種類が増えたわけではありません。とはいえ、ふつうにサイトを運営していても意図せず触れてしまう項目はいくつかあります。公開資料をもとに、確かめておきたい場所を整理してみます。

今年三度目のスパムアップデート

Googleは検索の順位に関わる大きな更新を、ステータスダッシュボードのランキング履歴に記録しています。そこを見ると、今年のスパムアップデートは3月24日、6月24日、そして今回の8月18日で三度目です。コアアップデートのほうは3月27日と5月21日の二回でした。

目を引くのは展開の速さです。今回は2日16時間で完了し、6月の更新も2日1時間でした。11日以上かかった5月のコアアップデートや、26日を超えた昨年8月のスパムアップデートと比べると、明らかに短くなっています。展開が短いということは、順位の動きが出るならすぐ出て、すぐ落ち着くということでもあります。数日ぶんの数字だけで判断を急がないほうがよさそうです。

コアアップデートとは狙いが違う

コアアップデートは検索システム全体の評価の見直しで、違反がなくても順位は動きます。一方でスパムアップデートは、スパムポリシーに反する手法を検出する仕組みの精度を上げるものです。Googleはポリシーの冒頭で、違反行為は自動システムと、必要に応じた人によるレビューの両方で検出されると説明しています。後者は手動による対策につながり、違反したサイトは順位が下がるか、結果に表示されなくなるとしています。

この二段構えは実務のうえでけっこう重要です。手動による対策を受けた場合はSearch Consoleに通知が届きますが、自動システム側の評価が変わっただけなら通知は来ません。通知がないから何も起きていない、とは言い切れない一方で、通知が届いていれば原因の在りかははっきりしている、という読み方になります。

運営していると意外に触れやすい項目

ポリシーを読み直すと、悪意なく運営していても引っかかりうる項目が並んでいます。ひとつは利用者が投稿できる場所に溜まるスパムです。ブログのコメント、フォーラムの書き込み、ファイルのアップロード先などが例に挙げられており、サイト運営者自身が気づいていないことが多い、とGoogle自身が書いています。

もうひとつは、改ざんによって置かれたコンテンツです。既存ページへのコード挿入、新しいページの追加、本文への隠しリンクの混入、そして条件つきのリダイレクトが例示されています。検索結果から来た人だけ別のページに飛ばし、URLを直接開いた運営者には何も起きない、という形が典型です。長く動いているサイトほど、使わなくなったプラグインやテーマが入り口になりやすいところです。

第三者の記事を載せる形も気になりますが、ここはGoogleが線引きを明記しています。問題になるのは、ホスト側がすでに持っている評価を借りて上位に出すことが主な目的のときです。読者に直接届けることを目的とした寄稿、社説、記事広告、あるいは掲示板やコメント欄のような利用者投稿の仕組みは該当しない、と例外が並べられています。

安心してよい表現と、確かめたいリンク

隠しテキストの項目もよく誤解されます。白背景に白文字を置く、文字サイズや不透明度をゼロにする、CSSで画面外に飛ばすといった手法は違反ですが、アコーディオンやタブ、スライダー、ツールチップ、スクリーンリーダー向けのテキストは違反ではないと明示されています。使い勝手のために内容を出し分ける設計は、そのまま続けて構いません。

リンクについても同じで、広告やスポンサーとしてリンクを売り買いすること自体は否定されていません。rel=”nofollow” か rel=”sponsored” を付けて評価を渡さないようにしていれば、ポリシー違反にはならないと書かれています。過去に受けた掲載営業の名残が残っていないか、記事下やフッターのテンプレートも含めて見ておくとよさそうです。

順位が動いたと感じたら、まずSearch Consoleで手動による対策の通知を確認し、次に落ちたクエリとページを特定する。この順番で見れば、慌てて本文を書き換える前に原因の見当がつきます。展開はすでに終わっているので、ここからの数字は落ち着いた状態のものとして読めます。

WordPressの新版で増えた見た目まわりの指定

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

WordPressの新しいバージョンが8月19日に公開された。コードネームは「Mary Lou」で、ジャズピアニストのメアリー・ルー・ウィリアムスにちなんでいる。公式の発表によると、800人を超える貢献者が関わり、1500以上の改善と修正が入ったという。ここでは制作の現場で実際に触ることになりそうな変更を、いくつか並べて見ていく。

画面幅ごとのスタイルが標準の操作に

サイトエディターから、タブレットとモバイルの画面幅に対してブロックの見た目を指定できるようになった。グローバルスタイルでブロック種別ごとに設定することも、個々のブロックに設定することもできる。編集しながら表示幅を切り替えて確認する仕組みも付いている。

theme.json では @mobile と @tablet というキーの下に入れ子で書く。@desktop にあたるキーは意図的に用意されていない。ブロックの既定のスタイルがそのままデスクトップのスタイルであり、上書きしなかった項目はどの画面幅でも効き続ける、という考え方になっている。

区切りの位置も theme.json の settings.viewport で変えられる。既定はモバイルが480px、タブレットが782pxで、px、em、rem の非負の長さだけが有効になる。CSSの関数や割合、単位なしの値は無視される。標準のブロックサポート(タイポグラフィ、色、背景、境界線、寸法、余白、レイアウト)を使っているブロックは自動で対応し、独自のスタイル操作を持つブロックは対象外になる。自作ブロックを確認するときの境界線はここになる。

ホバーや押した状態も扱えるようになった

あわせて、擬似的な状態のスタイル指定が入った。theme.json とエディターの両方から :hover、:focus、:focus-visible、:active を指定できる。ただし今のところ対象は Button ブロックと Navigation Link ブロックに限られている。

メニューの現在地を表すための独自状態の仕組みも入っているが、こちらは theme.json のみで画面上の操作はまだ用意されていない。今は存在を知っておく程度でよさそうだ。

背景まわりで長年の回避策が不要に

ブロックサポートに background.gradient が加わった。従来の color.gradient は background の一括指定として出力されるため background-image まで打ち消してしまい、ひとつのブロックで背景画像とグラデーションを同時に使えなかった。新しい方は background-image の個別指定として出力され、画像とグラデーションをカンマ区切りでまとめて書き出せる。Group、Accordion、Pullquote、Post Content、Quote が最初の対応組になっている。

ほかに dimensions.minWidth が min-height と同じ流儀で追加され、グローバルスタイルでは text-shadow も扱えるようになった。

新しいブロックと編集画面の土台

Playlist と Tabs が試験的な扱いから正式なブロックになった。Playlist は複数の音声をひとまとめに並べ、再生中の様子を波形で添えることもできる。Tabs はタブで内容を切り替える表示で、これまでプラグインに頼っていた場面をいくらか置き換えられそうだ。

編集画面側では、管理バーがすべてのエディターで表示され続けるようになった。投稿エディターは、テーマの種類や登録済みブロックのバージョンにかかわらず常に iframe の中で動く。内容によって切り替わっていた従来の挙動はなくなる。エディター用のスクリプトが動く文書とキャンバスの文書は別物なので、素の document や window を見に行っているコードは対象を取り違える。要素から ownerDocument や defaultView をたどる書き方への置き換えが要る。

管理画面まわりの細かい追加

wp_get_tooltip() と wp_get_toggletip() が追加され、これまでエディターの中にしかなかった説明の吹き出しを管理画面全体で使えるようになった。前者はアイコンだけの操作に読み上げ可能な名前を与えるもの、後者は補足説明を開くボタンを添えるもので、コア自身も投稿画面のメタボックスやログイン画面のチェックボックスで使っている。

Navigation ブロックが子のリンクにフォントサイズを渡さなくなった点も、テーマを作っている人には効いてくる。相対単位が入れ子で掛け算になり、編集画面と表示側で文字の大きさが食い違う原因になっていた。has-{slug}-font-size を直接狙っているテーマは、開発者向けノートにある従来の挙動を戻すフィルターを見ておくとよい。

更新の前に、独自ブロックや管理画面を拡張しているプラグインを一度試しておきたいところだ。画面幅ごとの指定がコアに入ったことで、追加CSSで抱え込んでいた部分をテーマ側に戻せる場面は増えそうに思う。

【NO.150】AIが書いた文章に見えない印がつくようになりました。



先日、AnthropicのClaudeに仕様変更があると話題になりました。
AIが書いたかわかるように見えない印をつけるとのこと。

この騒動で「Claudeを解約」とか「印を消すサービス」とか
色々な方向に発展してるので、今日はこの「見えない印」のお話をしていきます。

今回、Claudeでこの話は話題になりましたが
実はGoogleは2年前からやっています。

ではなぜ、Googleの時には話題にならなかったのに、今回のAnthropicの場合は話題になったのか。

AI ActというEUが作ったAIについての法律があります。
この法律で新たに定められたのが

2026年8月2日から、透明性義務が適用開始。
2026年12月2日から、8月2日より前にEEA市場に出ていた生成システム（音声・画像・動画・テキスト）も対象。

という決まりです。

今回のAnthropicの動きは、この決まりに対応するためです。
Googleはこの決まりが出来る前からやっています。
つまりOpen AIも、なんらかの同様の印をつける必要があります。

このAI Actの決まりが出来てからなので、今回のAnthropicは話題になっただけと
わたしは考えています。

それと、Googleがやったときは、印の検出は一般人には出来なかったのが大きかったと思います。
今回のは、誰でも検出できるツールも配布される予定というのがポイントかも知れません。

今回の決まりに、大きな声で反発をする人たちはいますが
わたしは、今のうちになんらかの手を打っておく必要はあると思っている側です。

今回の決まりが、スキのない、素晴らしい決まりだとは思っていません。

ディープフェイクなど、さまざまな危険が放置されている状態ではあるので、何か決まりは必要だと考えます。
調整は今後行なっていけば良いかなと。

わたしが不思議だったのは、AIが作ったものだとバレることを嫌がる人が結構多いな。というところです。
個人的には、AIができること、わざわざ人間がやってどうするの？という考えなので、不思議な部分ではあります。

どういう感覚なのか、いまいちピンと来ません。
今の時代に、手書きの履歴書とか持ってこられて
「うんうん、パソコンに頼らず偉いな。」みたいな評価なんですかね？

わたしは、その人材が入社しても、効率の良い仕事をしてくれるとは考えられませんし
いかに自分をよく見てもらうかだけに一生懸命な印象を受けます。
これは個人の感想です（笑）

わたしは、今回の印を見分ける機能の痛手を受けるのは
学生が結構多いのはと思っています。

課題も論文も、AIチェックで即アウト。
ん〜、これも答えは分かりませんが何か違和感を感じます。

学びだから、自分で考える力を育てる。
はい、そこは同意です。

わたしは昭和の学校しか知りませんが、学生時代はルールで周りと同じようになることを良しとして
社会に出たら、個性を追求される矛盾を強く感じていました。

社会に出たらAIをうまく活用して課題をクリアすることを望むのに
学生時代の課題にAIを使うのはアウトってことですよね。
なんかこの辺の雑な感じ、どうにかならなないもんかと思っています。

先日、OpenAIが学生向けに作ったサービスで、すぐに答えを教えずに
答えに一緒に導いていくサービスがでまして、正解かどうかは分かりませんが
試みとしては、良い方向だと思いました。

AIを使うと、考える能力が低下する。

よく言われていますよね。
どうなんでしょうかね、一律で言うのは個人的に雑かなと。

メールというサービスが始まった時に
あんなもの使ってると、文章能力が落ちるって言われてました。
落ちたのは、字は読めるけど書けないということと、単純に字が下手になった感じじゃなかったでしょうか？
失うものが違うんですよね。こういうミスリード、多い気がしてます。

子供達は、人類の未来だと本気で思っています。
ミスリードがなるべく少ない世界を望みます。

印の話に戻りますが、今は嫌がっている人がいます
しかし、本当にASIの時代になったら、つまりAIが人間を調節する時代が来たら。

「Made in AI」じゃないと信じられない世界が来るかも知れません。
人間のドクターとか怖いです。
最新のロボットでお願いします。
なんて世界もありえるかも知れません。

「あの時代、印を嫌がっていた人いたよね（笑）」
なんて会話が未来でされちるかも知れませんね。

Just be hopeful.

ライブラリの棚卸しにBaselineを使うという発想

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

一度入れた外部ライブラリを、あとから見直すことはあまりない。動いているし、テストも通っているし、あえて触る理由がない。ただ、その間にもブラウザ側は動いていて、いま package.json に並んでいるもののうち何割かは、すでにブラウザが自前で持っている機能と重なっている。Smashing Magazine に出た依存関係の棚卸しの記事が、その重なりを具体的な数字で示していて面白かった。

入れたきりの依存が積み上がっていく

記事によると、中規模のJavaScriptアプリでは、圧縮後でおよそ60KBから90KB分の依存が、いまやブラウザ側で代替できる範囲に入っているという。日付や数値の書式、HTTP通信、モーダル、ツールチップ、オブジェクトの複製、配列のグループ化。数年前までは確かに穴だった領域が、順に埋まってきた結果だ。

それでもライブラリが残り続けるのは、怠慢だからではないと筆者は書いている。セキュリティの観点で npm audit は回していても、「このライブラリは今もブラウザにできないことをやっているのか」という問いを立てる機会が、そもそも運用の中に組み込まれていない。だから入れたまま何年も過ぎる。複数サイトの保守を抱えている制作の現場だと、この感覚は身に覚えがあるのではないかと思う。

Baselineという安全度の目盛り

棚卸しの物差しとして使われているのが Baseline だ。WebDX Community Group による指標で、ある機能が主要ブラウザ(Chrome、Edge、Firefox、Safari)でどこまで安全に使えるかを三段階で示す。全エンジンには載っていない「限定的な利用可能性」、出そろった直後の「新しく利用可能」、出そろってから30か月が経った「広く利用可能」という並びになっている。

この30か月の差が、棚卸しでは効いてくる。広く利用可能なものは、基本的に今日そのまま置き換えを検討できる。新しく利用可能な段階のものは、自分のサイトの訪問者層を確かめてから決める話になる。状態は webstatus.dev や、MDN の各機能ページに付いているバッジで引ける。

消す前に通しておきたい三つの問い

「ブラウザができるようになった」と読んで、すぐ削り始めないほうがいい、というのが記事の立場だ。紙の上では無料に見える置き換えが、一部の利用者の環境を静かに壊すことがあるし、気づかずに頼っていた機能を落とすこともある。そこで、削る前に三つ確認する。

ひとつめは、代替となる機能が自分の利用者にとって安全かどうか。一般論としてのBaselineではなく、アクセス解析や browserslist の設定と突き合わせて判断する。社内向けの管理画面と、古い端末からの流入が長く続く一般向けサイトでは、答えが変わる。

ふたつめは、置き換えの費用。ブラウザ側の対応が足りずポリフィルを足すことになり、それが外したライブラリより重ければ、容量は増えている。

みっつめは、ブラウザの機能が実際の使い方をカバーしているか。ライブラリは見た目の似た標準機能より多くの仕事をしていることが多い。記事が挙げているのが axios で、fetch に置き換えると、404や500で拒否されない、共通処理を差し込むインターセプタがない、自動再試行がない、アップロードの進捗が取れない、といった差が出る。実際にどこまで使っているかを見てから決める、という順番になる。

置き換えが効きやすいのは書式と画面部品まわり

記事はライブラリを一個ずつではなく、かたまりで見ていく。いちばん取りやすいのが国際化まわりで、相対時間、数値や通貨の書式、複数形、配列を文章に連結する処理は、ブラウザの Intl 系で大半が置き換えられる。この一群でおよそ14KBという計算だ。ただし継続時間の書式は主要エンジンに出そろったのが2025年3月で、広く利用可能になるのは2027年の見込みとされている。

もうひとつ大きいのが画面部品で、こちらはツールチップやポップオーバーのライブラリまで含めて合計およそ24KB。このうちモーダル用のライブラリ、フォーカスを閉じ込める処理、背景のスクロールを止める処理が、dialog要素とCSSの一行にまとまる。showModal で開けば、フォーカスが中に移り、背後が操作できなくなり、Escapeで閉じ、閉じたあとは元の要素にフォーカスが戻る。重なり順もブラウザが面倒を見るので、z-index と格闘しなくてよくなる。手書きの実装より結果的に読み上げ環境への配慮が行き届く、という指摘もうなずける。

通信まわりも同じ見方ができる。よく使われるHTTPクライアントは圧縮後で17KBから19KBほどあり、単純な取得や送信であれば fetch と中断用の仕組みで足りる。タイムアウトも標準の指定で書ける。ここは前述のみっつめの問いが効く場所で、共通処理や再試行に頼っているなら、外した分を自分で書き直すことになる。

配列やオブジェクトの操作も、グループ化や深い複製、集合の和や積は標準側に入った。一方で debounce と throttle には今も標準の代わりがないので、そこは残す。全部捨てるという話ではなく、ブラウザがすでに持っている部分を二重に配らない、という整理だ。

今は手放さないという判断も同じ枠組みから出る

この記事の良いところは、置き換えない例をきちんと入れているところだ。JavaScriptの日付処理を置き換える Temporal は、2026年3月に仕様策定の最終段階に達し、Firefox と Chrome には載ったが、Safari の安定版にはまだ来ていない。全ブラウザで使うにはポリフィルが要る。

そこで数字を並べると、軽量な日付ライブラリが圧縮後3KB程度なのに対し、公式のポリフィルは44KB前後ある。今すぐ乗り換えると容量は減るどころか増える。三つの問いに通すと、機能の良さでは勝っていても、利用者の範囲と費用で落ちる。だから今は現状維持で、Safari が対応してBaselineに入った時点でもう一度見る。判断を「保留」として記録しておける枠組みは、実務では地味に効く。

ブラウザ側の受け皿は今も増えている

置き換え先が増え続けているのも事実で、Chrome 150では、矢印キーでの移動やフォーカス位置の記憶を属性の指定だけで賄える focusgroup が入った。従来は tabindex を書き換える手書きのスクリプトで実現していた部分だ。文字を枠幅に合わせて拡縮する text-fit や、border-image の回り道なしでグラデーションの枠線を描ける background-clip の新しい値も同じ流れにある。

続く Chrome 151 のベータでは、コンポーネントの内側にある要素を aria-labelledby などから参照できる仕組みや、複合的な部品の中の補助的な操作を支援技術に伝える aria-actions が挙がっている。手書きのJavaScriptで補っていた振る舞いが、少しずつ宣言的な記述に移っていく。

中小企業向けのサイトだと、そもそも巨大な依存を抱えていないことも多い。それでも、テーマやプラグインが読み込んでいるものを一度数えてみる価値はある。四半期に一度、本番に出ている依存だけを並べ、それぞれが実際のビルドでどれだけ容量を占めているかを解析ツールで測り、代わりになる機能のBaselineの状態を確かめる。そのうえで先ほどの三つの問いに通し、いま標準になっているものを返していく。それだけで表示は軽くなり、更新を追いかける対象も減る。まずは一つの分野だけ選んで手元の設定ファイルを開いてみる、という始め方が現実的だと思う。

動画の再生状態に合わせた見た目をCSSで切り替える

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

動画や音声を埋め込んだページで、再生が始まったら中央の大きな再生ボタンを消す、読み込み待ちの間だけ画面を少し暗くする、といった切り替えを組んだことはないでしょうか。こうした見た目の出し分けは、これまでJavaScriptで再生や停止のイベントを拾い、要素にクラスを付け外しして実現するのが定番でした。その状態の判定を、CSSの側から直接書ける指定がブラウザに入ってきています。

再生中か止まっているかを見分ける指定

Chromeの開発者向けブログが公開したChrome 152ベータ版の案内には、:playing、:paused、:seeking、:buffering、:stalled、:muted、:volume-lockedという疑似クラスが並んでいます。いずれもaudio要素とvideo要素を、そのときの状態にもとづいて選ぶためのものです。

MDNの説明によると、:playingはメディアが再生されている状態を表します。興味深いのは、いま実際に映像や音が進んでいる場合だけでなく、利用者の意思以外の理由で一時的に止まっている場合も再生中として扱う点です。つまり、回線が細くて読み込み待ちになっている最中も:playingに当てはまります。利用者が自分でボタンを押して止めたときが:paused、というすみ分けになっています。

読み込み待ちや消音といった細かい状態も拾える

:bufferingは、再生を続けたいのにデータが足りず、読み込みを待っている状態を指します。MDNには、:bufferingに当てはまる要素は:playingにも同時に当てはまる、とはっきり書かれています。待機中の表示を出しているあいだも再生中用のスタイルは効いたままになるので、両方が重なる前提で指定を組む必要があります。

:mutedは、音を出せる要素が消音されている状態です。似たものに:volume-lockedがありますが、こちらは端末やブラウザ側の設定によって、JavaScriptからは消音の切り替えも音量の変更もできない状態を指します。作り手が制御できる消音と、作り手には手が出せない音量の固定を、別々に見分けられるようになっているわけです。

書き方は素直で、MDNにはvideo:mutedに枠線を付ける例が載っています。video:not(:muted)と組み合わせれば、音が出ている状態との出し分けもできます。利用者が再生コントロールで消音を切り替えれば、その場でスタイルのほうも切り替わります。

状態の同期をスクリプトに任せなくてよくなる

この手の状態管理は、地味に事故が起きやすいところです。イベントの取りこぼし、同じ画面に複数の動画を置いたときの指定の衝突、画面を切り替えたあとに前の状態が残ってしまう、といった不具合は制作の現場ではおなじみでしょう。判定をブラウザ自身が持ってくれるなら、そもそも表示と実態がずれる余地が小さくなります。

地方の中小企業のサイトでも、会社紹介の動画や商品の紹介映像を置くことは珍しくありません。凝った独自プレーヤーを作らない場合でも、再生が始まったら重ねていた説明の見せ方を控えめにする、読み込みが長引いているときだけ待機中の表示を出す、といった調整はCSSの側だけで書けるようになります。スクリプトを増やさずに済む分、表示の軽さにも保守のしやすさにも効いてきます。

いまの対応状況と現実的な取り入れ方

ただし、すぐにどこでも使えるわけではありません。MDNの各ページには限定的な対応と表示されていて、広く使われているブラウザの一部では動かないためBaselineには達していない、と明記されています。手元のブラウザで動いたからといって、すべての来訪者に同じ見え方を届けられる段階ではない点は押さえておきたいところです。

一方でChromeの案内では、これらの疑似クラスがInterop 2026の重点分野の一つに挙げられています。Interopはブラウザごとの実装のばらつきを揃えていくための取り組みなので、そこに入っているということは、対応が広がる方向で足並みが揃いつつあると読んでよさそうです。

現実的な取り入れ方は、これまでどおりの作りを土台に置いたうえで、対応しているブラウザでは見え方がもう少し気の利いたものになる、という上乗せの形でしょう。動かないブラウザでも困らない範囲から試してみると、次にプレーヤーまわりを触るときの引き出しが一つ増えます。

ゲスト購入した注文をあとから会員に紐づけられるように

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

ウェブショップを動かすWooCommerceの新しい版、11.0が公開されました。八月四日付の公開で、551件の変更が取り込まれ、89人が関わった大きめの更新です。中身は目新しい機能を足すより、土台の整理と積み残しの解消に寄っています。その中で買い物客の側から見て分かりやすいのが、ゲスト購入まわりの扱いの変化です。

WooCommerceには以前から、購入手続きを終えたあとにアカウントを作れる仕組みが用意されていました。11.0ではそこから一歩進んで、購入者が過去のゲスト注文を自分で探し出し、メールアドレスの確認を経てアカウントに結び付けられるようになっています。会員登録を後回しにしたまま何度か買い物をした人でも、あとから注文履歴を一つにまとめられる、という流れです。店舗側で名寄せの問い合わせに対応していた手間が、そのぶん減る可能性があります。

規模の大きい店舗向けの速度改善も入りました。内部の問い合わせの最適化、Store APIの改善、注文処理を通した在庫状態の扱いの見直しが挙げられており、商品数や注文数が増えるほど効いてくる部分です。ほかに、計測の取りこぼしを減らす調整、返金を売上の集計に反映する変更、取り込みに失敗した過去データをやり直せる仕組みも含まれています。

直後に出た修正版もあわせて

その六日後には11.0.1が出ています。こちらはセキュリティ更新の扱いで、ゲストのセッションcookieがソルト付きのより強いハッシュに変わりました。古いcookieは期限が切れるまで有効なままなので、更新をまたいでもゲストのカートは残ります。ほかにも、商品の短い説明にもパスワード保護が及ぶようになった点、Store APIでクーポンの利用回数の上限が正しく適用されるようになった点、カートや購入手続きのブロックに表示される通知の中身が安全に処理されるようになった点が並びます。ログの書き込みのたびにフォルダ全体を走査しなくなり、記録がたまった店舗で購入手続きが重くなりにくくなった改善も入りました。あわせて、次のWordPress 7.1に向けた互換性の調整も進んでいます。注文一覧が新しい一覧表の記述に合わせられた、といった地味な内容ですが、本体の更新を控えている店舗にとっては先に当てておきたい版といえます。

会員登録を必須にすると買い物の途中で離れられやすい、という悩みは店舗の規模を問わず共通です。ゲストのまま買えるようにしておき、必要になったときに履歴をアカウントへ寄せられる作りは、無理のない落としどころだと感じます。会員向けの案内やクーポンを届けたい店舗にとっても、購入のハードルを上げずに接点を作れる余地が広がります。一方で、注文とアカウントを結び付ける処理はメールアドレスの確認を挟むとはいえ個人情報に触れる部分なので、公開前に自分の店舗の設定で挙動を一度確かめておきたいところです。11.0はデータベースの更新を伴うため、控えを取ったうえで検証環境から順に試すのが安全です。

ChromeとFirefoxの更新間隔が秋から短くなる

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

ブラウザの新しい版が届く間隔が、この秋から短くなる。GoogleはChromeの安定版を4週間ごとに出してきたが、9月から2週間ごとに切り替える。ほぼ同じ時期に、MozillaもFirefoxで同じ方向の変更を試す。新機能が増えるという話とは少し性格が違って、これはサイトを作って納品したあとの面倒の見方、つまり段取りのほうに関わる変更だと思う。

Chromeは九月から二週間ごとに

Chrome for Developersの告知によると、新しい間隔での最初の安定版はChrome 153で、公開は2026年9月8日。ベータ版は各安定版の3週間前に出る。対象はデスクトップに限らずAndroidとiOSも含まれ、すべてのプラットフォームで同じ間隔になる。

変わらない部分もある。企業の管理者や、Chromiumを自社製品に組み込んで使う側に向けたExtended Stableは、これまでどおり8週間ごとのまま。DevとCanaryにも変更はない。更新の回数が増える代わりに、1回あたりに入る変更の幅は小さくなる。Googleはその点を、利用者への影響を抑えられて、公開後に問題を追いかけるときも切り分けがしやすくなる理由として挙げている。

切り替えの前後では、開発の締め切りにあたるブランチの日程も前倒しになる。告知には移行期の日程表が添えられていて、どの版がいつ枝分かれしていつ公開されるかが並べてある。個別の機能がどの版に入る予定かを追いたい場合は、Chromiumのダッシュボードや Chrome Status のロードマップで日付を確認できる。

Firefoxも同じ時期に間隔を詰める

Mozillaの開発者向けメーリングリストでは、Sylvestre Ledru氏が、Firefoxのデスクトップ版とAndroid版を9月から4週間間隔ではなく2週間間隔にすると告知している。最初の対象はFirefox 155で、公開予定は9月1日。これまでの日程なら出せなかったタイミングだ。

ただしMozillaはこれを実験と位置づけている。恒久的な変更と決め打ちせず、実際に走らせてみた結果を見ながら必要に応じて調整するという書き方をしている。開発者に倍の速さで働くことを求めるものではなく、準備できていない仕事を急がせるつもりもない、機能は必要なだけ時間をかけてよい、という説明も添えられている。頻度を上げる狙いは、出せる状態になったものが利用者に届くまでの待ち時間を減らすところにある。

四週間ごとで出る最後のChrome 152

現行の間隔で出る最後の版がChrome 152になる。ベータの告知を見ると、CSS側では音声や動画の状態に応じて見た目を変えられる擬似クラスが増えている。再生中や一時停止中、読み込み待ち、消音といった状態を :playing や :paused のような形で書き分けられる。自前の再生ボタンを作るときに、状態の受け渡しをJavaScriptで持たずに済む場面がありそうだ。

ほかにも、既存の色を参照して透明度だけを変えられる相対的な指定や、入力欄の自動修正の効き方を制御する autocorrect 属性が入る。どれも派手な機能ではないが、実務でよく書いていた小さな回り道を減らす種類の変更が並んでいる。こうした細かい追加が、これからは半分の間隔で積み上がっていくことになる。

保守の段取りをどこで区切るか

頻度が上がって困るのは、たいてい機能そのものではなく、こちら側の段取りのほうだ。よくあるのが、保守の説明や見積書に「最新版のChromeとFirefoxで表示確認」と書いてあるだけで、いつ確認するかは決めていないというケース。間隔が半分になると、確認の回数を増やすのか、こちらで区切りを決めてまとめて棚卸しするのかを先に決めておかないと、追いつけていない感覚だけが残ってしまう。

現実的なのは、毎回は追いかけないと割り切ることだと思う。ベータ版で先に触れる期間は変わらず用意されているので、自分たちが関わるサイトで実際に使っている仕組みに関係する変更だけを拾い、それ以外は通常の保守の周期でまとめて見る。手の数が限られている小規模な制作現場ほど、この線引きを最初にしておく効果は大きい。

頻度が上がることには直接の利点もある。修正が手元に届くまでの待ち時間が短くなることだ。深刻な脆弱性の修正を定期便とは別に配る仕組みは以前からあるが、通常の不具合や表示の食い違いも、これまでより早く解消されるようになる。閲覧する側の環境が新しくなる速度が上がるという意味では、作る側にとって悪い話ではない。

もうひとつ、版番号を条件にした分岐や、対応範囲を版番号で書いた文書は、これから急速に古びていく。番号ではなく、その機能が使えるかどうかで判断する書き方に寄せておいたほうが、あとで書き換える手間は少なくて済む。ブラウザ側が速く動くようになるほど、こちら側は番号から距離を置いたほうが楽になる。