GitHubでのCSS開発

翻訳者から：

この記事は、GitHubのCSS開発者である人気のあるフロントエンドフレームワークであるTwitter Bootstrapの主要なメンテナーの1人であるMark Ottoを代表して書かれました 。



さまざまなアプリケーションの開発プロセス、特にスタイルガイドとCSS開発へのアプローチに常に興味がありました。 CSS開発で時々意味のない詳細を好むので、GitHubでCSS開発プロセスについて少し書くことにしました。

簡単な説明

CSSコードの現在の状態の概要は次のとおりです。

• プリプロセッサとしてSCSSを使用します。
• 本番環境にリリースする前にコンパイルする100を超える個別のソーススタイルシートがあります。
• コンパイル済みCSSは、バージョンIE <10のセレクター数の制限を回避するために2つのファイルに分割されています。
• これらの2つのファイルの合計重みは90KBです。
• CSSアーキテクチャの特定のアプローチには従いません。
• ピクセルを測定単位として使用しますが、場合によってはemも使用します。
• Normalize.cssを使用し、独自の破棄スタイルをミックスします。

プリプロセッサ

上記のように、SCSSを使用します。 この選択は、到着するずっと前に行われたもので、それに反対するものは何もありません（Bootstrapは現在LESSで開発されているにもかかわらず） SCSSファイルは、ファイルをインクルードするためにスプロケットの助けを借りてRuby on Railsによってコンパイルされます。 これについては後で詳しく説明します。



LESS、スタイラス、または...はどうですか？ GitHubがかつてLESSに切り替える予定はなかったと思いますが、それは言えません。 これで、ほとんどの場合、LESSを使用した開発に切り替えません。 明らかな利点はありません。



プリプロセッサを使用しているのはなぜですか？ 内部フレームワークには、比較的小さな変数セット（フォントや原色の混合など）およびミックスイン（ほとんどの場合、ベンダープレフィックス付きのプロパティ用）が含まれているため、コード開発が迅速かつ容易になります。



現時点ではAutoprefixerを使用していませんが、実際には、そうすべきです。 この場合、ほとんどすべてのミックスインは必要ありません。 これがすぐに実現することを願っています。



また、現時点ではソースマップを使用していませんが、まもなく変更されます。 （知らなかった場合、ソースマップを使用すると、ブラウザのインス​​ペクタで、どのソースSCSSファイルから、このスタイルセットがコンパイルおよび圧縮されたCSSの代わりにコンパイルされたかを確認できます。



これに加えて、SCSS機能はほとんど使用しません。 私たちの場合、SCSS機能は、変数、ミックスイン、色関数（ 暗く、明るくするなど）、数学関数、および継承を使用することになります。

建築

現在、CSSアーキテクチャへの2つの一般的なアプローチはBEMとOOCSSです。 OOCSSに傾いていますが、全体的かつグローバルなアプローチはありません。 これらの2つのアプローチの特性を組み合わせたあいまいなアプローチで新しい要素を開発しようとしますが、次の基本的な特徴があります。

• セレクターの他のすべて（ID、タグ）よりもクラスの優先順位。
• 不要な継承の回避;
• クラス名での（単一の）ハイフンの使用。
• クラスにできるだけ短い名前を付けようとしますが、混乱や混乱は生じません。

私の好みのCSSアーキテクチャについては、別の投稿で詳しく説明します。 さて、上記のテキストはGitHubのアプローチをまとめたものであり、もちろん完璧ではありませんが、それが必要とするものの良い仕事をします。

構文チェック（リンティング）

数週間前にSCSS 構文チェックの使用を開始しました。 コードスタイルに関する独自の条件付き規則がありましたが、各開発者のスタイルとフォーマットはややユニークでした。 現在、すべてのCIビルドには基本的なSCSSリンティングが含まれており、次の場合、ファイルはビルドにリリースされませんでした。

• クラスはCSSにありますが、 app / viewsテンプレートフォルダー内のどこにもありません。
• 同じセレクターを数回使用します（ほとんど常に組み合わせる必要があるため）。
• 一般的なフォーマット規則（継承の制限、規則間のインデント、 ：の後にスペースがないなど）に違反しています。

全体として、これらの少数のルールにより、コードはかなりきれいに保たれます。 コメントのスタイルや一般的なアーキテクチャの不一致は含まれていませんが、これはドキュメントを通じてコン​​パイルされるべきチームです。 これは、誰もが何かを修正して補足できるものです。

2つのCSSファイル

GitHubには、2つのCSSファイルgithubとgithub2のセットがあります 。 ファイルは、ファイルあたり4095個のセレクターという制限の問題を解決するために、数年前に分割されました。 この制限は、IE 9以前のバージョンに適用されます。 GitHubにはIE9のサポートが必要です。CSS分離アプローチは長い間有効です。 今日、GitHubにはこれらの2つのファイルに約7000のセレクターがあるためです。 これらの数値を他のサイトのデータと比較してください。

• Bootstrap v3.2.0のセレクターは1900弱です。
• Twitterのセレクターは8900未満です。
• NY Times-約2100人のセレクター。
• SoundCloud（新バージョン）-約1100。

これらの数値はcssstats.comによって生成されました 。 これは、私を含むほとんどの開発者が自分のファイルを見ない側からあなたのスタイルを見る非常にクールな小さなユーティリティです。 また、GitHub内ではチャートを使用し、通常は自分のニーズに合わせて使用​​します。

スプロケットを介した介在物

GitHubのCSSおよびJavaScriptは、スプロケットを介して含まれており、 requireが含まれています 。 app / assets / shylesheet s フォルダー内の分割されたサブディレクトリを使用してCSSコードを開発します 。 これは次のようなものです。

