【知らないと損】現代HTML/CSSの今！あなたの常識は古いかも？
引用元：https://news.ycombinator.com/item?id=45056878
ネストが追加されたのは評価するけど、CSSは全体的に見て本当に変でひどい言語だと思うね。たぶん使い方が悪いだけかもしれないけど、複雑でめちゃくちゃだし、呪文を並べて動かす感じ。継承ベースのスタイリングシステムと、継承なしで内包だけするレイアウトシステムが組み合わさってる。スタイリングとレイアウトを結合したのは間違いだったし、根本的に壊れてるものに機能を追加しても直らないよ。
反対意見だね。CSSに関するこういう意見は、ちゃんと時間をかけて学んでない人、特にカスケードを理解してない人が言ってるんだと思う。何年も前に新しい実装のためにCSSの仕様を深く掘り下げたけど、マークアップのセマンティクスからスタイルを分離するという目的にはすごく良く設計されてると感心したよ。
記事の「CSSへの否定的な意見の多くは、使い方をよく知らないことから来ている。多くの開発者はJavaやTypeScriptばかりでCSSの基礎を学ぶのを飛ばして、理解してないスタイリング言語に文句を言う」ってのは、あんたみたいな人のことだよ。ちゃんと学ばないくせに知ったかぶるのは傲慢だね。
あの複雑さは全部罠だよ。ひどい設計に無駄に時間を費やした人だけが、他人が学ぶ時間のない秘密を握ってる。あの複雑さは時間とエネルギーを食うだけで無意味だ。CSSはひどい設計、ひどいドキュメント、秘密だらけのひどい代物だよ。
あんたも筆者も、すごく傲慢な言い方だね。CSSへの反感にはもっとちゃんとした理由があるんだ。IE11にはNested flexboxのバグがあったし、サポート終了は2022年だ。記事のNested CSSは2023年12月に出たばっかり。CSSは1996年からあるんだから、現状は改善されたけど、それまでの20年以上ひどかったことを忘れないでほしいね。
「IE11にNested flexboxのバグがあった。IEのメンテが悪かったからCSSが嫌い、ってのがまともな議論になるの？」
長い間、90年代後半からだいたい2012年くらいまで、IEが一番人気のブラウザだったんだ。IEで動かなかったら、それは“動かない”ってことだったから、IEに合わせて開発するしかなかったんだよ。
「スタイリングとレイアウトを組み合わせたのは間違いだった」って言ってるけど、UI開発したことある人なら、スタイリングとレイアウトは密接に絡み合ってるってよく知ってるはずだろ？例えば、文字列の長さ、サイズ、改行、マージンとかさ。ボーダーやパディングを変えたら、子要素のスペースも変わるじゃん。根本的に結合してるものをどうやって切り離すっていうんだよ？
じゃあ、あんたの提案はなに？
いちいちツールの細かいところまで何週間もかけて学ぶ暇なんてないよ。ただ使ってパッと終わらせたいだけなんだ。もしツールが直感に反して使いにくいなら、それはツールが悪いし、みんなが別のを探すのも当然でしょ。
Webのフロントエンドは一回捨てて、グラフィックアプリ向けに作られたシステムでやり直そうよ。HTTPは残し、HTML/CSSはPDFみたいにドキュメント用にしてさ。UIはRedLangやProcessingみたいにサクサク動くものが欲しいんだよ。開発者が大量のシムウェアをクライアントに押し付けるのはもうやめようぜ。
個人的にはCSSのカスケードが問題だと思うな。シンプルなドキュメントならよかったけど、アプリを作るようになったらもうカスケードが無限の頭痛の種だよ。今時のCSSモジュールとかTailwindとかって、まさにカスケードや詳細度の問題を避けるためにあるんだし。概念は難しくないけど、実際何百ものCSSファイルがあるアプリだと、もう地獄絵図だよ。
そうかもしれないけど、HTML構造とレイアウトを分離できるって考えがそもそも間違いだと思うんだ。特にレイアウトが親や兄弟を参照してる時とか。CSSの夢はスタイルと意味を分けることだったけど、結局HTMLが意味をなさなくなって全部divになった。CSSはサイトをドキュメントだと思ってた時代に作られたから、その概念自体が欠陥だったんだよ。だからReactとかJetpack Composeみたいな新しいフレームワークは、この分離をやめてスタイルをコンポーネントに直接入れるんだ。あれはUIフレームワークであってドキュメントじゃないって認めてるからね。全部プレゼンテーションだよ。
毎日何十ものCSSファイルと格闘してる俺が言うけど、問題はCSSじゃないんだ。作業をドキュメント化しない怠惰なデベロッパーが悪いんだよ。みんなが同じ仕様で作業してたら、一貫性のある信頼できる結果が出るんだ。デベロッパーが手探りで、数ヶ月ごとに車輪の再発明をしてたらそりゃ酷いことになるよ。
ツールをきちんと学ばないで、自分の怠け心を棚に上げてツールのせいにするってわけね。なるほど。
確かに俺もCSSの複雑な挙動をじっくり学ぶ時間はなかったな。カスケードとか詳細度みたいなカスケードプロパティはやっぱり最悪の機能だと思うよ。スタイルルールの全体像を頭の中で維持するのって難しいし、結局は試行錯誤になっちゃうんだ。結局CSSに変換されるたくさんの「方言」以外、誰ももっといい代替案を出せてないけどね。
結局、全部エッジケースだよ。
今のCSSは問題だらけだけど、もっと統一感のあるレイアウトシステムを設計して、CSSをコンパイル先にできないかな？今のプリプロセッサは、CSSの半端なアイデアの上にさらに半端なアイデアを乗せてるだけって感じだよね。
TailwindはCSSの問題をかなり解消してくれるから人気なんだろうね。レイアウトシステムってよりは、CSSの嫌な部分を減らしてくれる感じ。Reactの＜Flex＞とか＜Grid＞みたいな高レベルの抽象化でも、うまくいくかもね。
具体的な例とかあるの？
UI構築専用のネイティブフレームワークがいっぱいあるのに、Webフロントエンドがそれらを全部打ち負かしたってすごいよね。
ちゃんと学ばないで不満を言うのは、その人自身を物語ってる。間違ったやり方をしてツールを責めるなんて、一番傲慢な態度だよ。
Flexboxって、実際みんなが使い始めたのは2013年くらいからじゃない？2022年のIEのバグの話と2012年の話は関係ないと思うな。WDで2009年にあったのは知ってるけど、人気が出たのは2014〜2015年頃だよ。
CSSに文句を言う人って、ろくに勉強もしないで「オモチャ」扱いする人が多いってのが俺の経験。見た目が良くてメンテしやすいページを作るのって、バックエンドのコードを書くのと同じくらい労力と計画が必要なんだよ。
みんなCSSがどれだけ難しいかって過剰に騒ぎすぎだよ。昔も今も、技術は進歩してるのに、勉強を嫌がってネットで文句ばかり言う人の態度は変わってないんだよね。
ビデオゲームって、「お前が学ぶ努力をしてないだけ」じゃなくて、「俺たちのデザインが悪かった」って反省して、誰でも楽しめるように作り直したから良くなったんだよ。プログラミング言語もそう謙虚であるべきだよね。
CSS Zen Gardenは健在だけど、Webが出版プラットフォームとして盛り上がった時代は終わったね。今CSSを書くのはWebアプリの文脈で、Zen Gardenみたいなスタイルはむしろアウト。個人サイトはスパムやハッカー、ビットコインマイナーのリスクだらけだし、プレゼンテーションを自由にできないFacebookやTikTok、RedditみたいなSNSが主流になったってこと。MySpaceやLiveJournalみたいにCSSで遊べたSNSはもうないんだ。
もちろん、僕は怠け者だよ、なんで不必要な手間をかけたいんだ？もしツールが悪いUXで余計な労力を要求するなら、僕は別のものを見つける。使える時間は限られてるからね。もし他のツールがないなら、「そこそこでいい」仕事をして、もっと重要なタスクに移るよ。幸運なことに、Kritaの代わりにGimp、Cuda&OpenGLの代わりにVulkan、C++の代わりにRustみたいな代替品はよくあるんだ。
この記事の内容には共感するけど、「JavaScriptを望まないユーザーがいる」っていう価値提案は正直響かないな。僕はArchユーザーで、ブラウザスクリプトやWebクローリングもする「True Believer」だけど、これはかなりニッチなユーザー層の好みだよ。まるで「10%のユーザーがIE6を使ってる」時代の議論に逆戻りするみたいで、CSSが優位に立つ理由は、もっと説得力のあるところにあるはずだ。
ちなみに、僕はnoscriptを使ってインターネットを利用してるけど、完璧に使いやすいよ。JavaScriptが必要なサイトは、拡張機能から有効にするだけでいいから、いつも使うサイトで邪魔になることはないんだ。パフォーマンスやバッテリー、セキュリティにとってもかなり良い。一週間以上noscriptで生活してみたことある？きっとあなたの見方も少し変わると思うよ。ちなみに、僕はこのブログ記事の作者です。
もっとコメントを表示（1）
noscriptを使ってるってことは、結局大量のアプリを代わりに使ってるってことだよね？Windowsアプリ、iOSアプリ、何でも。でしょ？だって、FacebookやWhatsApp、BSky、Drive、CoD:BO6、その他諸々を使いたい（ただ見るだけじゃなく）んだから。そしてそれらは全部、同じプライバシーを侵害する力を持つ環境で動いてる（正直もっと危険なことも多い）。「noscriptを使え」っていうのは、結局「ブラウザを使わずにスマホを使え」って言ってるのと同じじゃない？何の意味があるんだ。（正直、この議論をしてる人のほとんどが最終的にこう認めるんだ。「no javascript」は「no Google」を意味してるだけで、彼らの目標はプライバシーなんかじゃなく、World Wide Webというプラットフォームを破壊してAppleの製品を優遇することなんだ、ってね）。
「一部のユーザーはJavaScriptを望まない」って？
その通りだよ、ほとんどの人が望んでないね。
Webユーザーの99.9%以上はJavaScriptなんて聞いたこともないよ。
僕はDiscordやBlueskyみたいなWebアプリではJavaScriptを有効にしてるよ。まだ訪れたことのないサイトでJavaScriptをデフォルトで無効にするのは、攻撃を受けるリスクを制限するのにすごく有効なんだ。Facebookみたいなサイトはあまり使わないから、同意した時だけJavaScriptを動かす感じ。もちろんプログラムやアプリは使うけど、攻撃を受けるリスクと脅威モデルは「ゼロかヒャクか」じゃないから、できるだけ安全にする方がいいでしょ。
でもさ、市場の決定ってミクロ経済的なものじゃないんだよ。もしみんながnoscriptをデフォルトで使うような世界になったら、誰もWebアプリなんて作らなくなる（だってプラットフォームがデフォルトで最悪になるから）。そしてみんなが、その時の支配的なベンダーのネイティブアプリを使うようになる。それって、プライバシーやセキュリティ含めて、ほぼ全ての指標で今よりずっと（はるかに）悪い状況になるんだよ。あなたの論理は「寄生虫」みたいにしか機能しない。ほとんどの人がnoscriptを使わないからこそ、あなたはそれを使って自分を「守れる」んだ。
僕にとっての魅力は、宣言的なCSSで数バイトでできることが、命令的なJavaScriptだと何行も書かないとダメで、変な挙動やフレームワークの互換性問題が減るし、Time-to-interactiveも低いことなんだ。noscriptの状況で動くのは、おまけみたいなものだよ。心の奥底では、DSSSLが恋しいな。
俺もnoscriptをほぼいつもオンにしてるよ。でもさ、JSがないと動かないものが結構あるんだ。GoogleやBingの検索、YouTube、Tor Browserじゃない普通のFireFoxだとDuckDuckGoすら動かない。Tor BrowserならDuckDuckGoは動くから普段はそれ使ってるんだけどね。JS必須の点滅広告とかあるサイトは、だいたいスキップしてるわ。
俺は個人的なthreat modelを持ってるんだから、“parasite”なんかじゃないよ。ブラウザのCVEsだって二桁ある人間だから、余計な注意を払うのは当然だと思うね。それにnoscriptってのは、JavaScriptが実行できないって意味じゃなくて、FlashやJava Appletみたいに同意が必要ってことなんだよ。あんたの議論は、noscriptユーザーがJavaScriptを全然使わないって決めつけてるけど、それは違うね。
90%なら信じるけど、99.9%はちょっと言い過ぎな気がするな。
「1週間noscriptで暮らしたことある？」って？俺はJavaScriptもマウスもなしで20年以上生きてるんだが。Webを始めた頃はJavaScriptなんてなかったんだよ。テキストを読んでファイルをダウンロードするのは毎年どんどん簡単になってるしね。普段はブラウザでHTTPリクエストすることは避けてるし、保存したHTMLをテキストオンリーのブラウザで読むこともあるよ。
あんたは平均的なユーザーがコンピューターについてどれくらい知ってるか、めっちゃ過大評価してると思うよ。
JavaScriptを使いたくないユーザーのことには軽く触れてるだけだけど、記事のほとんどはCSSの機能を紹介することに費やされてるね。パフォーマンス向上の動機も挙げられてるけど、動機付けの全体を深く掘り下げてないのは良いと思うよ。個人的には、技術を見せることに集中してる方が生産的だと思うね。
多くの人は膵臓がんのことなんて聞いたこともないだろ。それを説明して、彼らが納得するか見てみろよ。IEのJavaScriptは、多分、彼らのシステムを少なくとも何回も台無しにしてきたはずだし、彼らはトラッキングが何かも知ってるんだ。
「個人的なthreat modelを持ってるから“parasite”じゃない」って？違うね。もしみんなが君の「personal threat model」を持ったら、君が使ってるプラットフォームが死んで、noscriptの選択肢すらなくなっちゃうんだよ。だからこの比喩は的を射てるし、俺は主張を曲げないね。
Tor Browserって、めちゃくちゃ遅いんじゃないの？
noscriptを使ってる人たちをターゲットにするのは、あまり意味がないってのは同意するよ。でも同時に、あまり触れられてないもう一つの側面を強く強調したいんだ。つまり、コードを減らしてブラウザの機能をもっと活用するのは、とてつもなく価値があるってことさ！やることを減らしてブラウザに任せるのは、すごく良い結果をもたらすんだよ。
私はnoscript賛成派だけど、それはオタク界隈だけの話かもね。一般の人にはあまり響かないだろうし。個人的にはnoscriptに価値があると思ってるよ。記事はすごく良いのに、こういう些細なことで議論が盛り上がっちゃうのは残念だな。
FacebookやWhatsAppを使いたきゃJSいるって言うけど、俺はGoogleやFacebookみたいな巨大企業に縛られたくないね。Googleアカウントも持ってないし、AndroidからGoogleアプリも消してるよ。JSなしで平気な奴は、SNSやGoogleアプリなしでも生きていけるタイプだと思う。これは根本的に違う世界観だから、無理に分かり合おうとする必要もないんじゃないかな。
ad-techで働いてる奴らがいるってことだな！冗談は抜きにして、JSがない時代からWebを使ってる俺たちからすれば、JSなしでも問題なく動くんだよ。最近、SEOとか非JS向けに作ったルーターをReact用に更新したら、JSなしでもページ全体が見れるようになった。curlでテキストも画像プレースホルダーも表示できるし。JSなしのサポートってそんなに難しくないって！
もうそんな時代じゃないよ。JSがいらない時はすごく使えるんだ。Torで5MB/s以上のダウンロードも見たことあるしね。良くも悪くも、出口ノードは制御できないから、リセットしないと変えられないけど。一部のサイトはユーザーの場所を気にするから注意が必要だけどね。
誰にとって悪いって？エンドユーザーじゃないでしょ。彼らは使うなら一度許可するだけなんだから。ブラウザの通知とかマイクの許可と一緒だよ。もし全員がnoscriptを使ったら、たぶんインターフェースも許可フローみたいに変わるかもね。それに、みんなDiscordやSlackみたいな「ネイティブ」アプリを選んでるけど、あれってただのWebアプリのラッパーじゃん。スマホでも同じで、Twitter/XのネイティブアプリをWeb版より好むよね。でも、それでもWebアプリは作り続けられてるし、みんながnoscriptを使っても作り続けられるよ。
私は普段JavaScriptをオフにしてて、必要な時だけオンにするタイプなんだ。JSなしのメリットが大きすぎて、もう手放せないね。JS自体が嫌いなわけじゃなくて、プライバシー侵害とか、重すぎるページ、ロードの遅さとか、サイト側がユーザーにしてくる「嫌がらせ」が問題なんだよ。CSSだけでだいたいのことはできるし。JSをオフにするだけでページがめちゃくちゃ速くなるから、もっと多くの人にこの快適さを知ってほしいな。
noscriptで、インタラクティブな要素が必要な時にだけ許可する「オプトイン」の体験が気に入ってるよ。決済とかでたまにカクつくことはあるけど、もう10年くらいnoscript使ってるから慣れちゃったね。CPU食いまくりの広告とか、意味不明な動画広告に比べたら全然気にならないよ。
「ブラウザに任せればいい」っていうのは分かるけど、もしブラウザがそれをちゃんと、一貫性を持ってやってくれるなら、って話だよね。残念ながらそうじゃないんだ。ある環境ではマウスが動くと変な色のスライダーが飛び出してくるのに、別の環境では固定サイズの違う色のスライダーが出てくる。これじゃあ、統一感のあるデザインなんて作れないよ。
JSオフのメリットは大きいのに、最近のブラウザは無効化しにくいよね。Firefoxも昔は簡単だったのに、Googleの圧力で機能が削除されたんだろうな。JSなしだと広告がほとんど出ないし。AndroidならPrivacy Browser、WindowsやLinuxならPale Moonで簡単にオフにできるよ。HNみたいなテックサイトでこのメリットが語られないのは、JSで稼いでる人が多いからだろうね。
NoScriptを長年使ってるけど、’完璧に使える’ってのは言い過ぎだと思うな。HNやRedditで新しいサイトに行くと、JSなしじゃまともに動かないサイトが多すぎる。JSを悪者にしてCSSで何でもやろうとした時期もあったけど、大規模な開発だとそれぞれ得意なことが違うって気づいたよ。どちらも進化してるし、CSSでできることが増えてるのは良いことだね。
CSSの最悪なところは、多くの人がちゃんと学ぼうとしないで、たった一日使っただけで強い意見を持つことだよね。
20年前にCSSを学んだ俺から言わせれば、カスケーディング（継承）は最悪だよ。チームで開発してると、ある変更が全く別のところをぶっ壊す、みたいなことばかり。複雑なセレクタとか、もはや意味不明。シンプルなレイアウトすら昔は激ムズだったし、何でCascading Rulesなんてものにしたのか理解できないね。レイアウト組むのがフルタイムの仕事になるなんておかしいだろ。
俺はCSSのカスケーディングが好きだし、継承は’適切な場所’なら最高のアイデアだよ。CSSのカスケーディングはツリー構造だから、ドキュメントを解析するのにすごく合ってるんだ。人間も知識を整理するのにツリーを使うことが多いしね。ドキュメントとCSSは相性バツグンだと思うよ。
問題は、どのプロパティがカスケーディングするかしないか、全然分からないってことだよね。ブロック要素、Flexbox、リンクとか、特殊なケースが多すぎる。結局、試行錯誤で一番よくあるパターンを覚えるしかないんだ。
もっとコメントを表示（2）
30年前に学んだ時、CSSがこんなに普及するとは誰も思ってなかったよ。DSSSLとかJSSとか、他にも選択肢があったんだ。DSSSLはHTMLと同じSGML系、JSSはNetscapeが推してたJavaScript構文だった。ちなみに、JavaScriptってCSSより先にブラウザに登場してたんだよ。
俺もCSSを20年やってるけど、それって君のスキル不足じゃないの？
昔ポッドキャストアプリを作った時、CSSでフッターを’常に下部に表示’、’常に可視’、’コンテンツを隠さない’、’ハック不要’で実装しようとしたんだ。でも、結局無理だったよ。本当にひどいシステムだと思ったね。
挙げた条件のどれかを破らずにやるのは無理だよ。SOとかブログで提案されてる解決策は、コンテンツが多すぎると画面外に押し出されたり（条件2違反）、少なすぎると最後の要素の下に引き上げられたり（条件1違反）、絶対配置を使うとコンテンツを隠したりする（条件3違反）。結局、フッターと同じサイズの空要素を絶対配置で使うことになり、それがフッターの下をスクロールする要素になる（条件4）。Google Podcastsもそうしてたはずだけど、これってただのハックだよ。ページに犠牲になる要素を作らなくても、もっとシンプルな方法がありそうなもんだけどね。
隠したくないコンテンツに下パディングがあれば、フローティングフッターはその追加パディングの真上にくるはずだよ。さらに、FlexboxやGridを使えば、もっとうまく、ハックなしで処理できる。これって、CSSで見た中で一番複雑なことには思えないな。
それはもう俺の投稿で言及したハックのことだね。もしシンプルにFlexboxやGridで解決できるなら、自由に投稿してくれよ。
＞CSSの最悪なところは、多くの人が学習しようとしないことだ
20以上の仕様を全部深く学ばずにCSSを使うなんて、とんでもない！ひどい話だ！
ツールを使うのに問題があるなら、人じゃなくてツールの方を見るべきだよ。人は変わらない。バンドソーを使う人にもっと注意しろとは言わないだろ？安全機能を付けるんだよ。
もちろん、20年分の仕様を全部学ぶ必要なんてないよ。他のプログラミング言語やマークアップ言語と同じで、現代的に使うのに必要なことはいくつかあって、それ以外のことは時間をかけて覚えていけばいいんだ。
もし無謀な行動を示したなら、実際はバンドソーを使わせないだろ。
そうだね、でもそれは有能なプロに「もっと注意しろ」と言うのとは違うよ。事故は、個人にもっと用心深さを求めるんじゃなくて、事故が起こりにくいシステムを作ることで防ぐんだ。だからバンドソーにはガードとか他の安全機能が付いてるんだよ。
1時間くらいでCSSを効果的に使う方法が分からない人は”プロ”じゃないね。CSSはすごくシンプルで、すごくパワフルだ。みんなの理解が不足してるみたいだし、これらのコメントを見ると、意図的な無知に行き着くように思えるよ。
例えばJSみたいな他のプログラミング言語に対しても、同じ基準を適用する？
Of course. I think JS is full of mistakes. To be fair some of the more egregious ones have been fixed, but there are still plenty left.I’m a big believer in learning new stuff, when that stuff has lasting value. However it is far more efficient to fix things, a one time cost that benefits everyone, than to ask everyone to learn the quirks of a tool, a cost that is paid every time someone new comes along.
Are you implying that having both String.prototype.substring and String.prototype.substr is somehow confusing?JS is in general better because by the time it came out people knew what to expect from a scripting language.CSS didn’t really have a lot of earlier styling and layout languages to copy. Also the original vision was much more limited.
＞ Also the original vision was much more limited.Is this about CSS or JS (and things like Node)?
You don’t tell people to be careful when using a saw?!How about we do both? We expect people to be able to use the tools, you know, properly, and make sure the tools are well-designed?
＞ How dare people use CSS without learning in-depth all 20+ specifications! It’s an outrage!Is strange reaction to:＞ … then have a strong opinion after they were forced to use it for a day.There is not problem with using something without understanding all complex rules. Point is about forming strong opinion based on superficial knowledge.People are not humble these days.
I didn’t realize that nesting is official now, last time I checked it was still a proposal. Nice!CSS has a lot of weirdness but I feel like it’s been following the trajectory of Javascript toward becoming decent language. Flexbox and the :has selector, and now nesting, cover a lot of the pain points I’ve had over the years.
Two of those wishlists css features already exist as specs:＞ n-th child variableSee sibiling-index() and sibling-count() https://developer.mozilla.org/en-US/docs/Web/CSS/sibling-ind…＞ Reusable blocksSee @function and @mixin draft spec, https://drafts.csswg.org/css-mixins-1/ and https://css-tricks.com/functions-in-css/Both are available in chrome already.
Okay, but are those radio tabs accessible?I think that if you want to follow WAI-ARIA practices, the aria-selected, tabindex and aria-controls need to be updated via JS when the active tab changes? I’d love to be wrong about that.Accessibility is often an afterthought. And, sometimes there’s an assumption that by working with HTML/CSS directly, accessibility comes built in. Just Something to keep in mind when choosing an approach.
I think so?I am aware that people who read the blog might base parts of their websites on my examples, so I definitely want to make sure they’re accessible as to not cause a negative ripple effect on the web.I don’t have a background in accessibility, but I try to do the best I can. I try out what I make with various accessibility tools (e.g. keyboard navigation, screenreaders), and also read up on how things should be handled.For the radio tabs specifically - they are keyboard navigable, work with screenreaders, and follow the tabbing to content practice mentioned in the WAI-ARIA example[0].[0] https://www.w3.org/WAI/ARIA/apg/patterns/tabs/examples/tabs-…
Thanks! Sorry if I came off as brash, time has been tight recently. You’ve already put a lot of work into a very informative article, and it’s appreciated. The outlook is solid. I’d like to find an opportunity to revisit some of my own code with your writing in mind.Part of the reason for mentioning the radio-tabs is because I was working on my own implementation for a personal project a few weeks ago. My goal was specifically using the role=”tab”/role=”tabpanel” pattern, but my read of the guidance left me feeling like I was trapped with using JS to set those. Since it was timeboxed, I bailed out to augmenting it with JS for and moved on.My hope was maybe somebody on HN with more of a background on accessibility could interject some thoughts here.
