原子CSSの作成：ティエリー・コブレンツとのインタビュー

この記事は、Atomic CSSの作成者であるThierry Kobleentzにインタビューし、この人気のあるCSSフレームワークの背後にある歴史とコンテキストを詳細に見ていきます。ティエリーは現在引退しており、大規模なCSSSを書くのに豊富な経験を持ち、Yahooでフロントエンドエンジニアとして働いています。

Thierryは、Smashing Magazineでの2013年の古典的な記事「Challenging CSS Best Practices」の原子CSSの概念を主流にもたらしていると広く見なされています。この記事では、長年にわたって多くの人気のあるCSSライブラリの道を開きます。このインタビューでは、ティエリーは原子CSSの歴史をレビューし、進行中の影響を反映しています。

21世紀初頭に戻って、どのようにしてWeb開発の分野に入りましたか？特にCSSを書くことでどのように生計を立てましたか？

Thierry Kobletz： 1997年に米国に引っ越した後、私はHTML、CSS、JavaScriptを趣味として学びました。

当時、私はFrontPageを使用していて、ガイダンスのためにニュースグループに大きく依存していました。私はすぐにMacromedia News-GroupsとCSS-Discussの通常の顧客になりました。早い段階で、Web Standard Project Philosophyをサポートし、アクセシビリティに大きな関心を寄せました。何年もの間、フロントエンドは私にとって単なる趣味でした（私の本当の仕事はアンティークのディーラーです）。私は時々ウェブサイトを作成しますが、私は主に私が学んだか「発見した」テクニックを共有する（多くの）記事を執筆と公開しています。

これは、2007年にYahooの呼びかけが報われ、Yahoo!のStyleSheet（YSS）のWebサイトビルダーテンプレートを修正して構築できるかどうかを尋ねました。職務記述書：HTML、JavaScript、CSSのみ！そしてたくさん！

Yahooでのあなたの毎日の仕事は何ですか？

TK： Yahooでの私の役割は長年にわたって大きく変わりました。

私の最初の仕事は、YSSテンプレートのスタイルシートを作成することでした（CSS Zen Gardenに似ています）。その後、YSSがバンガロール（インド）に「配信」される前に、YSS Webサイトのマーキングとスタイルを書き直しました。そこでは、同僚と「知識移転」のために送られました。

ちなみに、スタイルシートを置き換えて、YSSのさまざまなデザインを作成することで、軽量（非JS）ソリューションを見つけて、「ビデオの本質的なスケールの作成」を思いついた方法です。

YSSの後、私はゼロから始まるプロジェクトにのみ参加する機会がありました（書き直しなど）、Yahooのフロントエンド作業にますます関与しています。多くの内部文書を作成します提案。

Yahooでの私の8年間で、おそらく100行のJavaScriptコードがなかったという別の追加メモです。私が辞めたり、解雇されなかった場合、リンギャン・ズーとレナート・イワシマのおかげです。

当時の人気のあるCSS執筆練習は何でしたか？

TK：初期には、ライブラリも公開された方法もありませんでした。それはすべて、「非セマンティック」クラス、ID、CSSハック、条件付き注釈、フレームワーク、CSS式、「JSプロービング」などです。私の古いサイトで、私はこのようなコメントさえ持っていました：

<code></code>

すべてが公正な競争であり、すべてが非常に限られているツールセットしか持っておらず、多くのことをしなければならないため、すべてが乱用されます。

しかし、私がYahooに参加したとき、状況は劇的に変わりました。英国の開発者は、Web標準の堅実な支持者であり、YahooのHTMLとCSSがどのように書かれているかに大きな影響を与えてくれたことに感謝します。セマンティックタグ付けは現実であり、CSSは懸念の分離の原則（SOC）に従って書かれた「T」です（ただし、私にはあまりにも熱心ですが）。

YuiにはCSSコンポーネントがありますが、CSSフレームワークはまだありません。内部CSSライブラリ（LEGOと呼ばれる）がありますが、私はそれを使用したことがありません。 OOCS、SMACSS、ECSS（Benへの敬礼）、BEM、ブートストラップ、純粋な方法およびその他の方法とライブラリがまもなく表示されます。

原子CSSのアイデアはどのようにして生まれましたか？

TK： YSSがインドに移る前に、マネージャーのマイケルモンテサノは、スタイルシートの編集を避けるためにバンガロールにチームを獲得する方法があるかどうかを尋ね、それにより損害のリスクが低下しました。 YSSテンプレートの経験（有料の顧客は、ページが破損していると不満を言う）により、スタイルシートに変更を加えると非常に妄想的になると思います。