/* = require primer/basecoat/normalize = require primer/basecoat/base = require primer/basecoat/forms = require primer/basecoat/type = require primer/basecoat/utility = require_directory ./shared = require_directory ./_plugins = require_directory ./graphs = require primer-user-content/components/markdown = require primer-user-content/components/syntax-pygments = require primer/components/buttons = require primer/components/navigation = require primer/components/behavior = require primer/components/alerts = require primer/components/tooltips = require primer/components/counter = require primer-select-menu = require octicons = require_directory . */
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

依存関係を含め（Primerは内部フレームワークです）、その後、フォルダーのすべてのSCSSファイルを、スプロケットがそれらを含めることを決定した順序で含めます（アルファベット順に思えます）。 スタイルを簡単にバインドできる（ require_directory。Commandを使用して）のは簡単ですが、これには欠点もあります。



スタイルが適用される順序 （および、それに応じて、ファイルが含まれる順序）は重要です。 実際、これはそうではありませんが、すべての設計システムにはルールとスタイルの基本的な階層があります。 スプロケットアプローチでは、特定の問題に遭遇することがあります。 これは、2つのCSSファイルのいずれかに新しいファイルをいつでも追加できるためです。 ファイルの名前に応じて、コンパイルされたCSSのさまざまな場所に表示されます。



さらに、スプロケットの使用は、SCSSファイルがグローバル変数およびミックスインに直接かつ自動的にアクセスできないことを意味します。 これにより、変数またはmixinにアクセスするすべてのSCSSファイルの先頭に毎回（ @ importを介して）それらを含める必要があります。

性能

GitHub内では、多くのグラフを使用して、サイトとAPIの動作を追跡します。 また、いくつかの興味深いフロントエンド機能を追跡します。 たとえば、ここ3か月間の2つのCSSファイルのサイズを示すグラフです。







また、 blobページの過去3か月間のCSSファイル内のセレクターの数のグラフもあります 。 明らかに、タグセレクターの数を減らすためにまだ多くの作業があります。







更新されたCSSファイルを毎日追加し、毎日数十個も追加しているという事実により、かなり大きなCSSファイルのキャッシュを絶えずノックダウンしています。 ファイルサイズの最適化やキャッシュエラーの削減はほとんど行いませんでしたが、この方向をより詳しく調べ始めています。 非常にまれにしか変更されないコアファイルと、頻繁に変更されるセカンダリファイルがあると非常に便利です。



このトピックをTwitterで開くと、2つのファイル（ コアなど）があります（現在、それらがあるかどうかはわかりません）。 コアファイルには、最初のツイートまでの経過時間をできるだけ短くするために必要なスタイルが含まれていました。 他のすべてはmoreファイルにありました。 迅速な変更に対するGitHubの愛情を知っている（すぐに移植されない限り、ここには何も移植されません） これで、2つのファイルが任意に分離されました。



一般に、セレクターのパフォーマンスを最適化してもそれほど気になりません 。 過剰な投資、ID、要素など、悪いアプローチを認識していますが、再最適化は試みていません。 1つの例外はdiffページでした。 diffページのレンダリングに必要なマークアップが多すぎるため、 [class ^ =” octicon”]のような属性セレクターは避けました。 頻繁に使用すると、これらの属性セレクターはブラウザーをクラッシュ（およびクラッシュ）させる可能性があります。

ドキュメント

それについて言えば、私たちは自分たちのために非常に良い仕事をしていますが、改善にも取り組んでいます。 一般公開されているCSSスタイルガイドがあり、 CSSの一般的なガイドラインのすべてと、ほとんどのコンポーネントの例があります。 スタイルガイドジェネレーターであるKSS上に構築されています。



完全ではありませんが、開発者はコンポーネントをすばやく見つけて使用できます。 これはまた、新しい開発者に開発プロセスを見せて、通常の開発速度をより速くするための素晴らしい方法です（私が約2年前に参加したときのように）。

プライマー

以前にこれをほのめかしましたが、Primer pは、最新ではない人にとっては、パブリックおよび内部アプリケーション内の一般的なスタイルとコンポーネントの内部フレームワークです。 以下が含まれます。

• ノーマライズ
• ボックスサイズ 、タイポグラフィ、リンクなどのグローバルスタイル。
• ナビゲーション
• フォーム;
• メッシュ;
• マークアップスタイル。
• 特別な選択メニュー。

GitHub.com、Gist、およびいくつかの内部アプリケーションで使用しています。



ほとんどのPrimerコンポーネントは、スタイルガイド（ナビゲーション、ツールチップなど）に文書化されています。それにもかかわらず、最近Primerの更新と改善を開始したため、多くのコンポーネントが変更されています。



お願いしたい人のために、私はプライマーの一部をパブリックドメインに投稿したいと思いますが、近い将来この方向に変化するものはほとんどありません。 それでも、私は希望を持っています。

コードリアクター

CSSを含むレガシーコードのまともな部分があります。 厳格なバージョンルールを持つパブリックオープンソースプロジェクトとは異なり、これらのソリューションが私たちに合っていれば、不要なコードを定期的に取り除きます。 削除するものを見つけるには、次の2つの方法があります。

• 似ているものの、実際には異なるHTMLコードとCSSコードを持つもの、およびその後の組み合わせの手動検索。
• CSSでクラスを探し、ビューファイルにあるかどうかを確認するスクリプトを実行します。

一般的なリファクタリングプロセスは、おそらくGitHubに固有のものではありません。 削除するもの、削除するもの、公に議論するものを見つけ、CSS開発チームに知らせて、できるだけ早くそれらを移植します。 チームメンバーは誰でもコードを削除できます。 GitHubに新しいものを直接追加する多くの開発者がいますが、削除できるものを分析する多くのオタクもいます。