URLが更新されないなら、それはボタンだと思う。URLが変わるなら、リンクにすべきだね。少なくとも、俺はいつもそうしてる。

ウェブアプリをナビゲートするハイパーリンクみたいなもの？ それって <a> タグのこと？

世界を見てると、理由の一つはボタンに変な見た目を適用しやすくするからだと思う。だから、ボタンとして機能しないだけじゃなくて、見た目もボタンじゃなくなっちゃうんだよね。

ところで、TV Tropesって知ってる？ あそこには長いリストがあって、1ページ内で「フォルダ」に分かれてるんだ。 その「フォルダ」をクリックすると展開したり折りたたんだりできるんだけど、これは「onclick」プロパティを使った実装で、内部には（昔はそうだったと思うけど、今は兄弟の子供みたいな感じだね）。

一番よく見る理由は、デフォルトのボタンスタイルをオーバーライドしなきゃいけないって愚痴だね。

そうだね。苦労して学んだよ、笑

彼らは送信動作を無効にする正しい方法を知らない。これはDIVの利点で、知らないからtype="submit"を誤って設定することがない。多くの人が知らないことはたくさんあるよね。DIVを使うと、空の状態から始めて、追加したい機能を明示的に加えることができるから、後でその機能を簡単に削除したり変更したりできるんだ。もちろん、HTMLの標準についての知識が豊富で、Buttonが現在のユースケースにぴったり合うなら使うだろうけど、デザインや要件は常に変わるからね。DIVを使うことでデザインがより透明になるし、属性を追加することで設定した機能が見えるようになる。Buttonを使うと、あなたやコードを読む他の人が、何をするのかを理解するためにドキュメントを参照したくなるかもしれないけど、DIV + 属性ならそれが明示的に「書かれている」んだ。いくつかの利点と欠点だね。

デフォルトは、のためのものであって、ではないと信じてる。

確かに、OPの長い愚痴は重要な情報を見逃してるね。デフォルトタイプのボタンは変なことをするから、確かクリック時のJSハンドラーをスキップしちゃうんだよね。

ここ数年でこういうことをする人が増えてるのを見たよ。フレームワークや無知、無関心が関係してるんだろうけど、昔ながらの方法がほぼいつも最高のUXを提供してくれる。タグの代わりにおしゃれにしようとした人には、軽い不快感と不便を願ってるよ。

昔、.netプログラミングをやってた頃、asp.netはナビゲーションをJavaScriptイベントで処理してて、それが全部壊れちゃったんだよね。ちょうどRuby on Railsが出る前だったから、今はもっと良くなってるかも。

そうだね！クリックできるなら、ボタンかリンクのどっちかにすべきだよね。

ああ、100%同意！最近参加したプロジェクトは、そこそこ複雑なReactのウェブアプリなんだけど、ナビゲーション要素が実際のリンクじゃないんだ。すべてonClickで処理されてて、概念的にはただのリンクなのに。なんでこんなことがウェブのフロントエンド界隈で広まってるのか全然わからない。

なんでブラウザは、クリックハンドラで発生するJSトリガーのナビゲーション（またはhistory.push）イベントをキャッチしないんだろう？そのクリックハンドラのイベントデータから、ユーザーが中ボタンを使ったりcmd/ctrlを押しながらクリックしたことがわかるのに、それを新しいタブでのナビゲーションに書き換えられないのかな。理想的には、呼び出し元が期待していたことと違うことが起こったとは気づかせずに。サイトやアプリの開発者が意図したこととは違うかもしれないけど、ユーザーが実際にトリガーしたいと表現しているのはその意味なんだから、ユーザーが望むことをしてあげればいいのに。ブラウザはユーザーエージェントであって、開発者エージェントじゃないからね。（「それはレイヤー違反っぽい」と言う前に—確かにそうだけど、その特定のレイヤー違反は、ほとんどのブラウザのJSエンジンが「ナビゲーション呼び出しのスタックにクリックイベントが含まれていない場合はポップアップウィンドウや新しいタブのナビゲーションを抑制する」ロジックをサポートするために既に存在してる。コードの見た目はもうお金を払って買ったものだから、できるだけその恩恵を受けるべきだよね！）

