ついに来た！select要素がCSSで自由にカスタマイズ可能に！長年の夢、JSライブラリ不要になるかも？
引用元：https://news.ycombinator.com/item?id=43532830
2000年代初頭のウェブ開発者としては、めっちゃ興奮してるんだよね。selectってHTMLじゃ再現できないことができるからさ。viewportの外にドロップダウンを表示できるとか、マジで助かる機能だわ。次はautocompleteとtag selector頼む!
記事によると、base-selectを使うと色々できなくなるみたい。
＞The ＜select＞ doesn’t render outside the browser pane. … It doesn’t trigger built-in mobile operating system components.”
＞”＜select＞はブラウザの外に表示されないし、OSの機能も使えない”
モバイルユーザーは最適化されてないselectに備えろってことか。でもjavascript減らせるのは良いね。
＞The ＜select＞ doesn’t render outside the browser pane. … It doesn’t trigger built-in mobile operating system components.”
＞”＜select＞がブラウザの外に表示されないとか、OSの機能を使えないとか、それって＜select＞じゃなくね？スタイリングは良いけど、これじゃ意味ないじゃん。
スタイリングのオプションが全くないのと、ユーザーを危険に晒すオプションしかないんじゃなくて、その中間が欲しいよね。
select2みたいなカスタムのselect代替要素はもう色々あるよね。selectにcombobox機能がないのが問題で、type-ahead completionとか、大量のデータソースからの遅延ロードができないんだよね。
ブラウザの外に表示できなくなるのは痛い。iPadのStage Managerだと、ポップオーバーはウィンドウ内に収まるんだよね。セキュリティの問題かな。
「OSの機能を使えない」って仕様なの？Appleなら違う実装するかもね。
どうなんだろう。positioningとかsizingとかboxのCSS propertiesが壊れるかも。ネイティブウィジェットでHTMLをレンダリングする必要があるし、WebKitをネイティブウィジェットに入れる必要もあるかも。セキュリティの問題もあるし。
モバイルユーザーが圧倒的多数なのに、ウェブデザイナーはユーザーに優しくないサイトを作るのかね？（たぶんそう）
マジでサイトによるよねー。モバイルブラウザで何か調べるのってマジ地獄。仕事も無理ゲー。誰があんな小さい画面でキーボードなしで作業したいんだよ？デスクトップなら、一つのテーマで何十、何百ものタブを開けるし。だから、うちのサイト（技術系の記事）へのアクセスがモバイル端末からたったの17%ってのも納得。
Windowsが52%、Linuxが18%、Macintoshが13%、Androidが11%、iOSが6%、Chrome OSが0.5%、その他が0.5%未満だってさ。（AndroidとiOSにはタブレットも含まれてるかもだけど、タブレットからのアクセスはほんの数パーセント。）（クローラーとか不明なUAは除外した結果ね。）
ちなみに、ボットって嘘つくから、Windowsの結果が水増しされてるかも。別のデータソースだと、Google検索でサイトを見たデバイスは、デスクトップが69%、モバイルが30%、タブレットが1%だって。（クリック数も似たような感じ。）
それはそうだけど、最初の実装ってことっしょ。そのうちブラウザベンダーが、selectのフル機能をちゃんと使えるようにしてくれると思うよ。
ブラウザはviewportの外のことには絶対webコードの影響を受けさせないと思う。詐欺師がヤバいことしかしないって。
viewportの中のピクセルを勝手に描画するだけでも十分ヤバいのにね。一時期廃れたけど、また流行りだしてるのが、ユーザーのOSとブラウザを検知して、Paypalの偽ウィンドウをpixel単位で再現してログインさせようとするやつ。最初のブラウザの中に表示されるんだよ。
だから1Passwordの新しいログインプロンプトは前より酷いんだよ。画面の真ん中に表示されるから、ウェブサイトが簡単に偽物を作れちゃう。前のは拡張機能のアイコンの高さに表示されてたから、ブラウザのアラートダイアログよりちょっと上だったんだよね。
絶対ないわ。なんでブラウザのウィンドウの外にweb開発者が描画できるようにするんだよ？マジありえない。
中間地点が必要だよね。背景色とフォントだけ設定できるようにして、ネイティブっぽい機能は残してほしい。
画像みたいなフォント（色んなUnicode文字を使って、それぞれに小さいタイルを割り当てる）を使えば、それっぽい画像を作れると思う。
てか、一つの文字にどれくらいのディテールとかサイズとか色とかアニメーションを詰め込めるんだろう？
Chromeだとこれで動くし、メニューがviewportの外に出るのも防げないよ。
select、option ｛
background： red；
font-family： ’comic sans ms’；
｝
マジか、Chromeだけかよ
HTMLで基本的なtypeaheadコンポーネントやタグセレクターがないなんてマジでありえないよね。作ったどのページにも必要だったし。ライブラリはあるけど、バグがあったりするし。Selectタグのスタイリングが今できるようになったってことは、もっと複雑なtypeaheadはいつになることやら。
なんでエンジニアのリソースを、広く使えるHTMLウィジェットじゃなくて、WebBeer APIみたいなニッチなものに使うんだろ？
＞ basic typeahead Appleの公式ドキュメントにはないかもしれないけど、Safari 12.2からサポートされてるよ。 動作が不安定な例もあるよね。最新のiOSだけど、ネイティブのdatepickerが起動したりしなかったり、typeaheadも安定しない。 デモを見ると問題点がよくわかるね。iOSだと”まあまあ”動くって感じ。 Safariは”新しい”IEだよ。もう10年くらいそうだけど。 マジそれなー。SafariがIEと違うのは、IEが昔めっちゃユーザー多かったからじゃん？ ほとんどのウェブサイトは別に何もしなくても見れるっしょ。 むしろChromeの方が変な癖があって対応が必要だったりするよね。 iframeだけの問題かもだけど、Chrome（というかBlink）でサードパーティCookieなしで動かすのめっちゃ大変だったわ。 ＞オートコンプリート機能も頼むわ ＜input type=“datetime-local”＞で自動でISO8601のタイムゾーンオフセットが付くのが欲しい！ ISO-8601は過去のローカル時間をシリアライズするには正しいフォーマットだけど、未来には向かないんだよね。 この場合、タイムゾーンを聞くことが多いかな。OSで更新されるデータだし。同じ場所にいてタイムゾーンが変わることは少ないと思うし。自分がメンテしてるソフトはログインが必要で、タイムゾーンを選べるようにしてる。それをUTCに変換して保存して、表示するときにUTCからローカル時間に戻してる。ユーザーがタイムゾーンを変えても大丈夫なようにね。 過去のことはそれでいいけど、未来のことはダメじゃん？ これ広くサポートされるまでが大変そう。caniuse.comだと今46%だってさ[1]。まだサポートしてないブラウザでもちゃんと使えるように、プログレッシブエンハンスメントとして使うのが大事だね。つまり、plain select elementにない機能を新しいスタイリングに入れちゃダメってこと！ま、それはいつもそうだけどね。でも、形になってきてて嬉しい！divのカスタムセレクトボックスより全然マシになるはず。😊 マジでそれな！めっちゃ改善だと思うけど、遅すぎだろって感じ。もっと早く実現してほしかったわ。 フロントエンドってマジめんどい。ここ15年くらい、JavaScriptフレームワークが幅きかせてて、フォームみたいな簡単なことでも使われてたし。Basic HTML/CSSが、JavaScriptなしでスタイル変えたいってニーズにやっと追いついてきた感じ。 JSとJSのコンポーネントが流行ってるのは、ブラウザベンダーが新しいHTML要素をなかなか作ってくれなかったからだよ。みんなが要望してたのに無視し続けてたんだよね。やっと出てきても、dialogとかdetails / summaryみたいに中途半端だったりするし。 ＞Even when they do arrive, they can be half baked - like dialog or details / summary - and that doesn’t help matters openとopenModalのAPIには癖があって、アクセシビリティのこと考えてないと気づかないかも。dialogの中だとフォームにも癖があるし。 ＞The biggest thing though, is for the life of me I don’t understand why you can’t open and close a dialog without JavaScript. There’s no way to do it. マジそれな…こういうのが欲しい。 ＞I’m with you… would be nice to have: JavaScriptなしでやりたいって話でしょ。 なるほどね。でも実際問題、 それ、もうすぐ来るよ！ ADA準拠を気にする必要があるなら（いつも気にしてるけど、いつもお金もらえるわけじゃない）、これは対応が難しいかもね。昔のOperaはHTML5要素のサポートが最高だった。特に日付/時間の入力はマジで最高だった（他のもほぼ全部良かったけど）。 usabilityとかwebのことちゃんと考えてたOperaが売られちゃったの悲しい。 ユースケースごとに新しいHTML要素を作るのは違うと思うな。HTML要素を拡張できるようにするべき。 ＞解決策はHTML要素を拡張できるようにすることだって？ 十分な数の人をハッピーにできるくらいのHTML要素は作れると思うよ。80%の人のために80%。 フォームってマジ難しいよね。一番ステートフルで、みんなが触るUIコンポーネントだから。HTMLには最低限のツールしかないから、最高のUXを提供するには足りないんだよね。エラー表示のタイミングとか、送信許可のタイミングとか、エラー状態の表現とか、もっと細かく制御したいじゃん？HTML以外でフォーム作ると、言語が変わるだけで、UXのこと考えなきゃいけないのは変わんないんだよね。 20年以上遅すぎだろ！ここ20年、JavaScriptなしでできることが少なすぎる。 画像で角丸が流行った後に なんかSafariって、iOSアプリに力入れたいからか、基本的なプラットフォームの改善を後回しにしてる気がするんだよね。 Safariは遅れてるしAppleはWebのこと気にしてないっていうのはもう聞き飽きたよ… Webの改善ペースって遅いよね。 えー、まだ標準規格ができて2週間しか経ってないじゃん。しかも、Appleの人が書いてるし。 確かにそうなんだよね。だから、ブラウザの新しい改善にすぐ期待しないようにしてる。でも、ブラウザの能力の進化を見てみると、驚くほどだよ。 Web開発の永遠の5年問題か。未来の標準規格に対応できる方法があればいいのに。 ＞まあ、それはいつもの良い習慣だよね。 おそらく、divベースのコントロールをページに残して、必要に応じて＜select＞ベースのコントロールを隠したり、ブラウザごとに異なるHTMLを生成したりするんじゃないかな。 的外れかもしれないけど、開発者はどのユーザーがアプリを使っているかを考えるべきだと思う。インターネット全体が対象なら、後方互換性を考慮する必要がある。内部アプリなら、気にせずに新しいAPIを使うのもありじゃないかな。 ＞組み込みのモバイルOSのコンポーネントが起動しないのが心配だなー。 base-selectを使う場合だけの話みたいだよ。使わなければ今まで通り動くはず。 ここで言う”You”はウェブサイトの作者のこと。ユーザー視点だと問題解決になってないんだよね。 Chromeはもうネイティブじゃないコンポーネントをたくさん使ってるし、Firefoxも似たようなもんじゃん？ ＞ChromeとかFirefoxとかがネイティブじゃないコンポーネントを使ってるってことは、OS標準のアプリとは違うってことだけど、ウェブサイト全体としては統一感が出るよね。 勘違いしてるみたいだけど、モバイルでのselectの見た目をウェブ開発者が自由に決められるようになるってことだよ。 スタイルを変えない方がいいコントロールもあるんだよ。スクロールバーを見てみろよ。細すぎて掴めなかったり、色のコントラストが悪くてどこを掴めばいいかわからなかったり、スクロールバー自体を消しちゃうやつまでいる始末。 今更でしょ。2000年からずっとカスタムselectボックスをハックしてきたんだから、牛が通った道を舗装するようなもんだよ。 それは違うな。うちのウェブサイトにはサイドバーとメインコンテンツがあるんだけど、サイドバーもメインコンテンツもスクロールできるんだよね。サイドバーは背景色に合わせて暗い色にしてるんだけど、背景が暗いのにサイドバーだけ白くてゴツいと見た目が悪いんだよ。 理想を言えば、ブラウザがもっとマシなデフォルトを使ってくれれば、こんなことしなくて済むんだけどね。Firefoxはそこらへん優秀だと思う。スクロールバーは控えめだし、コンテンツの幅に影響しないし、 これってselect optionsのためにもっとリッチなHTMLが使えるってことだよね。画像とか、2列の情報表示とか、フォントの太さを変えて追加情報とかさ。めっちゃ助かるじゃん。 いやいや、必要な情報をちゃんと伝えるべきでしょ。情報を制限するのは有害な場合も多いし、シンプルにするどころか逆に難しくなることもあるよ。一貫性も同じで、使いやすさを制限することがあるし。10色から選びたいときにスペースが限られてたら？色の見本があるselectが完璧じゃない？名前も添えれば最高じゃん？なんでテキストだけに制限されなきゃいけないの？ユーザー無視じゃん。 良い例だね。カラーピッカーなんて何十、何百通りも発明されてるのに、アプリごとにちょっとずつ違うから毎回考え込んじゃうんだよね。シンプルなselectで色の名前が表示されるのが一番だよ。色見本が欲しいなら、横に置いてselectのイベントハンドラで更新すればいいじゃん。 それって客観的に見て悪化してるじゃん。「blue」が何を意味するのかわからないし、青色なんていっぱいあるし。「悪くしたい」ってのは説得力ないよ。開発者がアプリのニーズを記述できる一貫した文法を提供するのは、不必要な発明でも複雑さでも摩擦でもないよ。 名前だけじゃ色が伝わらないって。赤だって緑だって何百種類もあるんだから。一つずつクリックして色見本を確認するなんて面倒だよ。色見本付きのリストにするのが一番簡単じゃん。誰も考える必要ないし。 Windowsには標準のカラーピッカーダイアログがあったの覚えてる？Windows 98とかViataのmspaintにあったやつ。何でも屋はどれも得意じゃないって言うじゃん。mspaintの専用パレットツールバーの方が直感的だった。 スクロールバーをウェブサイトから完全に取り除いてるのもあるよね。最悪なのは、hoverした時だけ表示されるカスタムJSのやつ。コンテンツを部分的に隠すし、ドラッグしようとしてちょっとでもカーソルが外れると消えて、下にある要素を誤ってアクティブにしちゃうんだよね。 小さすぎたり見えなかったりするスクロールバーが多くのブラウザでデフォルトになってるのが残念だよね。例えばLinux版のFirefoxとか、今使ってるんだけど。もっとコメントを表示（1）
完璧じゃないけど、datalist試したことある？タグピッカーについても全く同感。Bootstrapにタグセレクターコンポーネントがないのが残念だった。
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/da… の互換性を見て。iOSとMacの最新Safariでデモは動くよ。
「Safari推奨」は見ないけど、Safariで見れるように頑張ってるサイトは多いよねー。Chromeユーザーですらないけどさ。
Safariで見れないサイトはChrome独自の非標準機能使ってるだけだし。
Safari特有のバグがあるサイトはごく少数だよね。
もうすぐできるんじゃない？datalist要素を見て。
＞https://developer.mozilla.org/en-US/docs/Web/HTML/Element/da…
ローカルな日時ピッカーは未来の日時で使われることが多いと思う。
タイムゾーンオフセットじゃなくて、ゾーンIDが欲しい。そうすればバックエンドでdateとtzdataがうまく処理してくれる。
2028年1月7日の午後8時にニューヨークで何かしたいとして、その後NYCのDSTルールが変わったら、午後8時にしてほしいじゃん。
UTCに変換して戻すとその情報が失われて、違う時間になっちゃう。
[1] https://caniuse.com/mdn-css_properties_appearance_base-selec…
＞dialogとかdetails/summaryが中途半端ってどういうこと？details/summaryはスムーズなトランジションがないとか？dialogはJavaScriptなくても結構使えると思うけどな。
自分の場合は、date/time inputがマジ勘弁。FFだと時間のクリック要素すら表示されないし、手打ちしなきゃいけない。
一番意味不明なのは、JavaScriptなしでdialogを開閉できないこと。マジで方法がない。もっとコメントを表示（2）
＞popover使えばJavaScriptなしでできるよ。
dialog要素はopen属性でデフォルトで開けるし、dialogフォームメソッド使えばボタンで閉じれる。JavaScriptいらないよ。
dialog要素をJavaScriptなしで開く方法はまだないけど、command/commandforがHTMLの仕様に追加されたらしい。
＜button type=”open-dialog” target=”dialogId”＞Open Dialog＜/button＞
…
＜dialog id=”dialogId”＞
＜button type=”close-dialog”＞Close Dialog＜/button＞
＜/dialog＞
マジでそれが一番理にかなってる。
＞今すぐできるよ。
// 開くとき
＜button onclick=’document.querySelector(”#dialogId”).showModal()’＞Open＜/button＞
// 閉じるとき
＜button onclick=’this.closest(”dialog”).close()’＞Close＜/button＞
close()の結果を使えないのが問題なんだよね。ステータス返せるのに。
＞It would just make so much sense.
＞提案した方法も同じくらい理にかなってると思うけど。もし提案に問題があって、そっちの提案で解決できるなら教えてほしい。onclickでJS使うのと、他の属性使うのと、複雑さは変わんなくね？どっちも大差ないと思うよ。JSオフのブラウザだとonclickが動かないのはわかるけど、そもそもJSなしでダイアログ使うのは、ビルトインの開閉属性があってもUX最悪じゃん。
https://developer.mozilla.org/en-US/docs/Web/API/Invoker_Com…appearance: base-selectっていうCSSルールのおかげで、HTMLとCSSで＜select＞を拡張する標準的な方法ができたし（JSに頼らなくても、コマンドを宣言的に呼び出すことでインタラクションも拡張できる可能性もある）。
Appleにこれ実装させるのが解決策でしょ：
https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att…border-radiusが追加されたみたいなもんか。
Safari 18.4に関する8000字以上の記事（今日リリースされたばかり！）を読めば、Webを気にしてない組織が書いたものには思えないけどね。[1]
[1]: https://webkit.org/blog/16574/webkit-features-in-safari-18-4…
大企業が気にしてるかどうかは置いといて、90年代のUIフレームワークと比べると、開発者の体験は貧弱だよ。
HTML、CSS、JavaScriptが最良の道なのかどうかはわからないけど、30%も収益を奪うエコシステムに縛られない、もっと良いものが必要だよね。
一日一日が長く感じるけど、年月はあっという間だね。
色や形で情報を認識できない人たちのために開発することを忘れないで。メニューのスタイルに重要な情報を隠している場合、スクリーンリーダーを使っている人にはアクセスできない可能性があるよ。もっとコメントを表示（3）
＞”だって、あれって信頼性もアクセシビリティも高いし、レスポンシブじゃん？”
入力要素でAndroidのUIが開くと、使い慣れてて安心できるんだよね。selectとか日付・時刻入力とかもそう。
適当なウェブ開発者が作った実装が甘いコンポーネントは心配だけど、Googleならネイティブの代替を忠実に再現できるんじゃない？少なくともAndroidでは。
＞バラバラの人がdivとJavaScriptでバラバラな動きをするよりはマシじゃん。
確かにselectのデフォルトはダサいけど、ちゃんと仕事はするんだぜ。
それに、ユーザーとしてはスタイルを自由にselect要素に適用したいんだよね。他が全部スタイリングされてるのに、ダサいselectボックスが一つだけあるのは違和感しかない。
SVGとか複雑なDOM要素を入れられないのも問題だし。大抵のカスタムselectボックスはアクセシビリティを無視してるけど、これなら解決する。
サイドバーだってことはちゃんとわかるし、デザイン的にもこっちの方がいい。color-schemeにも対応してるし。
技術の文法、つまり開発者が創造するために与えられたビルディングブロックのセットは、柔軟性と表現力のある意図とのバランスを取る必要がある。CSSの＜select＞はいい感じにバランスが取れてる。含めるのを非難するのは、機能よりも批判者について多くを語ってる。
