CMSの管理画面でクラス名を変更できるようにしたことを後悔している


コーディングとCMSのテーマ設計の話です。かなりCMS構築に慣れていないと理解しづらい内容になるので、順を追って説明します。

モジュール型のサイト設計

CMSで運用されるサイトは、トップページや下層ページのサイドバーで、投稿の新着やナビゲーションなどの「モジュール」を埋め込む前提で構築やコーディングをします。
ここでは「モジュール」としていますが、CMSによって名称は異なります。よく知られているのはWordPressの「ウィジェット」です。

コーディングにについては、以前書いた記事「CMSの構築を考慮したコーディングとかクラスの命名規則の話」で詳しく書いていますが、つまりはこの場合、それぞれのモジュール(=ウィジェット)はクラス名が付与されたdivで包括される前提となります。

例えば、WordPressの人気テーマ「Lightning」のトップページで、新着記事を表示している箇所は以下のようにマークアップされています。

<div class="widget widget_vkexunit_post_list" id="vkexunit_post_list-13">
(新着記事リスト)
</div>

自由モジュールであることを示す「widget」、テーマ専用パーツであることを示す「widget_vkexunit_post_list」のクラスに加え、一意のIDが付与されています。
これによって似たようなモジュールをページに複数配置しても、クラスかIDで区別してCSSスタイルを調整できます。

モジュールのクラス名を自由に決められるようにしてみる

DrupalのBlockやViewsでは、先述した包括divに付与するクラス名を変更できる機能があります。コーダー側のコーディングルールを活かせるので、とても魅力的な機能です。


ヘッダ、フッタのボタン、包括divの属性を変更できるようにした例


このクラス名変更機能を、a-blog cmsのモジュール設定に組み込んだのが、二年ほど前に公開したテーマ「echo_zero」でした。

モジュールの外観のカスタマイズ | はじめての方へ | 解説資料 | echo_zeroデモサイト

このテーマは当時はかなり満足していて、安定したウェブサイトをサクサク構築できるので、いくつかの案件にそのまま採用していました。
…が、二年が経って、一部の案件でこの機能が足を引っ張るようになってしまいました。

クラス名を見つけられない

完全納品ではなく、納品後も改修をお手伝いする案件だと、半年ほど経ってコンテンツが増えてきてから、二段階目の改修を依頼されることがあります。
モジュールの追加やデザイン変更などが発生しますから、コーディングも変わってきます。以前はイベント新着関係のモジュールが一個しかなかったのに、似たようなモジュール(関連イベント・現在位置から近い順)が増えたりします。

半年も経つと、自分の作ったテーマでも細かい構造は忘れています。このクラスは、どのモジュールで使用していたろうかと、テーマをクラス名の一部、例えば「module-event」などで検索してみても…見つかりません。
クラス名はCMS側で管理しているので、ローカル環境のエディタの全文検索ではヒットしないのです。
こうなると、a-blog cmsの管理画面に入って「モジュールID」の一覧から該当のモジュールを探すことになります。かなりの手間です。

CMSで何もかも管理すればいいわけでもない

一般に配布するテーマであれば、クラス名を変更できる機能は非常に便利です。
利用する人の大半は、モジュールごとに細かくCSSを調整したり、コーディングルールにこだわったりすることがないので、メリットの方が大きいでしょう。

ですが、自分がいちからテーマを作成していて、改修も多い場合は、修正すべき箇所をローカル検索できないというのは、毎回の時間のロスは大したことがないものの、けっこうストレスが貯まります。

そんなこんなで最近は、多くの人がやっているように、記事リストを呼び出す箇所を共通のインクルードファイルにして、クラス名や繰り返すコンポーネント名を変数で渡す構築になっています。
以下はa-blog cmsの場合です。a-blog cmsはJSON形式で変数を渡せます。これなら検索にもヒットします。

@include("/include/module/summary.html", {"class": "c-module-event-top", "mid": "summary_event_top", "loop": "event"})

ここまで書いて、どのくらいの人にこの文章が伝わっているのだろうか…と思いはじめていますが…

よく考えたら、モジュールの包括divを、制作者以外が変更できるようにする必要は基本的にないわけです。配布テーマでは便利でも、制作者が不便になるような機能は制作段階で外しておかなければと、改めて反省しています。


投稿者名 うぇびん 投稿日時 2019年09月23日 | Permalink

CSSプロパティはどこまで覚えればいいのか


今朝、Twitterを見ていたら「未経験からの入社でも、このくらいはCSSのプロパティや値を覚えていてほしい」というツイートが流れてきました。