したがって、EZ -CSSライブラリの精神で、「功利テーブル」を作成しました。これは、スタイルシートにルールを編集したり追加したりせずに、開発者がスタイルを実装できるように設計されたテーブルです。

数年後、Engineeringの当時のマイケルディレクターであるマイケルは、Yahooのホームページをユーティリティクラスを使用して再設計できるかどうかを尋ねました。セマンティッククラスよりもユーティリティクラスの優先順位付けについて議論しましたが、そのレベルでは当時は存在しなかったとは思いません。これは非常に大胆な動きです。

この大規模なエクササイズはすぐに概念実証となり、タグを使用したスタイリングの多くの利点を示しました。それは非常に多くの箱をチェックしたので、私たちはその「静的」スタイルシート（ステンシルと呼ばれる）を使用して私の家庭製品を再設計することにしました。

原子CSS（ACSS）を設計する際に従うべきガイドラインは何ですか？誰が関与していますか？

TK：私たちのステンシルライブラリは静的であり、デザインスタイルを実施するための優れたツールです。Yahooはすべてのプロパティでこのスタイルを採用しようとしていると思います。私たちはすぐにこれが起こらないことに気付きました。各Yahoo Designチームは、完璧なフォントサイズ、完璧なマージンなどについて独自の意見を持っています。

この状況は維持できないため、創造的な方法の原子性を尊重しながら、開発者がその場で独自のスタイルを作成できるツールを開発することにしました。これがアトマイザーの生まれの方法です。スタイル（CSS宣言）の追加を停止し、代わりに、開発者にメディアクエリ、子孫セレクター、擬似クラスなどの幅広いスタイルを開発者に提供するリッチな語彙の作成に焦点を当てました。

ACSSを使用すると、開発者は好きなものを自由に使用できます。そして、開発者が使用してきたスタイルには、いくつかの新しい直接的な利点があります。彼らはもはや自分のスタイルがページを壊すことを心配する必要はなく、コンポーネントをスタイルするためにセレクターを書くことを心配する必要もありません。

ACSSはもともと、Yahooの問題を解決し、Yahooの環境で働くために建設されました。

原子CSSに関与している人々には、レナート・イワシマ、スティーブ・カールソン、私自身が含まれます。レナートとスティーブはアトマイザーを作成しました。

人々が大企業のためにCSSを書いていない場合のCSSについての誤解は何ですか？

TK： 2007年にYahooに参加したとき、コードベースがどれほど巨大であるかをすぐに学びました。 There are teams across many locations/time zones; countless products; hundreds of shared components; third-party code; A/B testing strategies; as a requirement extension; different scripting directions; localization and internationalization; various release cycles; complex deployment mechanisms; a large number of metrics; various legacies; strict coding standards; construction processes; politics; and more politics; and so on.

これのほとんどは私にとって真新しいものであり、CSSの書き方にそれがどのように影響するかどうか、そしてどのように影響するかを学ばなければなりません。私にとって一般的な慣行である多くのテクニックや方法が適合していないように見える、または少なくとも複雑なアプリケーションに逆効果になるため、私はすべての信念を再訪して挑戦し始めました。

「リアリティチェック」は、スタイルの抽象化に関連しています。私たちは皆、M-10クラスをマージンにマッピングすることを言っている記事を読みました：10pxは、 HTMLとCSSの両方を編集してスタイルを変更することを意味するため、良いアイデアではありません。残念ながら、これは大/複雑なプロジェクトで起こることです。

• デザイナー： 15ピクセルのギャップが欲しいです
• 開発者： OK、それはM-3Xです（5ピクセルの増分）
• デザイナー：もちろん、何でも！
• 開発者：それは完了です！
• デザイナー：実際、15ピクセルが少し大きすぎますが、12ピクセルに変更できますか？
• 開発者：いいえ、10ピクセルまたは15ピクセルのいずれかもありません。
• デザイナー：申し訳ありませんが、これは私にとってはうまくいきません。 M-3Xを12ピクセルに変更できますか？
• 開発者：いいえ！他のチームはM-3xが15ピクセルであると予想しているため、それはできません。
• デザイナー：わかりました、マージンを12ピクセルにしたいので、方法を見つけてみてください。 15ピクセルが多すぎると、10ピクセルが少なすぎます。
• 開発者：（死にます！）

このような問題を予測するには、リクエストの背後にあるデザイナーの意図を理解する必要があります。色のプライマリなどの抽象化のために選択されたスタイル、またはM-3Xケースの15ピクセルのマージンなどの特定の値のために選択されますか？設計原則を実施するスタイルガイドがある場合、M-3xのようなクラスは問題ない場合がありますが、設計チームが必要なスタイルを要求できれば、ぼやけたスタイルにつながる慣習の名前を避けることをお勧めします。私の経験では、あいまいさはあれば損害につながる可能性があります。

