HTMLに賭ける
(catskull.net)- 大規模言語モデルベースのAIが広がるにつれて、人が見る画面と同じくらい、機械が読めるセマンティックHTMLの価値も高まっている
- 大手ソーシャルメディアの囲い込み型プラットフォームはデータ移動と相互運用性を妨げ、fediverse・Threads・Blueskyのような分散型の試みも一般ユーザーを引きつけるには動機が弱い
- 現代のHTMLは
<details>、<dialog>、さまざまな<input>のように、Webアプリに必要な基本UI要素をすでにかなり備えている - ブラウザのデフォルトスタイルやreader modeを活用すれば、過剰なCSS・JavaScript依存を減らせ、適切なタグは機械可読性とモバイル入力体験を改善する
- RSSが今も生き続けており、ChatGPT系インターフェースがデータアクセス手段として浮上している流れでは、広告中心のインターフェースよりも構造化されたHTMLのほうが実用的な基盤になりうる
Webの基本データインターフェースとしてのHTML
- 大規模言語モデルベースのAIの登場は、セマンティックHTMLの重要性を再び押し上げている
- インターネットの本質は、人が世界と相互作用するために必要なデータを届けることだが、HTML/CSS/JavaScriptの自由度はデータアクセスを制限する側面も持つ
- 大手テック企業のソーシャルメディアは、公開されアクセス可能なデータ形式やAPIよりも、閉鎖型プラットフォームの中にユーザーを囲い込んでいる
- プラットフォーム間の相互運用性は事実上難しくなっている
- 企業が簡単なデータ移行を嫌がることで、問題はさらに複雑になっている
- 最近のソーシャルメディアの不安定さは、fediverse のような分散型プラットフォームへの関心を再び高めている
- MetaのThreadsとJack Dorseyが作ったBlueskyは、より大きなfediverseとの相互運用性を打ち出している
- ただし一般ユーザーは、こうした理由だけで新しいソーシャルメディアを選ぶことは多くない
- すでに実証済みの解決策として、HTML を見直す必要がある
- 過去には、ブラウザでHTMLコンテンツが見栄え悪くならないようCSSを多用する必要があった
- 今では最新のHTML要素が多数追加され、現代的なWebアプリケーションに必要なUI要素の大半を提供している
- reader modeはスタイリングに費やした時間を無効化しうるが、これは前向きに捉えられる
- 正しいタグは機械が読みやすい形式を提供する
- 単にデザイン時間を節約する以上に、現代HTMLを採用する強い理由になる
- RSSは生き続けている
- ChatGPTのようなインターフェースが、人がデータにアクセスする将来の方法になる可能性もある
便利、または新たな見方ができるHTML要素
- MDNのHTML要素一覧は一見の価値がある
- 以下の例は別途スタイルを付けず、ブラウザのデフォルトスタイルだけを使っている
- ブラウザによって見え方が大きく異なったり、まったくサポートされないこともある
<abbr>: 略語を囲む要素- スタイルを適用して強調できる
- 主に機械可読の面で有用
<datalist>: 入力候補の一覧を提供する要素- タイプアヘッドのようなUIを作れる
- 組み込み検証はないように見える
- Safariでは
optionタグを閉じる必要があり、閉じないと動作しない
<details>: 開閉型の公開要素- 小さなドロップダウンのように使える
- スタイリングもかなり強く適用できる
<dialog>: ダイアログ要素- ボタン、フォーム、属性、JavaScriptで開閉できる組み込み要素
- 正確にはモーダルと同じではないが、モーダルを作るなら土台として使える
- 後続の要素の上にレンダリングされるようだ
<i>と<em>- 2つの要素の違いを知っておく必要がある
<iframe>- 例示一覧には含まれているが、冗談めかして扱われている
<input>: フォーム入力要素- 入力には適切なラベルと型を使うべき
- モバイルでは文脈に応じてOSが異なるキーボードを開くため、入力タイプの指定が重要
- 時間関連の入力が多様なので、別途JavaScriptのdate pickerを減らせる
- 例として
color、range、datetime-local入力が挙げられている
<mark>: テキストのハイライト要素- デフォルトではSafariで黄色のハイライトとして表示される
<meter>: 測定値表示要素- Safariでは設定したパラメータに応じて赤・黄・緑で表示される
optimum値を設定できる- 60fpsの音楽ビジュアライゼーションデモに役立つかもしれない
<progress>: 進捗表示要素- 固定値または不確定状態を与えられるネイティブHTMLの進捗バー
- Safariではウィンドウがアクティブなとき青、非アクティブなとき灰色に見える
- デフォルトではシステムのアクセントカラーに従い、CSSの
accent-colorプロパティで設定できる
1件のコメント
Hacker Newsの意見
HTMLがクローズドなエコシステムへのロックインの解決策だというのは変だ。そうしたクローズドなサービスもすでにHTMLを使っているし、言及されているセマンティック要素の一部や、より精緻なARIAのセマンティック属性も使っている。
ChatGPTのようなインターフェースが人間のデータアクセスの未来だという主張についても、AIシステムの要点は、入力を処理するために特別な「機械可読」注釈を必要としないところにある。ChatGPTや後続モデルは人間のように一般的なWebサイトを探索できるし、段落のまとまりが「リスト」かどうかも明示的なマークアップなしに気づける。
筆者が説明しているものは、結局HTMLのセマンティック要素を介したAPIに近い。だがAPIがあるなら、自動的なデータアクセスに大規模言語モデルは必要なく、Beautiful Soupを使う普通のPythonスクリプトで十分で、ローカルだけで実行できるという利点もある。
結局、良し悪しを分けるのは実装の複雑さだ。どんな道具でもうまく使うことも下手に使うこともできるし、初心者が丸ノコと充電済みバッテリーで大事故を起こすこともある。職人は道具をまったく使わず、横を叩く、つまりビジネス要件に逆らう選択をすることもある。
最近作ったWebサイトは、自分が作った中で最も互換性が高い。もうWebSocketは使っておらず、JavaScriptがサーバーと細切れにやり取りする方式にも依存していない。JavaScriptを完全にオフにしても、製品の約80%を使える。こうしたエンジニアリング上の選択が、どうしてクローズドなエコシステムへのロックインに対する解決策ではないと言えるのかわからない。
大規模言語モデルはテキストやソースコードなどを学習するが、推論装置と呼べるものが乏しい状態でDOMツリーを見て、それが何で何をするものなのか本当に理解できるのだろうか。DOMはテキストでもないし、バンドル化やコンポーネント化の結果なので、よく構造化されたソースコードとも言いにくい。「大規模言語モデルが任意の.exeを見て即座に統合できる」と言うのとほとんど同じに聞こえる。
私も似た関心があるが、目的はクローリングと新興検索エンジンだ。すべてのページをインデックスする前にヘッドレスブラウザで実行しなければならないなら、新しい検索エンジンの参入障壁はずっと高くなる。
この記事の最初の文は「大規模言語モデルベースのAIの登場により、セマンティックHTMLはかつてないほど重要になった」だが、むしろ「大規模言語モデルベースのAIの登場により、セマンティックHTMLはかつてないほど重要でなくなった」のほうが、はるかに擁護しやすい文だと思う。
セマンティックWebは失敗し、その座を、Googleが当時最高水準のAIを組み込んだ各種ヒューリスティックに莫大な資金を投じるやり方が置き換えた。AIが良くなるほど、適当に作られたごちゃ混ぜからでも情報を抽出する能力は上がり、そうしたごちゃ混ぜで十分なら、人々がかける労力もそこまでだろう。原理的には、最終的にセマンティックWebもヒューリスティックの山も、どちらもAIに置き換えられる。
最初だけLLMと書き、その後は一般用語であるAIに切り替えている点も重要だ。大規模言語モデルはAI全体ではなく、今ホットな一分野にすぎず、最後のホットな分野でもない。今後数十年を、大規模言語モデルがAIの最終解だと仮定して見通すのはよくない。
コンテンツの関連部分が十分にうまくインデックスされ、順位に上がることが目標なら、セマンティックHTMLを全面的に採用する動機は足りなかったと言える。
目標が「順位に上がること」から「大規模言語モデルにコンテンツのニュアンスや質感を最大限抽出させること」へ変わるなら、特定の要素をよりうまく使う動機は強まるかもしれない。そうするWebサイトは、大規模言語モデルの出力により大きな影響力を持てる。
聞こえるくらい大きな声で話すことと、理解されるくらい明確に話すことの違いのように感じる。
Bardが入った新しい結果ページを発表したのは聞いたが、広告を無視する習慣のせいなのか、まだ自分の地域に出ていないのか、見た覚えがないので調べてみないといけない。
頭の中ではセマンティックWeb陣営に近かったが、機械がそのごちゃ混ぜをそこそこ理解できるなら、わざわざ苦労する必要がどこにあるのか、という話はもっともだ。
知識グラフや他のデータ資産が、AIが「真の」知識を検索するのに役立つと主張するプロジェクトもある。個人的には、AIが自分のデータ資産を作れるようにする方法を開発するほうがよいと思う。ニューラルネットワークの重みもそうした資産の一つだ。
真実の問題は依然として非常に難しい。ある知識が別の知識より信頼できるとAIにどう知らせればよいのか？もちろん人間にも同じ問題がある。
これらの HTML 要素の大半はほとんど聞いたことがなく、かなり残念に思った。こうしたものは、「何にでも JavaScript が必要」というエコシステムを終わらせるのにかなり役立ち得るからだ。
少なくとも JavaScript を本来の意図に近い位置、つまりちょっとした装飾やインタラクションを加える手段へ戻せる。すべてのマークアップの代替であり、DOM 全体の管理者である必要はない。
自分が夢見るブラウザは、visurf https://sr.ht/~sircmpwn/visurf/ のような形で、内部の Netsurf エンジンがこうした要素を含む現代的な HTML+CSS をサポートするよう更新されたものかもしれない。そういうブラウザなら、ほとんど JavaScript のない小さなウェブを作れそうだ。スクリーンリーダー、システムテーマ、ショートカットキーなどを壊しにくくなってアクセシビリティが向上し、代替可能な重い JavaScript の仕掛けよりはるかに少ないリソースで済み、今日の中規模 Web アプリに期待されることの大半も実現できそうに見える。WebGL のようなものは Firefox を起動すればよいが、たとえば Matrix クライアントでも、WebSocket とエンドツーエンド暗号化のために少し JavaScript を載せる程度で済むかもしれない。
拡張性もほとんどないので、少しでも複雑なことをしようとすると結局捨てて JavaScript でやり直すことになる。そうなると最初から JavaScript で始めたほうがよく、そちらはうまく動き、完全な制御権を与えてくれ、すべてのシステムで同じように動作する。
結局、こうした追加コンポーネントは、すべてのブラウザが実装しなければならないのに誰も使わない肥大化要素として残る。
datalistを初めて見たときは「すごい、ゲームチェンジャーだ」と思った。動作はブラウザ間で同じだが、見た目は完全にブラウザ依存で、CSS でスタイル指定できない。あるときはデータのテキストだけが表示され、あるときはテキストと
value属性が一緒に表示される。そのため「Atlanta」を選ぶのではなく、「234290780 Atlanta」、つまり ID と値を一緒に選ぶことになる。クリック時の動作でも ID だけを直接取得できず、全体を取得して ID をパースしなければならない。単なる放置された要素のように感じる。
記事は MDN にリンクしていて、MDN は短いリファレンスとしては最も有用な部類だ。もちろん WHATWG HTML 仕様もあるし、あまりに膨大なら WHATWG HTML 2021・2023 スナップショット用の SGML DTD 形式の文法や、以前の HTML 5.x 系の文法もある。
[1]: https://sgmljs.net/docs/html200129.html
セマンティック Web を信じたいし、ブラウザが優れた標準モジュールとそこそこよいデフォルトスタイルを提供できると信じたいが、今はそうではないことを受け入れるしかない。
inputにラベルを付けるだけでも、なぜ属性ではないのかから考えなければならず、ラッパーとして使うべきなのか、for=属性を持つ兄弟要素にすべきなのかも確信しにくい。これは氷山の一角にすぎない。各タグごとに開発の歴史を丸ごと学び、現在の正しいやり方が何なのかを調べ直さなければならない。いいものを持てたかもしれないが、もう落ち着いて手放すべきなのかもしれない。
確かに変な部分や荒削りなところはあるが、すべての Web 開発者がセマンティック HTML を最大限活用できていたなら、ブラウザ上の JavaScript ははるかに少なく、アクセシビリティのバグも減り、仕様がこうした奇妙な点を修正したり置き換えたりする必要があるときに、より多くの目が向けられていた可能性が高い。
label属性はプレーンテキストの内容を意味するはずで、制限が強すぎるように見える。HTML は数十年使われてきたものらしく、複雑な歴史と複数の層を持っている。それでも最近は大きく変わっておらず、MDN のおかげで HTML5 で何が可能かを十分に学び、必要なときにさらに掘り下げるのは簡単だ。
labelタグをinputタグの後ろに置きたくなる。そうすれば CSS の擬似クラスで、入力状態に応じてラベルを選択してスタイル指定できるからだ。もちろん、どんな出版システムでも、実際にはどんなシステムでも、効果的に使うには提供されている基本要素の使い方を学ばなければならない。だからこれはセマンティック Web だけの問題ではない。
Go の HTML テンプレートのデバッグに
detailsをよく使う。{{if .DevMode}}で開発モードのときにデータを入れておくと、折りたたまれている間はページを大きく壊さず目立ちにくく、必要なときに開けば全体を見られる。details要素を少し乱用している。とてもすっきりしているのに、なぜもっと使われないのか分からない。GitHub Markdown でも使えるし、例やインライン説明に使っている人もいる。
読み物としてもインタラクティブなデモとしても良かった
Flutterを数年触ったあとで、また同じ結論にたどり着いた。HTMLに賭けるべきだ
Astro / Tailwind / Daisy UI / Alpine.js の組み合わせは、シンプルなサーバーサイドレンダリングを多用し、クライアント側のリアクティビティを少し振りかけたHTMLサイトを作るのに向いている
成果物はシンプルでまともなHTMLファイルで、デスクトップWebブラウザでもモバイルのラップされたWebViewでも見栄えがよく、きちんと動く。自分のアプリは実質的に静的なのでCDNにキャッシュされ、オフラインでも動作し、ソース表示がデバッグを楽にしてくれる
一番良いのは、新しい開発者がReact、Angular、PHP、Pythonのどの出身であっても、100行のビルドファイルを3分ほど見れば理解できると確信できること。本当にシンプルで良い
セマンティックWebの問題は、どれだけ簡単になっても開発者が正しく使うことを拒む点にあると思う。自分のブラウザ拡張機能が
mainタグを使うので、このタグを注意して見てきたが、MDNのドキュメントは何をすべきかが非常に明確で、ドキュメント自体も良い使用例を示している。それなのに、正しく使っているサイトはごく少ないそれどころか、見栄えのするプロ向けサイトでさえ、ナビゲーションやフッターのようなものまで含めたページ内の全コンテンツを
mainタグの中に包んでいることがある。このタグはページの主要コンテンツにだけ使うべきだこれほど単純な要素すら正しく使えないなら、他の要素にはあまり期待できない
こういうものを契約であるかのように見せかけるべきではない
pタグを段落に使った開発者は、文字通り全員が正しく使っている。class="card"のようなものとは違う技術理解の高い人たちが、こんなにも多くセマンティックWebの無用さや失敗を嘆くのが理解できない。「自動車が成功してほしい、長距離移動が楽になるのに」と言っているように聞こえる
だが、そういう時代はあった。HTML4以前のものは概ねそうで、それはもっとひどかった
だから、開発者ツールが誤った使い方に対して警告やエラーを出す方向のほうがよいのかもしれない
ここにある多くのコメントがこの記事を反JavaScript記事として見ているのが興味深い。自分にはむしろ、現代的なエンタープライズアプリのフロントエンドで使っているTypeScript中心のフレームワークと併用すると、とても有用なツール群に見える。HTMLネイティブのツールなので、あれこれ多くを要求しないからだ
例えば
meterタグは、今日出社したらReactで使っているすべてのローディングモジュールを置き換えることになりそうだ。今使っているものよりずっと良いからだ自分が人々を誤解しているか、記事を読み違えているのかもしれないが、今日の大規模アプリケーションのようにフロントエンド全体がほぼTypeScriptである場合でも、これは非常に興味深い
以前よりはるかに少ないJavaScriptでも作れる新しいアプリケーションが出てくる。既存のエンタープライズTypeScriptアプリではインプレースアップグレードになるかもしれないが、希望としては、新しいアプリ開発でそうしたエンタープライズフレームワーク自体を避けられるようになることだ。夢くらい見てもいいだろう？
Web開発を完全にこき下ろしたいわけではないが、本当にひどい。生のHTMLからスクリプト言語、フレームワークまで何年もやってきたけれど、たいしたことのない作業にかかる時間が、ものすごい脳の無駄遣いに感じる
休暇に行ったとき、食べたり飲んだりする場所や、1日立ち寄る場所を探したかっただけなのに、ほとんどのサイトはめちゃくちゃだったり古かったり、更新されていなかったりした。一度作って忘れられたサイトがまだたくさんある。予算が厳しくて更新する余裕がないか、更新が技術的に難しすぎるのだと思う
サイトの複雑さが麻痺を招いている。単純なテキストと画像の数ページで済むものが、無駄に過剰設計され、膨大なCPUサイクルを燃やしている。セキュリティ更新が必要な既製のCMSを改造して作っている可能性も高い
最近、映画館のサイトを見たのだが、その週に上映している数本の映画をざっと見ることすらほとんど不可能だった。スプレッドシートに入れたほうが読みやすいと感じたし、実際にAPIからJSONを落として見てみると、そのほうが読みやすかった
たいていは豚に口紅を塗ったような、疲れる包装にすぎない。Facebookが成功した理由の1つはオンボーディングが簡単だったことで、もう1つは写真共有が簡単だったことだ。WhatsAppやInstagramも同じ。公開は簡単であるべきだ。単純なFTPも簡単ではあるが、普通の人にとっては使い勝手の流れに奇妙な断絶がある。人々が求めているのはドラッグ＆ドロップ、アップロード、置いて忘れること、簡単な編集だ。データを消費したい人たちは結局、核心だけを求めている。つまりデータそのものだ
人々が求めているのは、きちんとスタイリングされ、使いやすいWebページだ。問題は、有能で効果的なユーザー体験デザイナーが十分におらず、会社のステークホルダーにもまともなUX感覚が不足していることだ
そのため、平均的な会社が用意できる中途半端なUXよりも、核心となるデータだけを提供するほうが平均的なユーザーにとって良い、という状況になっている。好まれないとしても、そのほうがましだからだ
{悪いUX} << {生データ} < {良いUX}WordPressが見つけた回避策は、プロフェッショナルなスタイルやテーマを作り、ユーザーが購入して適用できるようにすることだった。だが、ステークホルダーの悪趣味までは解決できない
Facebookは、プロフェッショナルで標準化されたUXを強制したから成功したのだと思う。
{人々のデータ} + {プロフェッショナルで標準化されたUX} = {勝利}だ。初期のFacebookのUXが嫌いだとしても、素人仕事だったとは言いにくい。MySpaceやGeocitiesなどに対する一般的な認識はその逆だった金網のようなものを探したければ、自分が入っているWhatsAppグループ、家族・近所・高校の友人グループから尋ねる。たいていいくつか番号をもらい、サービス提供者にWhatsAppで連絡すれば最新情報が得られる
そのサービス提供者たちは、最新のWebサイトを維持する余裕がない。WhatsAppにはプロフィールにカタログを載せる機能もあり、無料のビジネスアカウント向けだ
見たいのは「Wix Widgets」のようなものだ。RESTサービス呼び出しをつなぎ、データポイントをウィジェット表示にマッピングする程度のカスタマイズができる、データ接続型のウィジェットだ。最近どの会社にもある社内向けWebサイトの需要をさばくのに、かなり役立つはずだ
Webページの90〜95%には、単純な解決策が本当に必要だ
もしかすると、これがGUIの本質なのかもしれないとも思う。すべての指示を一つひとつ出さなければならず、多くのサイクルを食い、そうしないとクロスプラットフォームで動かない構造なのかもしれない
articleやsection要素を追加して試みたとはいえもちろん、生のHTMLコードはそもそも開発者以外の人が読むために作られたものではなかっただろうから、そういう面もある
純粋なHTMLモーダルができたという知らせに本当に期待したが、JavaScriptなしではトリガーする方法がないと知って失望した。純粋なHTMLでは閉じることしかできず、開けない
https://github.com/whatwg/html/issues/3567
dialog要素は素晴らしい追加で、実装されているのはうれしいが、コア機能の一部がJavaScriptに依存している。dialogを開くには、JavaScriptでopen属性を設定しなければならないbuttonやa要素がダイアログを開ける方法があるといい。HTMLに組み込まれたページ内インタラクションの前例はすでにある。たとえばリンクはページをスクロールできるし、details要素はインタラクションの後ろに要素を隠せるので、別のページ要素がdialogを開けても自然に見えるたとえば、ここの右上にある
?をクリックしてみるといい: https://aavi.xyz/proj/colors/onclick属性に入れることもできる