自作CSSフレームワーク「echo.css」で、変えたことと変えなかったこと


CMS構築のベースとして公開しているCSSフレームワーク「echo.css」が、Version 2.0.0になりました。

https://cms-skill.com/echo-css/

Version 1系から大きく変わったように見えませんが、内部的な変更を多数行っています。Twitterではリリース時にいくつかご紹介させていただきましたが、ブログでは方針などの細かい点も含めて「変えたこと」「検討したが変えなかったこと」をご紹介します。

方針
変えたこと
 ホバー・フォーカス・カレント効果
 カラーテーブル
 フォント
 c-heroの画像の扱い
 object-fitの採用
変えなかったこと
 SMACSSかBEMか
 ユーティリティクラスは必要なのか

方針

echoは、年に一度くらいのペースでリリースしているCMSテーマのベースとして使用しています。
バージョンアップにあたって、改めてecho.cssはこれからどうあるべきか検討した結果、「アクセシビリティ」も意識したいという結論を出しました。

私は生まれつき視力が低く、学生のときは点字翻訳のボランティアをしていました。その関係でアクセシビリティに関心があります。最近はますます視力が衰えていることもあり、個人的にも見やすいサイトが好きです。

Web Content Accessibility Guidelines (WCAG) 2.1の達成項目のうち、CSSスタイルが直接影響を与えるものは、主に以下です。

  • コントラスト比(1.4.3, 1.4.6)
  • テキストの間隔(1.4.12)
  • キーボード操作(2.1.1)
  • フォーカスの可視化(2.4.7)
  • 現在位置(2.4.8)
  • 予測可能(3.2)

多くの人気CSSフレームワークやCMSテーマを見ましたが、上記をすべてクリアしているものは多くありません。
作っている間の制作者だけでなく、作ってからも閲覧者にやさしいフレームワーク
としたいと考えました。デザイン性をくずさず、可能な限り達成基準を満たせるよう配慮したつもりです。

変えたこと.1 ホバー・フォーカス・カレント効果

先程の基本方針にあたって、すべてのクリック可能モジュールのホバー・フォーカス・カレント効果を見直しました。
フォームはフォーカスリングを必ず表示するように修正し、ボタンは色覚に依存せずに変化がわかるようになっています。チェックボックスの変更については別途記事にしています。

アクセシビリティを考慮した、チェックボックスとラジオボタンのCSSのサンプル | ウェビンブログ



ナビゲーションについては悩みました。色覚に依存しない効果にするのであれば、ホバー効果は太い下線か、枠囲みが良いと思っています。ですが、echo.cssはあくまでCSSフレームワークなので、ウェブサイトの意匠が大きく反映されるナビゲーションで凝った効果を加えたくありませんでした。
結局、デフォルトを薄いグレーの網掛けとして、この色をSassの変数で変更可能としました。



変えたこと.2 カラーテーブル

カラーテーブルは1系でも既に細かく定義していましたが、さらに整理しました。ベースカラー3色(first, second, third)とフォーム用のシステムカラー2色(info, impotant)で構成されています。
繰り返しますが、echo.cssはCMSベースのウェブサイトを制作するためのフレームワークですから、warningやsuccessなどの細かいステートは必要ないです。

https://cms-skill.com/echo-css/docs/design-tokens-color.html



アクセントカラーである「third」を何色にするかで、直前まで悩みました。赤にするとimportantとかぶってしまいます。よくあるシアンやオレンジにすると、コントラスト比の基準値に届きません。

結局、ボタンなどに使用したときには文字を黒くする前提で、ベースを黄色、文字色は茶色にしました。

変えたこと.3 フォント

使用しているフォントファミリーに大きな変更はありませんが、汎用見出し用のsecond, 大見出し用のthirdの使用箇所をギリギリまで絞り、どこで何が使用されているのかをドキュメントで明確にしました。

https://cms-skill.com/echo-css/docs/design-tokens-font.html



このフレームワークはFONTPLUSなどのウェブフォントサービスを使用したときに、font-weightプロパティだけでは文字太さを変更できない問題の対策をしてあります。
つまり、文字太さの変更が必要な箇所ではfont-weightだけでなくfont-familyの定義も行っているのですが、ウェブフォントサービスを使用しない場合はCSSが冗長になってしまっていました。

Version 2系では、フォント指定をしなければ最低限のスタイルのみが出力されるよう、Sassのmixinを追加しました。

変えたこと.4 c-heroの画像の扱い

.c-hero という、メインビジュアルやスライドショー向けのコンポーネントがありますが、これの背景画像の扱いを大幅に変更しました。

Version 1系では縦横サイズが端末の画像高さに依存しており、それに併せて背景画像をトリミングしていましたが、Version 2系では画像をトリミングさせずに伸縮させ、タブレットの画面幅でモバイル用の画像に切り替える挙動となっています。切り替えの挙動はレスポンシブイメージを前提としています。


デスクトップ(16:9)


スマートフォン(4:3)