スタイル設定のドキュメントまたはコンポーネントの構造に依存する - スタイルシートを書くためのきちんとした方法のようなコンバイナーのスルーをスルーしますが、複雑な環境では、特定のタグまたは構造が不可能であると想定できないという事実は無視されます。

Z-Indexは複雑だと思いますか？コンポーネントが配置されているスタック範囲さえない場合は、もう一度考えてください。これは、チームがページのさまざまな部分に対して責任を負う大規模なプロジェクトで解決すべき最も複雑な問題の1つです。私はかつてこれに関する提案を書きました。

入力と.input.requiredなどの資格のあるセレクターは、見事でセマンティックですが、0.1.1と0.2.0などの不必要なレベルの特異性を作成し、セレクターを制限しないことを防ぐことができます。

WildCardセレクター*に依存して、グローバルスコープスタイルを設定しますか？非常に大きなプロジェクトでは、これはあなたが他の人のコンポーネントをスタイリングしていることを意味するかもしれません。あなたが彼らのニーズを理解しない限り、他の人のためにスタイルの決定をしないでください。

IDが悪いと読んでいると思いますが、具体性は悪いですが。実際には。高い特異性は、ルールによって作成された特異性レベルの数ほど問題ではありません。存在のレベルが2つまたは3つしかない環境（たとえば、1.1.0、0.1.0、0.2.0）しかスタイリングするのがはるかに簡単です。これは、特異性がかなり低いが、「自由な競争」アプローチに従っている環境よりも、0.1.0、0.1.1、0.2.0、0.2.1、0.2.2など、0.1.1、0.2.0、0.2.1、0.2.2などです。

CSSコミュニティのアドバイスに盲目的に従うことは、不快な驚きにつながる可能性があります。まだ実際にテストされていない新しいテクノロジーを採用しないでください。 Will-Changeを覚えていますか？そして、あなたが使用する各スタイル、またはそれをトリガーする可能性のあるものを常に知ってください。たとえば、位置はスタッキングコンテキストと含有ブロックを作成できますが、オーバーフローはブロックのフォーマットコンテキストを作成できます。

私の経験では、CSSの深い理解は、大規模な組織がCSSを効率的に書くのに十分ではありません。 Yahooでの間、私は数年前に私と一緒にいた人々と対立することがよくありました。環境は非常に残酷であり、多くの落とし穴を避けるために非常に実用的なものが必要です。次回、大規模なプロジェクトのソースコードを見て、自分にとって意味をなさない何かを見るときは、Nicholas Zakasからのこのツイートを覚えておいてください。

人々は愚かで、無知であり、間違いを犯し、彼らが賢いと仮定し、最善を尽くし、あなたには背景が欠けていると仮定しないでください。

- Nicholas C. Zakas（@slicknet）2013年2月10日

Yahooの原子CSSへの移行はどのように内部で受け入れられていますか？

TK：私たちのホームページチームはACSSをよく受け入れましたが、外ではうまくいきませんでした。私たちの最初の相互作用は、サンタモニカにあるスポーツチームとのものでした。スティーブと私は、懸念の分離の原則に従わないことが正しいことであり、混乱を引き起こさないという電話会議で開発者を説得しようとしました。

ニコラス・ギャラガーによる最近の記事を彼らに指摘しましたが、「部外者」からは役に立つでしょうが、そうではありません。物事はうまくいっておらず、多くの摩擦があります。主な問題は、ライブラリがユーティリティクラスで構成されていることですが、その構文は会話を容易にするのに役立ちません。

Atomic CSSのアイデアに反対しなかったメールチームと会ったことを覚えていますが、ACSS構文に耐えられなかったため、「通常の」CSS宣言を使用する独自のJavaScriptメソッドを考え出したいと考えていました。とにかく、ライブラリをサポートするデータ（CSSとHTMLの約36％の減少）はそれ自体がそれをすべて述べているため、ACSSは終わりです。今日、7年以上後、Yahoo Homepage、Yahoo Sports、Yahoo News、Yahoo Finance、その他のYahoo製品はまだACSを使用しています。

ACSSのようなアプローチがコンポーネントの再利用性が重要なプロジェクトにどのように利益をもたらすかをよりよく理解するには、Yahoo Financeからコンポーネントのマークアップをコピーして、Yahooニュースに貼り付けます。コンポーネントは、ページの一部に属しているように見える必要があります。これは、ACSSがこれらのコンポーネントをページから独立しているためです。