一連のプロパティの紹介はとても勉強になるもので、うなずきながら読んでいましたが、途中、どうにも同意できなくて突っ込みを入れたものがあります。

  • flex-flow、justify-content、align-itemsの全ての値
  • animationのfill-mode
  • :nth-of-type疑似要素

これらのプロパティは中級者以上が、存在を知っている程度で充分であり、覚えるものではないと考えています。

覚えなくて良いと考える理由

私がこれまでお取引をした制作会社の「平均よりちょっと上」のレベルをイメージしています。

flexbox関連

flexbox 自体は、マークアップエンジニアとして就職するなら必修です。が、入社レベルでは以下の3パターンを実装するためのスニペットを知っていればいいです。このパターン以外の値の使用頻度が、極端に低いためです。

  • すべての要素を改行せず並べる+すべての要素の高さを揃える(レイアウト)
  • すべての要素を改行せず並べる+すべての要素を縦中央に揃える(ページネーション等)
  • 幅がオーバーした場合改行する+すべての要素の高さを揃える(グリッドレイアウト等)

なお、スマホでは横並びを解除(flex-direction: column)も意外と出番が多いです。

justify-contentの space-around, space-evenly は、一般のウェブデザインのパターンではあまり見られません。私は一度も実装したことがありません。デザインお任せのときに使ってみたいですが。
使用頻度が低いプロパティの挙動を研究するのは、頻度が高いスキルを問題なくこなせるようになってからでもいいです。むしろ読みやすいコードを書いてほしいです。

animation関連

「アートディレクターがゴリゴリに作ったカンプをCSSで動かすことになり、コーディングができる社員が初級者しかいない」という状況ならまだ理解はできるのですが、animationの fill-mode を初級者に説明させるのは酷というものです。使うとしてもbothでだいたいなんとかなります。
まずは transition から書かせて、CSSアニメーションの基礎を知ってからの方が理解しやすいと思います。transitionは必修です。

:nth-of-type

このプロパティを知らなかったというツイートをけっこう見ました。そのくらい使用頻度が低いプロパティです。
詳しくはMDNのリファレンスを見ていただきたいですが、以下のようなHTMLに任意のスタイルを反映させる際に役立ちます。

  • 自由にクラスを付与できない
  • 繰り返される
  • 他の要素が兄弟階層に混ざる可能性がある

WordPressのGutenbergなどの、CMSのブロックエディタで生成されたHTMLを整形する際に役立つ可能性があります。
ですが「使用頻度が低い」と書いたとおり、:nth-of-typeを知らなくても解決できるようなHTMLが提供されていることがほとんどで、私も一度しか使ったことがありません。また、JavaScriptを追加できるならDOMを解析して連番クラスを付与する手もあります。
考えられるのは、官公庁などのいにしえのHTMLを、一切触らずにCSSを追加しなければならないような状況でしょうか…

プロパティはどこまで覚えればいいのか

人それぞれと思いますが…私は
Bootstrapに書いてあるCSSが、覚えておきたいプロパティと値である」
と考えています。

BootstrapなどのCSSフレームワークは、実際にウェブ制作で頻繁に使用されるモジュールやコンポーネントの集合体であるからです。

開発者ツールで遊ぼう、フレームワークを読もう

ここ数年、年に2回、初心者向け講座の講師をしていました。「会社に入ったばかりの初心者に、最低限のHTML・CSS・JavaScriptを三日間で教える」というなかなかハードな講座です。

https://www.deos.co.jp/koza/detail/tf010

カリキュラムの作成にも一部参加したのですが、困ったのがCSSでした。一日では教えきれないほど必修のプロパティが多いのです。
最終的に「テキストにはいろいろ値が書かれているけれど、これとこれ以外は、今は覚えなくて良いです」と、現場で使用されているプロパティを推しまくる進め方になりました。

それだけでは、当然勉強不足です。なので、以下の三点を補足しました。

  • Chromeの「開発者ツール」を早い段階で触らせ、各プロパティに様々な値が存在していることも教える
  • 有名どころのCSSフレームワークを見てほしいと説明する
  • 時間の関係で教えられないプロパティは、名称と簡単な役割をメモさせておき、検索するように言う

CSSに限らず、学習には以下の三点が必要なのだと思っています。

  • 習得の優先順位を判別すること(これは勤め先の環境でも変わるでしょう)
  • 既存ツール、素材を活用すること
  • アンテナを張り、気になった用語を検索して調べること

長々と書きましたが、私はコーディングが大嫌いです!予算に余裕さえあれば、コーディングが得意な友人たちに外注してCMSだけを触っていたいくらいです。