CMSで構築したサイトを実際に稼働してみると、ルーズなトリミングが一切できない写真素材が多いです。画面いっぱいまで人が写っていたり、画面全体が被写体(建物の全景写真、コース料理など)であるためです。

特にメインビジュアルはサイトの顔ですから、少し使いづらくなったとしても実際のウェブ制作で喜ばれる挙動にしようと思いました。

変えたこと.5 object-fitの採用

一方、画像サムネイル用のモジュールで、トリミングが前提になっている .m-thumbnail は、トリミングの手法を変更しました。
Version 1系では、img要素の包括要素にoverflowプロパティを指定してトリミングしていたのですが、Version 2系ではimg要素にobject-fitプロパティを使用しています。

object-fitは、まだIE11とEdgeが対応していません。ですが、簡単なライブラリ追加とCSS修正で実装できるため、私にしては珍しく、標準となりつつある技術を早めに採用しています。

変えなかったこと.1 SMACSSかBEMか

echo.cssは、クラスの命名にSMACSS記法を採用していますが、Sassの設定でBEMに変更することができます。
Version 2系リリース直前の夜中、急に「SMACSSをやめてBEMした方がいいのか」で悩みはじめました。

コーディング関係で発言力があるエンジニアはほとんどBEMですし、最近の大型案件はBEM前提が多いです。このフレームワークがSMACSS=シェアが少ないという理由だけで使ってもらえないのではないかと悩みました。

また、もう一方で「選択できる」機能自体も廃止して、どちらかに固定すべきかとも悩みました。
選択機能は以下のとおり、接続子をSassの変数化することで実現しているので、SCSSファイルをクラス名で検索できなくなってしまうという欠点があるためです。

.#{$pr}#{$c}card#{$c1}contents {
...

最終的には、現状=SMACSSベースでBEMを選択可でFIXしました。

この段階になると制作者の好みで選ぶほかありません。やはり私はクラス名が簡潔なSMACSSが好きですし、US配列キーボード使いなので、アンダーバーを打つためにいちいちシフトキーを押したくなかったのです。

変えなかったこと.2 ユーティリティクラスは必要なのか

ユーティリティクラスというのは、余白を調整したり、文字に色を付けたり、文字サイズを変更したりする調整スタイルのことです。
優先度を最大にする必要があるため、敢えてラッパーのIDを振っています。

#document .u-margin-bottom-sm {
  margin-bottom: 10px;
}

主にサイト公開後のちょっとした変更や、CMSの拡張に使用するのですが、やはりCSS的には無意味というか冗長であるため、これも廃止するかかなり悩みました。

しかしecho.cssも含め、ウェビングスタジオ名義で作ってきたすべてのCMSテーマが「ウェブ制作の現実に歩み寄ったものにする」という方針だったので、きちんとしたコーダーさんに酷評されたとしても、ここは譲れませんでした。
ただし、製作技術の向上で不要になったもの(float, clear)や、アクセシビリティに難があるクラスは廃止しました。

まとめ

このように、いろいろ悩んだり調べたりしてバージョンアップした「echo.css」は、GitHubにてMITで公開しております。
私への許可は不要です。お気軽にご利用ください。フィードバックもお待ちしています。

https://github.com/webbingstudio/echo-css

こうして業務外のプロダクトを公開するようになってずいぶんになります(と言うか、そもそも個人制作の趣味が講じて開業したのですが)。
どんなに技術が向上しても、写真素材やフォント頼みの、見栄えだけのプロダクトは私には作れないと感じます。しみじみ使いやすさを感じていただける、実際に成果を得られるプロダクトを研鑽していきたいです。


投稿者名 うぇびん 投稿日時 2020年02月24日 | Permalink

アクセシビリティを考慮した、チェックボックスとラジオボタンのCSSのサンプル


HTMLのチェックボックスとラジオボタンは、各ブラウザのデフォルトUIのデザイン調整が難しいため、CSSで擬似的なアイコンを表示するのが一般的です。
様々な手法が公開されているのですが、自分でもいろいろ検討した結果、納得できる手法に行き着いたのでサンプルを公開します。

なお、公開中のCSSフレームワーク「echo.css」のチェックボックスとラジオボタンは、すでに実装済みです。
https://cms-skill.com/echo-css/styleguide/module-checkbox.html


投稿者名 うぇびん 投稿日時 2020年01月11日 | Permalink

CSSのフォントサイズの単位問題について考える


「CSSのfont-sizeプロパティの単位には何を使うべきか」という話に思うところがあったので、現時点の私の見解を書いておきます。

まずひとこと言いたいです。
この件に関しては、「論争」も「闇雲な信仰」も起きていません。

「記事を書いた人たちの周辺ではそう見えた」のかもしれませんが、技術者それぞれが考えるべき議題に、煽るような表現を使うことには良い気がしないです。これから学ぶ人が、細かい理由を知る前に萎縮してしまいます。
昨年末からTwitterを周辺に広がっている「コーダーとプログラマの呪い合い」も、根底にはそれがあると思っています。

ということで本題に入ります。


投稿者名 うぇびん 投稿日時 2020年01月10日 | Permalink

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