クラス名としての括弧の方法はどのようにしていますか？構文は、機能の書き方に触発されていますか？

TK：複数の反復を介して属性値セパレーターとして使用される「候補」の2セットを特定しました：括弧（）と四角いブラケット[]。

レナートは、追加のシフトキーストロークを犠牲にしても、JavaScriptの機能に精通しているため、四角い括弧の上にブラケットを選んだことを思い出します。 ACSS構文は次のことを目的としています。

• アトマイザーを介してルールの自動生成を促進します
• 開発者が必要な任意のスタイルまたは複雑なスタイルを作成できるようにします
• 学習曲線を最小限に抑えます

このように見えます：

 <code>[<context> [:<pseudo-class> ]<combinator> ][(<value> ,<value> ?,...)][][:<pseudo-class> ][::<pseudo-element> ][--<breakpoint_identifier> ]</breakpoint_identifier></pseudo-element></pseudo-class></value></value></combinator></pseudo-class></context></code>

開発者は、上記の構造に従ってクラスを構築します。コア構文は、人気のあるツールキットエメットに基づいています。コアクラスは任意の文字列ではなく、明示的なプロパティ/値ペアであるため、エメットメソッドを使用して機能を削減します。

また、12を超える補助クラスを作成しました。これらは複数のスタイルの宣言を適用し、視覚障害のあるユーザーを隠すコンテンツなどのショートカット、または.cfを使用してClearfixなどのハッキングです。また、構成ファイルを使用して、より多くの自由を提供します。ここでは、ブレークポイントなどの変数を作成できるようになります。

ACSSを使用したことがない人は、構文が（せいぜい）あまりにも奇妙であることを教えてくれますが、それに精通している人は、それが多くの点で賢いことをあなたに言うでしょう。

Smashing Magazineの「Challenge CSS Best Practices」の記事がどのように実装されているかについて話しますか？

TK：私は以前にさまざまなオンライン出版物で多くを書いたことがあるので、この「挑戦的な」アプローチに関する記事を書くのは自然です。

Yahooは2013年10月にフロントエンド会議を後援しました。レナートは私たちのソリューションを紹介するためにスピーチを手配し、その前にこの記事を公開しようとしました。サイトはコメントセクションを提供していないため、Yahoo！離れたリストは時間内に公開できませんでしたが、Smashing Magazineは、10月末までに記事を公開できるようにレビュープロセスを加速しました。

コメントセクションを使用して出版社を選択するための私のアプローチは、投稿が200を超えるコメントを受け取ったために報われました。これは非常に時間がかかり、イライラしていました。

この投稿には、問題のテクノロジーに関する免責事項がまだありますが、現在業界ですでに人気がある場合でも、奇妙に感じますか？

TK：記事が公開されたとき、私はVitaly [Smashing Magazineの共同設立者]に、ある種の免責事項のように聞こえると語った。しかし、Vitalyの考えを理解していたので、私はそれを本当に反論しませんでした。私はこのメモがまだ興味深いと思います、そして、このアプローチは今主流になっています。

後知恵を考えると、原子CSSのどの側面を変えたいですか？

TK：特にこのソリューションを開拓した後、常に改善の余地があります。他の人が自分の過ちや欠点について学ぶために何をしたかを見ることはできません。材料が改善されていません。ですから、私たちが初めて成功したと思うなら、それはうぬぼれます。

1年以上にわたって大規模なプロジェクトで「静的」スタイルのシートを使用しているため、原子CSSの豊富な経験があります。しかし、ダイナミクスの観点から見ると、ツール - はあまりインスピレーションを得ていないようです。他の図書館が追随するのに6年かかったことを忘れないでください。

フランス語では、 Essuyer LesPlâtres 。 （ほこりを拭く）

私たちが犯した間違いの1つは、「Atomic CSS」をACSS.IOのタイトルとして使用することでした。それ以来、タイトルを変更しました。

私が後悔する唯一のことは、コミュニティが長年にわたって原子CSS/ACSをどのように扱ってきたかということです。最近、誰かが「原子CSS」が意味することを私に説明した奇妙なやり取りにつながりました。

Atomic CSS Library [ACSS]はこの名前を使用していますが、あなたが話している機能はダイナミックなスタイルの生成であるため、誤解を招くと思います。 「Atomic CSS」は、小さなセレクターを原子として指定する一般的な用語ですが、静的です。

消去されることについて話します。 ;）

このインタビューに参加し、コミュニティに投稿できるようにしてくれたThierryに感謝します。

以上が原子CSSの作成：ティエリー・コブレンツとのインタビューの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。