良かったなーと思っています...。詳細度を低くすること」です。入れ子が深いセレクタもあまりありません。!importat、入れ子が深いセレクタは詳細度が高くなります。辿った深いセレクタを何度も書かないといけなくなったりして「ここを上書きしたい」だけなのに、その要素の親要素のことまで調べたりしないといけなくなり、時間の無駄です。詳細度がなるべく低くなるような設計にしています。命名を考える必要があります。採用することにしました。コードを書かなくてすむ工夫デザイナーさんにとっては、やはり「コードを書く」ということが一番のストレスなのではないかと考えました。コードを書かなくてもざっくりデザインの基礎的な部分やレイアウトが組めるようにカスタマイザーに力を入れました。下記のようなことをカスタマイザーでポチするだけで設定可能です。ページヘッダー表示などまた、固定ページのレイアウトも簡単に設定できるように、ページテンプレートも豊富に用意しています。左サイドバー、右サイドバー、トップページ用、ブランクページ、1カラム(サイドバー無し、ページ幅(最大固定)、ページ幅(リキッド))から選択することができます。親テーマに拡張性がないと、子テーマでデザインをカスタマイズしたい場合にどうしてもテンプレートを丸ごと上書きしないといけなくなります。テンプレートを丸ごと上書きしないですむように次のような工夫をしています。様々な箇所に大量のアクションフックがあります。等からそこだけピンポイントに要素を追加することが可能になっています。テンプレートを細かく分割して切り出すアクションフックが大量にあれば要素を追加することはできますが、要素を書き換えたり削除することはできません。様々なパーツをmodules/というディレクトリにテンプレートパーツとして切り出しています。パンくず、copyright、ロゴ、ページャー等です。パーツを細かく切り出せば、ページのテンプレートを丸ごと上書きしなくても必要なモジュールだけ上書きすれば良くなるので、上書きが与える影響を最小限に抑えることができます。クラス化これは難しいので良くないと言われることがしばしばあるのですが、僕的にはこれはかなりナイスなアイデアだと思っています。親テーマのものが先にロードされるため、関数ベースだとその関数を素直に上書きすることができません(同名の関数は定義できないため)。全て囲むという涙ぐまし努力を行っているテーマもありますが、正直それはかなり無駄な作業に思いますし、全くスマートでありません。クラスがあり、クラスには継承による上書きという機能があります。クラス化すれば、継承によって素直に機能を上書きすることができます。関数ベースだとどうしても各関数が大きくなりがちですが、クラス化しておけば各処理をさらに細かく分割することで、上書きの影響を最小限に抑えるようなこともできるようになります。クラス化することにしました。クラスを継承して使うことが難しいという場合は、フックの使用などはクラスを使わずに普通に関数ベースでも行えるので、特にクラスを使わなくても大丈夫ではあります。主であり、これは子テーマ等で容易に上書きできたり書き換えたりすることができるので、それらのアップデートがユーザーに与える影響がとてもとても大きく、プラグインのようにお気軽にアップデートすることができません。そのため今となって「こうしておけば良かった」とか「ここはこうしたいけど今から変更するには影響が大きすぎる」みたいなところがいろいろとあります。この辺りも後日また記事にしたいと思います。さんの「最近Habakiriのテーマをいじって勉強したのでその時の感想など。