そうだね。Reactを始めた多くの開発者は、つまらない基本を学ぶことなく「楽しい」部分に飛び込んじゃったと思う。そして、その開発者たちが後に続く人たちに間違ったパターンや基準を設定しちゃった。私が覚えている限り、divをボタンのように装飾する必要があったのは、アコーディオンのトリガーが巨大なボタンで、渡されたものがその中にレンダリングされるときだけだったけど、トリガーのタイトルの右にアクションが必要だったんだ。でも、そんなのは超稀だよね。ボタンをネストするのは無効なHTMLだから、普通にボタンを渡すわけにはいかないし。確かにCSSで絶対位置を使うこともできるけど、それだとフローから外れちゃって、別の方法でハックすることになる。

あと、JSベースのスクロールはやめてほしい。中ボタンを押してスクロールすることが多いんだけど、そんなサイトが多すぎる。

これ、Office 365のMicrosoftのウェブサイトチェッカーを思い出させる。左クリックでリンクをクリックすると、ページが安全チェッカーでキャッチされる（でも半分は機能しない）けど、その後に進む。でも中クリック？安全なんてないよ。

もう何年も前から、画像ホスティングサイトはJavaScriptがないと画像を表示してくれないところまで来ちゃったよ。ほんと、ただのimgタグを使えばいいのに。

そうそう、「プラットフォームを使えばいい」っていうのがあって、HTML5が出た2014年頃からフロントエンド界隈ではよく聞くフレーズだよね。残念ながら、ウェブ開発のすべての部分で広まってるわけじゃないけど、確実に「正しい」やり方として見られてるよ。

だったら、要素がスタイルを適用できるだけだったらいいのに。例えば、日付ピッカーが最悪なんだよね。使いたいけど、JSベースのやつは避けたい。でも、クライアントが「見た目がダサい」って文句言うんだよ。

2010年にアプリを書いた時のことをぼんやり覚えてるけど、その頃はボタンをすべてのブラウザで一貫してスタイルできなかったんだ。Firefoxでは灰色のボックスだったり、他のOSの標準スタイルが使われたりしてた。どこでも同じように見せたかったら、自分たちでボタンを作らなきゃいけなかった。間違ってるかもしれないけど。

「フロントエンドを作るならCSSは知っておいた方がいい」って入れておくべきだったな。いいフォローアップだね。言ってくれてありがとう！

appearance: none はボタンスタイルをリセットするのにかなり効果的だよ。私は通常、ボタンのように振る舞いたいもの（フォーカス、アクセシビリティ、インタラクティビティが必要なもの）用に .unbuttonify クラスを作って使ったり拡張したりしてるけど、見た目はハンバーガーメニューのトグルみたいな感じにしてる。

スタイルリセットがどうやって要素を同じように動かすの？リンクはボタンよりもブラウザに組み込まれている機能が圧倒的に多いよ。

これ、LLMがコードを書くのは得意だけど、ソフトウェアエンジニアリングはあんまり得意じゃないっていういい例だね。

これ、もっと取り上げられてもいいポイントだと思う。リンクをドラッグしたいと思ったことはないけど、毎日のようにリンクの一部をハイライトしたり選択したりするのに苦労してる。

俺は変わり者かもしれないけど、リンクをドラッグするのが好きなんだ。そうすると、リンクをバックグラウンドタブで開けるからね。右クリックメニューもあるけど、サイトがイベントをいじってなければ、PC（Windows/Linuxなど）でAltを押したり、macOSでOptionを押したりすると、リンク内のテキストを選択できるんだ。

iOSで電話番号をコピーするのと同じくらい悪いね、電話をかけるんじゃなくて（Androidではどうかは知らないけど）。iOSが電話番号にかけようとするのが、ほとんどの場合自分がやりたいことじゃないから、すごくストレスなんだよね。

リンクを選択するためのブラウザ拡張があるよ。昔は「Select Like A Boss」って呼ばれてたけど、今は「Drag-Select Link Text」って名前になった。要するに、横にドラッグするとテキストを選択、縦にドラッグすると通常通りにドラッグ＆ドロップ、長押しするとリンク全体のテキストを選べるってわけ。

テキストを選択するのはほとんど不可能だよね。選択できないテキストはイライラするけど、最近「TextSniper」っていうmacOSアプリを見つけたんだ。それを使うと、マウスでエリアを選択（スクリーンショットを取るときみたいに）できて、その後OCRでテキストを読み取ってクリップボードに入れてくれる。これでGoogle Analyticsがまた使えるようになるかも。