00:04
はい、11月9日は水曜日ですね。
遅刻は朝9時10分までしまいました。
朝からコーヒー飲みながらニュースを見てたんですけど、
気づいたら時間が過ぎてしまいまして、
こんな開始時間が後ろ倒しになりました。すみません。
おはようございます。ひめみのkeethこと熊原です。
では本日も朝活を始めていきたいと思います。
昨日までですね、5回にわたって、
デザイナーの奥山さんの講演の記事を読んでいました。
非常に刺激的かつ、興味深い言葉の数々が
散らばめられたと思うので、
今日はそこから別の記事を読んでいこうというところで、
久しぶりに技術記事ですけど、タイトルにあります。
CSSの命名規則の有効性みたいなところですね。
の記事を読んでいこうと思います。
どのように有効なのかというのと、
CSSもちろん当然完全に分離された設計に比べて、
命名規則によって設計された実装というのは
安定して稼働し続けるよという話をされているらしいので、
それをちょっと読んでいこうかなと思っています。
じゃあですね、早速入っていきましょう。
リンちゃんとKさんとワクワクさんと
たつや長谷川さんですね。アイコン変えましたね。
はい、おはようございます。
ご参加いただきありがとうございます。
タイトルにある通り、だらだら読んでいくので、
入体数50にいただければと思います。
では早速入っていきましょう。
CSSの命名規則が
Cascade LayersやWeb Componentsなどのある
2022年においても
CSSコードベースを設計する上でもっとも実用的で
賢明な選択であるということを思い出してもらうために
ここに来ましたと。この記事を書いてますと。
前回私はショップトークショーのポッドキャストに出演して
大規模なコードベース全体で
CSSを拡張したい場合に理解すべき基本的な
メンタルモデルについてというのをお話ししたそうですね。
そのポッドキャストのリンクもこの記事内に貼られているので
後ほどこの記事をシェアしますので見てみてください。
見てみるというか、ポッドキャストに聞いてみてくださいという感じですね。
じゃあ早速入っていきましょう。
一つ目はですね、アプストラクションvsアイソレーションですね。
いわゆる抽象化か分離かというところです。
まず推測してみますと
完全な分離、いわゆるECSSとかBEMとか
CSSモジュールとかなどと
完全な抽象化、いわゆるACSSが提唱し確立し
テールウィンドウなどが反復してきたみたいなところですね。
の連続体というのを想像してみてください。
早速言葉が難しい。
私はこの連続体のどちらの端にいることが拡張性のある
CSSコードベースを作成する最良の方法であるかどうか
というところですけど、連続体の方が私は
ベストの方法だというふうに確信をしていますと。
私が言いたいことを老練な
クリスコイヤーさんという方が要約してくれているそうです。
ACSSもそもそもよく分かっていないんですけど
ACSSというのは
アトマイザーアイザーアンポスティック
CSSだと
03:02
アンオプショネイティッドCSSか
というのをACSSという言葉があるらしいですね。
僕今初めて知りましたけどね。そんなのあるんや。
しかもこれはちゃんと公式サイトも用意されていて
ライブラリーみたいなもんですね。
不勉強です。申し訳ない。
ちょっと続けていきましょうか。
どの方向に石を投げても10個のCSSの方法論にぶつかるでしょう。
もしあなたのものがそうであっても気を悪くしないでください。
私は自分のACSSの方法論も含めて
そういうふうに言っています。
私の知る限り全てのCSSの手法というのは
この連続体のどこかに位置します。
そのどっちかの端に位置していて
それはよりシンプルなものですよというふうに仰っています。
連続的というのはさっきの通りで
完全な分離なのかそれぞれの連続体なのかというところが
この記事のセクションのタイトルにありますけど
抽象化か分離かというどっちかに偏るというか
寄っていくよということだそうですね。
続いてのセクションがWhy I Prefer the Pollsですね。
私が極というものを好む理由だそうですね。
極とは何ぞやって感じですけど入っていきましょう。
ACSSではクラスを何かに適用すると
コンテキスト構成要素その要素と
構成要素の関係というのを教えてくれます。
またそのクラスというのはユニークであるため削除が容易になります。
この命名規則というのは一見すると
地味なセレクターのために大変なことをやっているように思えるかもしれませんが
実はそれだけなんですよ。
抽象化というのはその逆も同様に説得力があります。
それは何をするかということ以外の意見を提供しません。
そのアプローチは私の好みではないですけど
私はその有効性というのは評価はしていますし
他の多くの人、他のほとんどの開発者の方向に出ようと言ってくださいと
もそのアプローチを好んでいますと言っています。
それ以外のものは連続体の中間に位置するため
文脈や適用性、実用性などを伝えるには
いくつかの方法のうちの一つを用いなきゃいけないと。
スタイルのレイヤーのようなコンセプトというのは一般的です。
あるものは特定のセレクターの命名規則を使用し
あるものはそのセレクターが存在するファイル名を使用します。
もし極端な分離や抽象化が
あなたに合わないのであれば
この中間領域にあなたに合うものがあるはずです。
この記事はそれぞれの利点を議論するためのものではありません。
どちらを選んでもそれがあなたのためになるんだったら
もっと力を発揮してくださいと。
最近の言語への追加機能というのは
この中間領域で大いに役に立ちますよと。
今はブラウザのサポートが問題ですけど
いつの間にかプロジェクトで
カスケードレイヤーを合理的に使えるようになるでしょう。
今すぐには進められない理由というのは
簡単にポリフィールライブラリーにならないからですと言っています。
しかしたとえサポートが行き渡っていたとしても
サードパーティーのコードを制御するような
用途は得意ですけど、自分のCSSを整理するのに
06:01
CSSのクラス名の命名規則があるおかげで
根本的に私は抱えていない問題を回帰してくれるからです。
というわけで私が分離派であることは
以上から確かですよと。
ウェブコンポーネンツのように
本物のビルトインCSSの分離が可能であれば
CSSの命名規則も不要になるんじゃないのと
私はそう思っていました。
しかしウェブコンポーネンツを数年使ってみて
自分で分離する方の方向に走ったんですね。
この方は。
一応注釈文じゃないですけど
CSSのスケーリングドアというのも一応書いてますね。
たくさんのコードとたくさんの開発者
あなたのCSSの書き方は今後5年間で数百人の開発者が
CSSに触れても大丈夫でしょうかと。
こんなことを考えてCSSを書いたことなかったですね。
5年間で数百人の開発者がCSSに触れても大丈夫か。
100以上あるコンポーネントの1つを削除しても
他のコンポーネントに悪影響を及ぼさないという確信があれば
簡単に削除できますかと。
これこそがスケーリングCSSの確信になると。
繰り返しになりますけど、私は2014年に始めた
私自身のアプローチを詳しく説明しました。
当時はうまくいったけど今もいっていますよってことですね。
今後もCSS界隈の方でシンギュラリティとか
でかい変更がない限りは続くんじゃないですかね。
続いてウェブコンポーネントのセクションです。
これはちょっと短いですね。
ウェブコンポーネントですけど、
CSSとウェブコンポーネントについて2つの問題を話したいと思います。
まず要素には意見がないわけではありません。
要素、エレメントですね。
ブラウザーがどの要素に対しても持っているものと同じ意見を持っています。
そしてそれは作成する全てのコンポーネントに対して同じです。
コンテキストが難しい文章だなこの人。
難しい文章だなこの人。
特にアプリケーションを構築している場合は
ほぼ間違いなく望まないデフォルト値で始まります。
これはブラウザーのデフォルトの話かな。
PタグだったりH1、H2などのデフォルトのマージンだったり
ボタンなどのあらゆるフォントも同じです。
そのため全てのコンポーネントは何らかのリセットが必要になる傾向があります。
ウェブコンポーネントが本来持っている分離性というのは
モロハの剣です。
確かに外側のスタイルが入ることもできませんが
グローバルなものを取り込むこともできません。
それを魅力って感じる人はウェブコンポーネントを使うんじゃないですかね。
リセットCSSもいろんなブラウザに対応するようなやつ。
いろんなやつもありますけどね。
スタンダードCSSとかあるし
最近はレスだったり
いろんなリセットCSSがたくさんあってそれぞれに特徴があるんですけど
だいたい各ブラウザとか端末に応じた
落とし所みたいなCSSになるような気がしますけど
完全にガッとブラウザがデフォルトで持っているCSSを
全部クリアにするみたいなリセットCSSもあって
ウェブコンポーネントを好む人はそういう方向に行くんじゃないかって
今読んでて思いました。
09:00
で戻りますね。
各コンポーネントがリセットを必要とするため
多くの被害化につながることは想像に難くありません。
ありがたいことにこのトンネルの先には光があります。
サファリアフォックスはこの問題が解決されるために
コンストラクタブルスタイルシートを実装しています。
唯一の欠点というのはウェブキットサファリがまだ実装しないことです。
サファリ16で確か
この辺ちょっと着手したような気がしますけど
コンストラクタブルスタイルシートに関して
前ブログ読みましたけど言及してなかった気がするので
サファリ16でもまだ実装されない気がしますね。
ただ違うCSSが入るのは知ってますけどね。
私がウェブコンポーネンツを扱うのに好んで使っている
Litですね。Lit HTMLのようなものはこの問題は処理してくれますけど
注意しなければならないこともあります。
Litね。この人Lit使ってるんですよね。
僕Lit全然使ってないわ。
そもそもウェブコンポーネンツでアプリを書いてないっていうのがありますけどね。
このようなことを提案するために一周を開くことを考えました。
メタプロパティーイコールデフォルトスタイルで
バリューイコールアンセットみたいなのを
使えるようにするというのをヘッドに追加して
デフォルトのユーザーエージェントスタイルというのは
全て無効にすることもできますけど
そんなのあったんや。バリューアンセットってあったんですね。
メタタグの中に。全然知らんかった。
過去にこの種のことを実験して
おそらくコンストラクタブルスタイルシートというのが
最善の解決だというふうにはこの方は最終的にたどり着いた
ということだそうですね。
今のが1個目の一周ですと。
2つ目の一周ですけど
僕の手元の翻訳が遅いと。
2つ目の問題というのは理解力の問題ですと。
私が手がけるのはほとんどアプリケーション的なもので
ドキュメントではありません。
コンポーネントの各ノードはそれぞれ異なることをする傾向があります。
そのためクラス名を放棄してしまうと
すぐに使えるhtml要素というのがなくなってしまいます。
pタグ、bタグ、span、em、itag
を使い切った後は厄介なことになります。
というのも純粋にスタイリングフックとして別のhtml要素を
追加することになり実際の使用目的とは本質的に
ほとんど関係ない要素になってしまうからです。
だから3回くらいノーと言わなきゃいけないよと。
また既存のhtml要素を元にしたものも
結構便利ですよと。
ボタンとかダイアログというものは無料で多くのことをやってくれているので
それらを作り直そうとするのは無駄なことでしょう。
だからwebコンポーネントをスタイリングフックとして使う場合
必然的にスタイリングのために
要素に追加のフックが必要になります。
つまり新しい要素とそれを状況に応じて制御するクラスという
2種類のスタイリングフックが存在することになります。
クラスを使用する場合は
1つだけで良いと。
CSSのクラスの命名規則というのが勝りますよという話ですね。
複雑度は結局増しちゃうので
それだったらクラスで集約する方が何やかんや分かりやすいかもしれないですね。
12:02
やりたいこと次第というのはもちろんあると思いますが
僕はちなみに
クラス名の命名規則でやる方が好きですね。
もう1つ注釈ですね。
またDOMの要素を調べてコードベースからそのクラス名を
グレップで探せるようにしたいと。
ECSSのようなものを使うと1対1の対応になります。
スタイルとマークアップ、リットの場合はテンプレートリテラですね。
の間で1対1の対応付けが行われます。
そういう顔のない要素ですと。
全てを構築している場合は目的のものを見つけられると良いですねということです。
確かに検索性は結構重要で
ちゃんと1対1だというところはかなり良いかもしれないですね。
そのためにクラス名が長くなるというクラスの命名規則というのは
いまだにWebを使いたくなるときはしょっちゅうありますが
まあまあ難しいですね。CSS in JSもあるし今は。
なかなかそれでやるかというところも別の議論もあるかもしれないけど
この記事中にCSS in JSについて
言及されるかちょっと分からないですね。
続けていきます。
続いてプロトタイピングとオンボーディングの迅速化と簡便化だそうですね。
CSSクラスの命名規則により
プロトタイプを簡単に作成することができます。
生のより意味的に適切なHTMLとCSSで
コンポーネントをスタブ化して
必要に応じてそれをウェブコンポーネントのようなものに移行できます。
これは最初から制作に役立つコードなんです。
どのエディターやIDを開いてもCSSとHTMLを理解することができます。
これは余計なお世話かもしれませんが
新しい開発者を仲間に加えるのは最初から貢献できるからこそ
より簡単なんですよと。
オンボーディングってまさにそういうところですよね。
そのためのプロトタイピングは結構大事ですね。
一方で現場がそんなことを考慮できたりするか
また別の話はありますし
発注側からするとそんなに関係ないですからね。
次でラストですね。すみません。
もうサマリーが決まりました。
まとめです。私はここでCSSの命名規則を使うことが
唯一の方法であると言いたいわけではありません。
むしろこのようなことをよく考えてほしいんです。
私たち仕事上ウェブデバイス業界のイルミナティ
イルミナティってなんだ?
イルミナティたちが前を潜めるような決定とか
技術的な選択をしてきましたと。
しかしそれは私たちにとって正しい選択だったのです。
私たちの製品、私たちの開発者のためにそれは必要だったと。
ですからあなたのCSSコードベースを設計することになったとき
もうそらかあなたはいくつかのアプローチを
試したいと思うでしょうしそうする必要があるでしょう。
そしてそれをしばらく使ってみてください。
そしてそのメリットデメリットを分析するのです。
これでも結構いいことを言っていて
いろんなメリットデメリットを各ブラウン
いろんな開発者もそうですし技術ブログもありますし
いろんなライブラリーのところで自分たちの良さというのがバーっと
トップページに出てまして他のやつと比較するとき
15:01
僕らはこういうメリットがあるって書いてあるんですけど
やっぱり書いてみないとわからないですね。どんな技術とかライブラリーもそうですけど。
便利なのがわかったしこれが解決する問題をこういうことっていうのも
地面から読んでわかるけど実際に開発するときに
これとこれを組み合わせたりとかこういうケースでこれに
アデハムエルと意外と落としはないよねみたいなのがたくさんあるので
結果ちゃんと使わないとわからないので使って評価をしましょうっていう
この一言はかなり僕はいいなと思いましたね。
多くの人っていうのは
完全な抽象化の道を歩んでいますと。
その昔スウェリー
コブレンズさんとヤフーチームっていうのが
ACSSとして提唱して今では無数の人が
それを主張しテイルウィンドウで結局一般化していますと。
テイルウィンドウは確かにある意味で一般化したものですよね。
UTTクラスの塊ですからね。
それはそれで一つの思想であって
これだけ流行ったっていうのはそれだけ汎用性も高く
使いやすく捨てやすいってところが結構大きいかもしれないですね。
その代わりアトリビューツめちゃめちゃ長くなって
結果的に1位になるっていうのはいいかもしれない。
ただ検索性悪いと僕は思いますけどね。
それを良し悪しどこで取るかっていうところはありますが
余談でした。
CSSモジュールを使っている人もいますと。
これは命名規則と同じことを自動的に行うものです。
唯一のトレードオフっていうのはツール化の必要性です。
他の人は全く別の方法を選ぶっていうこともあり得ると。
この会社の場合
私は手動によるCSS命名規則に一応こだわっています。
この10年間でツールは登場しては消え
フレームワークやライブラリーは日の目を浴びて
カスケードレイヤーのような全く新しい可能性が
Webプラットフォームで一応実現されてきました。
しかし優れたCSS命名規則から享受してきた有用性と
回復力というのは全然衰えてもいません。
というわけでもしかしたらECSSのようなものが
あなたにぴったりはまるかもしれませんよっていう問いで最後は終了しています。
という感じでした。
ちょっと短いですけど言いたいことはよくわかったし
でもこの記事は今年の4月なのでちょっと古くなり始めたかなみたいなところですけど
ただ設計の話なので
この先も同じような議論はずっと続けられると思うし
ECSSのようなものが今後も議論され続けるのはあると思いますね。
古来からの方法ですけど
言うてなんやかんや
全世界に使われているのは事実としてあるのでね。
最初からハイコンテキストな会話で
CSSに関してかなり
物事を知っている前提で書かれている気がするので
僕は途中ついていけなかったのもあるんですけど
温めてみなさんの方でも読んでもらうのがいいかもしれないなと思いました。
というところで30分になりましたし
今朝は僕が寝坊したので
後ろ倒ししてもいいんですけど
他の記事ですよね。ちょっと読んでみようかなと思ったやつ。
もう一個はウェブデザインにおけるコントラストの検証方法という
ウェブデザインのテストについての記事と
あとはやっぱり
18:02
リアクトですね。
リアクトは一世風車だけど
今はリアクトを手に負えなくなっているんじゃないのっていうような
感覚的な、感情的なブログがあって
それはちょっと読んでみたくなったんですけど
時間がオーバーしそうなので
これで朝勝ち終了しようかなと思っています。
また明日もゆるく何か読んでいこうと思いますので
興味あればご参加いただければ幸いです。
この記事は後ほどTwitterでシェアするので
改めて見てみてください。
今日もご参加いただきありがとうございました。
水曜日ですね。1週間お折り返しですけど頑張っていけたらなと思います。
それでは終了します。お疲れ様でした。