だからこそ、すべての人が高いレベルのCSSの知識を持っていなくてもいいのではないかな…と感じます。

追記

元ツイは一旦削除されましたが、ツイ主のTAKさんが、知っておくと良いプロパティと値について、再度まとめてくださいました。
こちらからTwitterへ移動して、一連のスレッドを読めます。


投稿者名 うぇびん 投稿日時 2019年08月07日 | Permalink

自作のCSSフレームワークで特に気に入っているコンポーネントの話


先月公開したCSSフレームワーク「echo.css」ですが、「どんなページが作れるかのサンプルがないと、イメージしにくいんじゃないかな」と言われました。

それで、ドキュメントよりも先にテンプレートを作っています。日曜日はチクチク制作をしておりました。

echo.cssのモジュール群で特に気に入っているのが、冒頭の画像の「c-flip」というコンポーネントです。デスクトップでは写真を大胆に表示し、モバイルでは写真が上、文章が下となります。



初出は、昨年稲葉さんと制作したa-blog cms用のテーマ「zeroichi_lp」です。

この時点でも充分使い勝手は良かったですが、実際の案件で使ううちに、デスクトップでの表示が8パターンまで必要なことがわかってきました。使用する背景画像によって、適切な文字配置は全く異なるためです。デザイン上の理由もあります。

  • 画像全面+コンテンツ白背景・左寄せ
  • 画像全面+コンテンツ黒背景・左寄せ
  • 画像全面+コンテンツ白背景・右寄せ
  • 画像全面+コンテンツ黒背景・右寄せ
  • 画像半分+コンテンツ白背景・左寄せ
  • 画像半分+コンテンツ黒背景・左寄せ
  • 画像半分+コンテンツ白背景・右寄せ
  • 画像半分+コンテンツ黒背景・右寄せ

8パターンのデザインを簡単に切り替えるために、サブクラスなどをずいぶん整理して現在に至ります。詳しくはこのコンポーネントの解説ページをご覧ください。

https://cms-skill.com/echo-css/styleguide/component-flip.html

私が制作するサイトは、ほぼすべてCMSを介して制作し、さらにその半分くらいが、フォーマットができてから原稿が入ります。その際に想定外の画像やテキストをどれだけ少ない工数で補完できるかを、自分の独自スキルとして磨きたいと日々考えています。これは少なくとも、AIには当分できないことです。


投稿者名 うぇびん 投稿日時 2018年11月04日 | Permalink

CMSの構築を考慮したコーディングとかクラスの命名規則の話


先日、CSSフレームワークについて記事を書いてから、今後のコーディング設計について具体的に考えています。

【Webdesign】Atomic Designの思想で、文系でもわかるCSSフレームワークを作りたい | ウェビンブログ

というより、再利用性のある業務用テーマの制作をいくつか依頼されており、いずれにしても着手しなければならないのです。

私の主業務が、CMS(それも特定のブランドによらない)を組み込んだサイトの制作であることを前提に、自分はどう設計していったらよいか、考えていることを書いておきます。


投稿者名 うぇびん 投稿日時 2017年07月08日 | Permalink

Atomic Designの思想でCSSフレームワークを作るのは難しいので代替案を考える


一昨日、「FLOCSSがわかりにくい」「Atomic Designの思想でフレームワークを作ってみたい」という記事を書いたところ、とてもたくさんの感想をいただきました。

【Webdesign】Atomic Designの思想で、文系でもわかるCSSフレームワークを作りたい | ウェビンブログ

大半がフロントエンドエンジニアからの突っ込みです。著名な方々にもたくさん意見をいただいただのでまとめました。ありがとうございます。

「Atomic Designの思想で、文系でもわかるCSSフレームワークを作りたい」に識者たちの鋭すぎる突っ込みが入る - Togetterまとめ

Atomic DesignがCSS設計に適していない理由

ピクセルグリッドの高津戸さんによると、そもそもAtomic DesignはCSSやJSの設計とは全く関係ないそうですが、よく考えてみると、たしかに厳密な階層構造を持っているAtomic Designの設計は、デザインレベルからの意思統一が可能な環境でなければ破綻してしまいます。

私はデザインを外部に発注することが多いですし、CMSベースで構築すると、どうしてもマークアップやクラスの命名に手を出せない箇所が出てきます(※)。

そんなこんなで、Atomic Designを採用することは諦めて、既存のCSS設計を、専門のマークアップエンジニアではなくても理解しやすくする方向で考え直すことにしました。


投稿者名 うぇびん 投稿日時 2017年06月16日 | Permalink