HTMLがここまでできる　dialog、popover、ネイティブUI

yurishimoによるこのコメントは[dead]であるべきではないと思います。>ちょっと注意ですが、datalistは強い契約が必要な場合にはあまり良い解決策ではありません。ユーザーはフィールドに好きなものを入力でき、あいまいなフィルタリングやタイポの緩和はありません。これらの要件を追加すると、より完全な機能を備えたコンボボックスを提供するライブラリがプロジェクトで非常に理にかなっている可能性が高いです。それは本当です！HTMLは多くのクールなことをでき、何をしているかによっては100%の道のりを達成できるかもしれません。しかし、ユーザーが値セットから選ぶフォームが多く、他の文字列を強制しないようにし、良い検索体験を得たい場合、datalistはそこに到達できません。

私はあなたの統計の中のその細部であり、2026年でもまだNoScriptを使い続け、サイトごとにJavaScriptを有効にしていますが、これは現代のウェブではますます困難になっています。うまくいけば、これらや他の現代のHTML機能が採用され、おそらくシングルページアプリケーションがほとんどの場合に必要ではないという認識も得られるでしょう。私はフロントエンドコードを書くことはあまりありませんが、書くときには、最近のHTMLでできないインタラクティブ性はほとんどなく、最悪の場合、HTMXのようなものを少し振りかけるだけで済みます。

日付入力にISO形式を強制できたら本当にいいのにと思います。現在の「プラットフォームネイティブ」は、OSが表示されているウェブページとは異なる言語を使用している場合、一部のユーザーにとって混乱を招きます。多国籍企業にとっては、基盤となるOSの言語に関係なく、すべての管理ページを英語にすることが理にかなっています。OSの日付形式が、英語のページから誰もが期待するものと異なるスクリーンショットを送ることを想像してみてください。

これに関連して、HTMLがソート可能なテーブルをネイティブにサポートしてほしいです。これは一般的なニーズですが、毎回再実装しなければなりません。

2026年のHTMLは、1996年のネイティブデスクトップGUIフレームワークができたことのほとんどをやり始めています…まあ、正直に言うと「ほとんど」は誇張です。ミレニアムの変わり目にNeXT/Apple AppKitがすでに提供していたことを考えると。フロントエンドにとって、Web 2.0が皆をUIフレームワークの最低共通分母に置き、その後何十年もチェックボックスやメニューボタンを貧弱に再構築するだけに費やしたことは、大きな後退でした。マイクロソフトはここで重要な役割を果たしました。彼らは2001年頃に過剰に達し、圧倒的なデスクトップ支配力がインターネットのUI層の進化を単独で決定できると考えました。そのため、彼らはInternet Explorer（95%の市場シェアを持つブラウザ）を非推奨にし、XAMLのような独自のソリューションをHTMLの代替としてすべてのエンジニアリングの賭けに出ました。

HTMLは開始以来<select>を提供してきましたが、それでも人々は<div>と大量のJSを使ってそれを再発明しようとするのを止めませんでした。これらの素晴らしい組み込み機能、特にタイプアヘッドは、過度にスタイル設定できるようになるまで主流にはなりません。

グループ化された<details>を見て、Ctrl+Fで非表示のコンテンツを検索したところ、Firefoxで開いてテキストがハイライトされました。detailsについて学んで以来、この修正を待っていました。