LESSを使用してBootstrap 2.0.3を使用しています。大幅にカスタマイズしたいのですが、ライブラリの変更が頻繁に行われるため、ソースの変更はできるだけ避けたいと考えています。私はLESSを初めて使用するので、そのコンパイルが完全にどのように機能するかわかりません。LESS または LESS ベースのフレームワークを使用するためのベスト プラクティスは何ですか?
7 に答える
私の解決策はjstamの解決策と似ていますが、可能な場合はソースファイルに変更を加えることは避けています。ブートストラップへの変更が頻繁に行われることを考えると、変更を別のファイルに保持することで、最新のソースをプルダウンし、最小限の変更を加えることができるようにしたいと思います。もちろん、それは完全な防弾ではありません。
bootstrap.lessとvariables.lessを親ディレクトリにコピーします。bootstrap.lessの名前をtheme.lessまたは任意の名前に変更します。ディレクトリディレクトリ構造は次のようになります。
/Website theme.less variables.less /Bootstrap ...
ブートストラップサブディレクトリを指すようにtheme.less内のすべての参照を更新します。variables.lessが、次のようにブートストラップディレクトリではなく、親から参照されていることを確認してください。
... // CSS Reset @import "bootstrap/reset.less"; // Core variables and mixins @import "variables.less"; // Modify this for custom colors, font-sizes, etc @import "bootstrap/mixins.less"; // Grid system and page structure @import "bootstrap/scaffolding.less"; @import "bootstrap/grid.less"; @import "bootstrap/layouts.less";
..。
CSSオーバーライドは、それらが含まれている場所の直後に、theme.lessファイルに追加します。
... // Components: Nav @import "bootstrap/navs.less"; @import "bootstrap/navbar.less"; // overrides .navbar-fixed-top .navbar-inner, .navbar-fixed-bottom .navbar-inner { border-radius: 0 0 0 0; padding: 10px; } .nav-tabs, .nav-pills { text-transform: uppercase; } .navbar .nav > li > a { text-shadow: none; } ...
HTMLページでbootstrap.lessではなくtheme.lessにリンクします。
新しいバージョンがリリースされるたびに、変更は安全である必要があります。また、新しいバージョンがリリースされるたびに、カスタムブートストラップファイル間で差分をとる必要があります。変数とインポートは変更される可能性があります。
これは私も苦労したことです。一方で、variables.less ファイルを独自の色と設定で高度にカスタマイズしたいと考えています。一方で、アップグレード プロセスを容易にするために、Bootstrap ファイルを少しだけ変更したいと考えています。
bootstrap.less
私の解決策 (今のところ) は、アドオン LESS ファイルを作成し、変数と mixin がインポートされた後にファイルに挿入することです。だから、このようなもの:
...
// CSS Reset
@import "reset.less";
// Core variables and mixins
@import "variables.less"; // Modify this for custom colors, font-sizes, etc
@import "mixins.less";
// Custom Addons
@import "addon-file.less"; // <--- My custom LESS addon
// Grid system and page structure
@import "scaffolding.less";
...
このようにして、Bootstrap の色やフォントをリセットしたり、追加の mixin を追加したりできます。私のコードは別ですが、残りの Bootstrap インポート内でコンパイルされます。完璧ではありませんが、私にとってはうまく機能している応急処置です。
私の側から見ると、その中にtheme.less
importという名前のファイルがboostrap.less
あり、そのすぐ下で、更新したくない変数値をオーバーライドします (たとえ LESS を使用するのが悪いように見えても、維持するのは簡単です)。 .
これは、変数のカスタム値を持つ場合にうまく機能しますvariables.less
その後、theme.less
代わりにファイルをコンパイルしますbootstrap.less
例theme.less
:
@import "path/to/my/bootstrap.less";
@linkColor: #MyAwesomeColor;
はるかに優れた (IMHO) アプローチは、 swatchmaker と呼ばれる Bootswatch github プロジェクトからヒントを得ることです。このプロジェクトは、Web サイト上の数十の Bootstrap テーマを構築および管理するために特別に調整されています。
プロジェクト内のMakefile
ビルドswatchmaker.less
(名前を のように変更できますcustomizations.less
)。このファイルには、一連のインポートが含まれています。
@import "bootstrap/less/bootstrap.less";
@import "swatch/variables.less";
@import "swatch/bootswatch.less";
@import "bootstrap/less/utilities.less";
swatch
フォルダーとbootswatch.less
ファイルの名前は、適切な名前に変更できます。
自分のファイルに影響を与えずに Bootstrap をアップグレードできるので、これは理にかなっています。実際には、Makefile
Bootstrap の最新バージョンを取得するためのコマンドも含まれています。詳細については、プロジェクト ページの README を参照してください。
おまけとして、README には、ファイルが変更さwatchr
れたときにプロジェクトを自動的にビルドする gem をインストールすることも提案されています。.less
時間があれば(そして場合に限り)、私のようにそれを行うことができます. フレームワークの独自の修正バージョンを保持し、フレームワークを更新するたびにドキュメントを読み、ソースの修正を確認します。
このソリューションは、一見あまり理想的ではないように思えるかもしれませんが、そうする理由があります。私は 1 つではなく、多くのフレームワーク、ベスト プラクティス、リセット/正規化スタイル シートなどの融合で作業します。また、更新によって既存のプロジェクトが予想外の方法で変更されることはないと常に確信しています。
私は次の理由から、独自のカスタム フレームワークに取り組んでいます。
- モジュール化して小さくしておく必要のないものを少しずつ取り除きます
- 私はクライアントの仕事に自分のフレームワークを使用しており、a) 自分が何を扱っているかを正確に把握し、b) クライアントに販売するすべてのものを所有したいと考えています。フレームワークを単にコピーして使用するのではなく、理解して再作成しようとします
- フレームワークを CMS と組み合わせて使用していますが、単純にフレームワークをプロジェクトにドロップして忘れたり、ゼロから開始したりすることはできません
Joelと同じ解決策にたどり着きました:
カスタムレスファイル
上記のように、カスタマイズしているすべての Less ファイルのローカル コピーを作成します: 「variables-custom.less」、「alerts-custom.less」、「buttons-custom.less」など。したがって、いくつかの標準を使用して、独自の追加を行うことができます。欠点は、Bootstrap が更新されると、移行が非常に困難になることです。
しかし、他にも次のことがあります。
スタイルのオーバーライド
ワークフローを調べていると、単にスタイルをオーバーライドすることを提案している人をよく見かけます。したがって、最初に標準の Less ファイルをインポートしてから、カスタム宣言を下部に追加します。ここでの利点は次のとおりです。新しいバージョンに更新する方が簡単です。欠点は次のとおりです。コンパイルされた CSS ファイルには、すべてのオーバーライドが含まれます。一部の CSS セレクターは 2 回定義されています。そのため、ブラウザは、実際に何を適用するかを見つけるために、いくつかの処理を行う必要があります。それは本当にきれいではありません。
プリプロセッサがそのような二重宣言を解決するほど賢くないのはなぜだろうか? ここで見逃しているより良いワークフローはありますか?
@import "../../styles.less";
一番下のbootstrap.lessに(またはスタイルシートがある場所に)追加するだけです。これにより、独自の.gradient
styles.less .border-radius
.