CSSの新機能に海外エンジニア賛否「JSに近づいてる」
姉妹サイトの新着
Hacker Newsで、フロントエンド開発者Josh W. Comeauが書いた記事「The Future of CSS」をめぐるスレッドが盛り上がっていた。記事は主要ブラウザが仕様の優先順位を揃える「Interop」プログラムを紹介し、@functionによるCSS関数やlight-dark()、Anchor Positioningといった新機能を取り上げている。スレでは、vanillaのHTML/CSS/JSだけで開発を続ける層が「今のCSSは本当に書きやすくなった」と主張する一方、関数や@scope・@layerの追加でCSSがJavaScriptに近づきすぎているという懸念も噴出。印刷用CSSへの不満や、CSSより前に存在したマークアップ言語DSSSLの逸話まで話が広がった。
CSSの未来
出典: joshwcomeau.com / 元記事はこちら
できる限りフレームワークを使わずvanillaのHTML/CSS/JSで書くようにしてるんだけど、フレームワークしか触ったことがない人にどれだけ良くなったか説明するのは正直難しい。適切な道具を使うのは当然として、それでも書いてて楽しいんだよな！
>>3
それ！自分も何年も同じことやってる。知能のベル曲線ミームっぽい感じがする。左端と右端は『vanillaのHTML/CSS/JSだけで十分』って言ってる、みたいな。
それ！自分も何年も同じことやってる。知能のベル曲線ミームっぽい感じがする。左端と右端は『vanillaのHTML/CSS/JSだけで十分』って言ってる、みたいな。
>>3
どこがどう良いんだ？それはかなり無批判な意見だな。flexboxやgridあたりは複雑すぎると思う。『flexible divs side by side』でググってみろよ。まず2個から、次に5個に増やして、ちゃんと動く解決策を教えてくれ。
どこがどう良いんだ？それはかなり無批判な意見だな。flexboxやgridあたりは複雑すぎると思う。『flexible divs side by side』でググってみろよ。まず2個から、次に5個に増やして、ちゃんと動く解決策を教えてくれ。
>>3
おかしくなりそうだ。ReactやVueのフレームワークだって結局HTML・CSS・JSを使ってるんだぞ？コンポーネントのマウントやライフサイクル管理を助ける薄いレイヤーが乗ってるだけで、同じものを使ってるんだよ…
おかしくなりそうだ。ReactやVueのフレームワークだって結局HTML・CSS・JSを使ってるんだぞ？コンポーネントのマウントやライフサイクル管理を助ける薄いレイヤーが乗ってるだけで、同じものを使ってるんだよ…
先に言っておくけど、自分はCSSが好きだよ！なぜか昔からずっと自分にはしっくりきてる。5〜10年経っても一般に使われるかどうかわからない改善を、粘り強く進めている人たちには本当に敬意を持ってる。
>>6
ブラウザの更新がこれだけ活発になった今、5〜10年のスケール感はもう過去の話だよ。1年前に採用された機能が普通に使われているのをよく見る。
ブラウザの更新がこれだけ活発になった今、5〜10年のスケール感はもう過去の話だよ。1年前に採用された機能が普通に使われているのをよく見る。
>>6
LaTeXでテーブルをスタイリングするという無謀な挑戦をしてから、CSSをさらに好きになった。
LaTeXでテーブルをスタイリングするという無謀な挑戦をしてから、CSSをさらに好きになった。
CSSを触るのが好きな少数派の一人だと思う。しかも今の使い方は数年前とはまったく違う。CSSモジュール、変数でパレットを定義してダークモード用に切り替える…今は本当にいい感じで触れる。
>>7
グリッドとflexboxも、以前は厄介だったレイアウトの問題をたくさん解決してくれた。アニメーションのおかげでJSの出番も減った。CSSを『いいとこ取り』だけにしてもっと単純化してほしいとも思うけど、それは無理だろうとも分かってる。
グリッドとflexboxも、以前は厄介だったレイアウトの問題をたくさん解決してくれた。アニメーションのおかげでJSの出番も減った。CSSを『いいとこ取り』だけにしてもっと単純化してほしいとも思うけど、それは無理だろうとも分かってる。
>>7
自分もCSSを使うのが好きだよ。一番最適化されたアプローチだと感じる。でも、CSSにそれほど興味がない他のエンジニアが関わるプロジェクトになると、CSSをそこまで使うのは難しくなる。
自分もCSSを使うのが好きだよ。一番最適化されたアプローチだと感じる。でも、CSSにそれほど興味がない他のエンジニアが関わるプロジェクトになると、CSSをそこまで使うのは難しくなる。
>>7
light-dark()を使えばダークモード切り替えはさらに楽になるよ 🙂 自分も@scopeや@layerを:has()セレクタと組み合わせてよく使ってる。もう全然違うものになってるのに、大半の人はそれに気づいてないと思う。
light-dark()を使えばダークモード切り替えはさらに楽になるよ 🙂 自分も@scopeや@layerを:has()セレクタと組み合わせてよく使ってる。もう全然違うものになってるのに、大半の人はそれに気づいてないと思う。
自分だけかもしれないけど、ああいう提案は全部CSSを不必要に複雑にしてる（というかJSっぽくしてる）気がする。特に関数系の機能はね。以前、同じ著者がブログを動かすために10万行のコードを書いた記事を書いてたのを思い出す。https://www.joshwcomeau.com/blog/how-i-built-my-blog-v2/
>>9
Joshのブログは完全にオーバーエンジニアリングされてるのは覚えておいた方がいい。本人もそれは認めると思う。かなり複雑な自分のコースシステムと整合性を保とうとした結果で、ブログ自体も『ただのテキストページ』以上のものになってる。
Joshのブログは完全にオーバーエンジニアリングされてるのは覚えておいた方がいい。本人もそれは認めると思う。かなり複雑な自分のコースシステムと整合性を保とうとした結果で、ブログ自体も『ただのテキストページ』以上のものになってる。
>>9
ついにCSSでJSインタプリタを書くという夢を実現できる！;)
ついにCSSでJSインタプリタを書くという夢を実現できる！;)
>>9
これが残りカスなんだとしたら、もうネタ切れしてるように見えるな。
これが残りカスなんだとしたら、もうネタ切れしてるように見えるな。
Claude Codeでコードを読まずにWebアプリを作ってみた。『メニューとヘッダーに外側マージンをつけて、半透明でぼかした背景にして』みたいな指示をするだけで、想像どおりの見た目になった。
>>10
『Claude』が実際にCSSを書いてくれたわけで、それが成立するにはその言語自体が必要だってこと、わかってる？的外れなコメントだな。
『Claude』が実際にCSSを書いてくれたわけで、それが成立するにはその言語自体が必要だってこと、わかってる？的外れなコメントだな。
Joshがブラウザ同士の協調を褒めてから始めてるのに、紹介されてる機能が全部Chrome限定なのはちょっと変な気がする。まあ、将来こうなるかもという予告としてはいいのかもね！
>>11
この記事は特に『Interop』プログラムについて書いてるんだよ。各ブラウザが協力して特定の標準をすべてのブラウザに持ち込む取り組みのこと。（しかも私たちも投票で選定に参加できる！）
この記事は特に『Interop』プログラムについて書いてるんだよ。各ブラウザが協力して特定の標準をすべてのブラウザに持ち込む取り組みのこと。（しかも私たちも投票で選定に参加できる！）
『JavaScriptに慣れているなら、これは馴染みやすいはず。@functionで新しい関数を定義し、resultで戻り値を指定する』かつてはHTMLがコンテンツ、CSSがレイアウト、JSが『処理』だった。今はJSがコンテンツもレイアウトも処理もやって、HTMLがコンテンツとレイアウト、CSSがレイアウトと処理を担ってる。
>>13
その定義はちょっとズレてると思う。JSは『処理』のためのものじゃなかった。コード自体は目的のための手段に過ぎない。
その定義はちょっとズレてると思う。JSは『処理』のためのものじゃなかった。コード自体は目的のための手段に過ぎない。
CSSのinherit()を長いこと待ってる…とはいえ、それとCSS Functionsがかなりの量の面倒事を呼び込むのは認める。文書マークアップにおけるtransclusionや条件分岐みたいなものだね。Anchor Positioningは良さそうだし、そこまで重荷を背負ってる感じもしない。
>>16
https://caniuse.com/css-anchor-positioning
全ブラウザが少なくとも部分的にサポートしてる。自分も使ってるよ。
https://caniuse.com/css-anchor-positioning
全ブラウザが少なくとも部分的にサポートしてる。自分も使ってるよ。
CSSに関数を本当に求めているんだろうか？CSSがチューリング完全に達した時点で、もうその流れは決まっていたとは思うけど。/* 関数を定義 */ @function –gradient-to-transparent(–color, –direction: bottom) { result: linear-gradient(to var(–direction), var(–color), transparent); } こういう曲芸が要らなくなるように、JavaScriptとの統合をもっとうまくやればいいんじゃないか。
>>18
JavaScriptは色々と要求するものが多いから。仮想マシン、スクリプトの解析とか。ページに何かを表示する前にそれが必須になるのは後退だよ。
JavaScriptは色々と要求するものが多いから。仮想マシン、スクリプトの解析とか。ページに何かを表示する前にそれが必須になるのは後退だよ。
>>54
CSSがチューリング完全なら、それはパースなどを行う仮想マシンを持っているということになる。つまりそれとJavaScriptの違いは単に構文だけってことだ。（チューリング完全な言語ならどれも同じ）
CSSがチューリング完全なら、それはパースなどを行う仮想マシンを持っているということになる。つまりそれとJavaScriptの違いは単に構文だけってことだ。（チューリング完全な言語ならどれも同じ）
>>54
それ、昔あったよ。XSLTっていうんだ。Googleは自分たちでは実装できるほど賢くなかったか、10年前にフォークしたものを直すために誰かに金を払う気がなかったんだろう。
それ、昔あったよ。XSLTっていうんだ。Googleは自分たちでは実装できるほど賢くなかったか、10年前にフォークしたものを直すために誰かに金を払う気がなかったんだろう。
今でもtree shakeができない。これが自分の古いCSSファイルを怪物みたいに肥大化させる原因。みんなもう諦めてる気がする。
>>24
CSSモジュールを使えばできるはずだよ。でも普通のCSSだとほぼ不可能で、あるクラスやIDがどこで使われているか分からないから。
CSSモジュールを使えばできるはずだよ。でも普通のCSSだとほぼ不可能で、あるクラスやIDがどこで使われているか分からないから。
他サイトの新着
HTMLとCSSはbashみたいなものだ。もしどこにでもあるという事実がなければ、誰も使わないだろう。
>>30
どこにでもあるわけじゃないものを選ぶ理由は何？『どこにでもある』というのは、大半のケースでおそらく最も重要な特徴だと思う。
どこにでもあるわけじゃないものを選ぶ理由は何？『どこにでもある』というのは、大半のケースでおそらく最も重要な特徴だと思う。
>>31
純粋な疑問なんだけど、リアクティビティや状態管理についても本当にそれは成り立つの？もちろんvanillaでも技術的には全部可能だけど、ちゃんと分かってやらないとあまりサポートが手厚くないという印象が、自分が最後に見た時点ではあったんだけど。
純粋な疑問なんだけど、リアクティビティや状態管理についても本当にそれは成り立つの？もちろんvanillaでも技術的には全部可能だけど、ちゃんと分かってやらないとあまりサポートが手厚くないという印象が、自分が最後に見た時点ではあったんだけど。
>>59
最近自分が作る（個人サイトやプロジェクトの）サイトは、仕事やネットで見かけるものより大抵レスポンシブにできてる。モダンCSSを使って、スタイルシートの構成を少し工夫して、セマンティックなHTMLを使ってdiv地獄にしないようにしてるだけ。正しく使って、ちゃんと注意を払えばうまくいくもんだよ。
最近自分が作る（個人サイトやプロジェクトの）サイトは、仕事やネットで見かけるものより大抵レスポンシブにできてる。モダンCSSを使って、スタイルシートの構成を少し工夫して、セマンティックなHTMLを使ってdiv地獄にしないようにしてるだけ。正しく使って、ちゃんと注意を払えばうまくいくもんだよ。
>>59
1. vanillaで使えるツールが最近かなり良くなった。2. LLMのおかげでニッチなスキルや知識が手に入りやすくなった。SPAにも出番はあるけど、平均的なCRUDアプリは今はvanillaやHTMXみたいな軽量ライブラリでかなり十分に対応できる。
1. vanillaで使えるツールが最近かなり良くなった。2. LLMのおかげでニッチなスキルや知識が手に入りやすくなった。SPAにも出番はあるけど、平均的なCRUDアプリは今はvanillaやHTMXみたいな軽量ライブラリでかなり十分に対応できる。
>>38
そうそう、ページをちゃんと印刷できるようにしたいときはCSSが憎い。
そうそう、ページをちゃんと印刷できるようにしたいときはCSSが憎い。
>>68
『W3Cエディタードラフト』（それが何を意味するのかは不明だけど）としてページメディア向けのCSSの草案があるよ: https://drafts.csswg.org/css-page/
『W3Cエディタードラフト』（それが何を意味するのかは不明だけど）としてページメディア向けのCSSの草案があるよ: https://drafts.csswg.org/css-page/
>>83
皮肉なのは、CSSの古い先祖にあたるDSSSLがすでにプログラミング言語だったってこと。Schemeの方言だったんだよ。
皮肉なのは、CSSの古い先祖にあたるDSSSLがすでにプログラミング言語だったってこと。Schemeの方言だったんだよ。
>>87
そのDSSSLの構文は、個人的にはこっちの方が見た目がいいと思う。
(element doc (make paragraph font-size: 20pt line-spacing: 20pt font-weight: 'bold color: color-purple (process-children)))
もし別の歴史が選ばれていたら、ハイパーテキストとスタイルとスクリプトを全部ひとつの言語でやる世界線もあったのかもね。
そのDSSSLの構文は、個人的にはこっちの方が見た目がいいと思う。
(element doc (make paragraph font-size: 20pt line-spacing: 20pt font-weight: 'bold color: color-purple (process-children)))
もし別の歴史が選ばれていたら、ハイパーテキストとスタイルとスクリプトを全部ひとつの言語でやる世界線もあったのかもね。
この話題の背景と論点
記事が扱う「Interop」は、Chrome・Firefox・Safariなど主要ブラウザの開発陣が合同で毎年の実装優先項目を決め、開発者コミュニティの投票も反映させる実際の取り組みであり、単なる掛け声ではない。スレで挙がった@function・light-dark()・Anchor Positioningは、この枠組みで優先的に実装が進んだ機能にあたる。争点になったのは、CSSに関数定義が増えることの評価だ。レスで指摘されているように、CSSはgridやflexboxの組み合わせだけで理論上すでにチューリング完全に達しており、@functionの追加は「できることが増えた」のではなく「書き方の選択肢が増えた」という位置づけに近い。CSSが「JavaScriptっぽくなった」という評は、スクリプト実行環境を必須にしないままロジックを表現したいという設計上の制約から来ている点は、スレの中ではあまり触れられていない。
※本記事は海外掲示板 Hacker News のスレッド「The Future of CSS」から抜粋し、編集部で日本語に意訳したものです。訳文の責任は当サイトにあります。
この記事のリアクション
まだコメントはありません。