今朝、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フレームワークは、実際にウェブ制作で頻繁に使用されるモジュールやコンポーネントの集合体であるからです。

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

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

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

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

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

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

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

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

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

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

追記

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

①単位

【em】
親要素のfont-sizeを基準にした相対値。要素のfont-sizeが16px相当だったら1em→16pxとなります。.5emなら16pxの50%の8pxです。font-sizeで可変したいmarginやpadding、あとはletter-spacingもemで指定されることが多いです(サルワカさんおすすめの指定方法)

— TAK (@tak_dcxi) August 6, 2019

テーマの継承＝親子テーマの概念があるa-blog cmsでは、複数のブログで構成されたウェブサイトを製作する場合、子ブログのテーマはルートブログの子テーマとします。

フォルダ構造をざっと書くと以下のとおりです。子ブログ「ニュース」の親ブログには「sample」というテーマが指定されています。
a-blog cmsは「テーマ名@親テーマ名」でテーマの親子関係ができますから、ニュース用のテーマは「news@sample」とすればよいわけです。

            sample ┬ テンプレート
                         ├ テンプレート
                         ├ テンプレート
             　            ・・・

news@sample ┬ テンプレート
                         ├ テンプレート
                         ├ テンプレート
                         　・・・

ですが最近、他の人が製作した親子テーマを使わない「シングルテーマ構築」を見る機会があり、試してみたところ、開発者によっては、親子テーマよりもメリットが大きいかもしれないと感じました。

シングルテーマ構築とは

手法としては、特に凝ったものではなく、かなり昔からあったものです。私自身、Movable Typeで試したことがあります。

テンプレート内にインクルードを書き、ファイル名の一部に「ブログ名」もしくは「ブログID」を引数として渡します。
a-blog cmsで、詳細ページ用テンプレートの場合こうなります。

@include("/_entry/entry_blog_%{BID}.html")

コードネームを取得する変数「%{BCD}」を使って、より直感的なファイル名にしても良いと思いますが、a-blog cmsはルートブログではコードネームがない（NULL）ので「entry_blog_.html」というファイル名になってもよいのかは考える必要があります。

フォルダ構造は以下のようになります。画面ごとに「_top」「_index」「_entry」のフォルダがあり、現在訪問しているブログのIDをキーとして、表示するテンプレートを切り替えます。

シングルテーマ構築のメリット

やったことがない人から見ると複雑そうに感じますが、大規模なウェブサイトほどメリットがあります。

修正漏れが出にくい

親子テーマで構築したときに問題となるのが、子テーマの修正漏れです。親テーマと子テーマはテキストエディタや統合開発環境でファイル一覧を見た場合、かなり離れた場所に表示されます。このため、複数人で開発したり、数ヶ月語に改修をしたときに見落としが出やすくなります。

ファイルを探しやすい

テンプレートが画面ごとにひとつのフォルダに入っており、かつ一意のファイル名になっているので、ファイル名を検索して修正する作業がスムーズです。 親子テーマの場合、「index.html」を探そうとすると、テーマの総数分だけファイルがヒットすることになります。 カテゴリー単位でディレクトリを作っていると、ますます大変なことになります。

他の条件分岐を併用できる

親子テーマの場合、振り分けるのはあくまでブログ単位であって「ルートカテゴリーがitemsのエントリー」などのカテゴリー単位の振り分けは併用できません。
a-blog cmsの場合、「コンフィグセット」機能が追加されたので、カテゴリーごとにテーマを変えることもできるようにはなったのですが、テーマだけではなく同様にコンフィグに含まれている編集設定なども変わってしまうので、あまり現実的ではありません。

シングルテーマ構築のデメリット

説明が必要

CMS構築にそれほど詳しくない人には、事前説明が必要になります。最低でも、ブログIDとコンテンツの対照表がないと、ブログIDの調べ方がわからない人にはどうしてよいかわからないでしょう。

ルールはやはり子テーマ（a-blog cmsの場合）

スマートフォンではテンプレートを差し替える、などの「ルール」機能を利用する場合は、子テーマでなければなりません。

ELSE分岐が面倒（a-blog cmsの場合）

インクルード時にファイル名が一致していなければならないため、「ではない」を条件とした分岐が難しいです。

えっ？IFブロックを使って、こうすればよいのでは…と思うかもしれませんが、

<!-- BEGIN_IF [%{BID}/eq/2] -->
@include("/_entry/entry_blog_%{BID}.html")
<!-- ELSE -->
@include("/_entry/entry_blog_not2.html")
<!-- END_IF -->

a-blog cmsはIFブロックを使用した場合、条件に合致していないコードも処理されます。なので、このような書き方をすると、実質２ページ分の読み込みが発生して処理が遅くなります。

ELSE分岐はこのように、条件に合致しないテンプレートに、さらにインクルードを書くことになります。

_entry.html

@include("/_entry/entry_blog_%{BID}.html")

entry_blog_2.html 以外のブログIDのテンプレート

@include("/_entry/entry_not_blog_2.html")

なお、自作のグローバル変数を作成する知識があれば、 %{IS_NEWS} のような特殊な条件でtrueを返すグローバル変数を作ったり、特定のカスタムフィールドの値をテンプレートファイル名に使ったりできるので、大幅に有用性が上がります。
その場合はa-blog cmsのアップデートやサーバー移転の際に、オリジナルのグローバル変数を定義している /extension/acms/Hook.php を上書きしないよう、資料を書いて共有しておく必要があります。

まとめ：これでいいのか…？

メリットのところで書いたとおり、シングルテーマ構築は、私的には便利でした。途中、ディレクターさんが急ぎの文言変更でテーマを編集しましたが、フォルダ階層を登ったり降りたりしなくて良いので、作業しやすかったようです。

この構築手法は、a-blog cmsの公式テーマの管理画面のカスタムフィールドでは昔から使われています。ですが、公開側のテンプレートについては、ドキュメントでもこのような手法は解説していないので、オレオレカオステーマになってしまわないか、このまま採用し続けて良いものかという迷いがかなりあります。うぇびんたんいつも迷ってますね。

このへん、他の製作者さんの見解を知りたいので、SNSのコメントなどいただけると、とてもうれしいです。

「さくらのレンタルサーバー」のドメイン管理の独特の仕様でハマったので記事にしておきます。

「さくらのVPS」を解約し、ドメインとCMSを「さくらのレンタルサーバー」へ移転したいという依頼でした。

移転当日、いつものように、さくらインターネットの「ドメインメニュー」でDNSを変更して、レンタルサーバー側のコントロールパネルにドメインを登録しようとしましたが、できません。

「さくらのレンタルサーバー」は、以前の所有者のコントロールパネルや移転前のサーバーにつながっていると追加できないというのは以前から知っています。ですが、今回の場合はすでに新しいサーバーへつなぐよう変更しているのに、追加できません。

変更ではなく削除

困って、さくらのサポートへ相談したところ、以下のようなお返事がありました。

さくらのレンタルサーバにドメインの追加設定を行います場合
現在のゾーン情報が削除されている必要がございます。

会員メニュー画面上 "契約情報" → "契約ドメインの確認" →画面右下 [ドメインメニュー] → 該当ドメインの [ゾーン編集]
→ 画面左 [削除] にて現在のゾーン情報を削除ください。

削除後、新しい設定は作成せずにさくらのレンタルサーバの
コントロールパネルからドメインの追加設定を行ってください。

つまり「さくらのレンタルサーバー」に独自ドメインを使用する場合は、同じアカウントが取得したサーバーであろうと、どのような設定であろうと、二回目以降は、一旦設定を削除しなければならない、ということらしいです。

さくらインターネットで取得した独自ドメインが追加できません

これまでずいぶん、さくらのサービスを使ってきたと思ったのですが、VPSからレンタルサーバーへ移転するケースははじめてだったということに、今更気づきました。
お名前.comやムームードメインと同様に、先にDNSの設定をしても良いのだと思いこんでいたのでした。

さくらインターネットのドメインメニュー画面

※画像のユーザーID、ドメインの設定、履歴はでたらめです

削除するとどうなるのか

なるほどそういうことか、ではドメインの設定を削除すればいいですね、ポチ
と削除したところで、この仕様の本当に恐ろしい部分に気づきました。

今回のドメインは、メールはさくらのレンタルサーバーではなく、GsuiteのGmailサーバーを利用していたのです。
削除した時点で、Gmailサーバーへつないでいた設定も全部切断されてしまいました。

お客様には、メールには影響がないとお伝えしていたので大失敗です。平謝りで設定をし直しました。
事前に設定を控えておいたのが不幸中の幸いでしたが、一時間ほどメールの送受信ができなくなってしまいました…

まとめ

結論からいうと、「さくらのレンタルサーバー」への移転の注意点は、以下の通りということになります。

• さくらのVPSなどの他サーバーに接続していたさくらのドメインを使用する場合は、一旦設定を削除しなければならない
• その際にGmailなどの、外部サービスへの接続もすべて切断されてしまう

この業界で15年仕事をしていて、こんな記事を書いていて大丈夫だろうか…と凹んでいます。
いつもと同じ感覚で作業すればいいや、というのが事故の元になることが、改めてよくわかりました…

すでに解決していただきましたが、旧バージョンの管理画面テーマを使用している人が検索するかもしれませんので、ログとして残しておきます。

私が制作したbaserCMSのテーマ「ratio_3_2」に、バージョン4.2から選択できるようになった新しい管理画面テーマを適用すると、SNSアイコンが出なくなってしまいました。

先月リリースされたbaserCMS4.2について、不具合のお知らせです。
ベータ版として同梱されている管理画面テーマ「admin-third」を有効にすると、ratio_3_2のFontAwesomeのアイコンがリンク切れになる不具合を確認しています。（続く） #baserCMS pic.twitter.com/oL9Y1ItiQp

— うぇびんさん (@webbingstudio) 2019年7月15日

調べたところ、以下の原因が判明しました。

• baseCMSはログイン中、ヘッダに常時ツールバーが表示される
• ツールバーでは、FontAwesomeの5系が使用されている
• FontAwesomeは、4系と5系を同時に使用すると、4系のアイコンが正常に表示できなくなる（クラス名が重複しているため）。

ratio_3_2だけでなく、FontAwesomeの4系が使用されているテーマはすべてこの不具合が発生する可能性がある、ということで、FontAwesomeをツールバーに使用しないように修正していただきました。ありがとうございます。

2019年7月20日時点では、まだ公式サイトのダウンロードファイルは更新されていません。気になる方は、baserCMSの公式リポジトリから、最新バージョンをダウンロードしてください。

https://github.com/baserproject/basercms

テーマだけ差し替えたいという場合は、 /app/webroot/theme/admin-third/ 以下を差し替えればOKです。

まだベータ版ですが、baserCMSの新しい管理画面用テーマは、デザインやカラーリングのバランスが取れていて、旧テーマよりもかなり使いやすいと思います。日常的にbaserを使用している方は試してみてください。

地味なTIPSなのですが。
a-blog cmsのインクルードは、themesからのパスで記述すると、他のテーマのファイルを参照することができます。

冒頭の図のように、theme_a から theme_b にある file_b.html を参照する場合は以下のとおりです。

@include("/themes/theme_b/file_b.html")

これを利用すると、テーマの関係を無視することができます。

と書いた時点で、CMSの構築に慣れている人は悪い予感しかないと思います。実際、これの多用はおすすめできません。なんのために「テーマ」という概念があるのかわからなくなります。

ですが、これを活用できる状況もあります。

• 期間限定で、特定のページを大幅に差し替えたい
• サイト公開後の一定期間だけ、ティザーサイトを公開したい

などで、一時的に退避する本来のページも、別URLで閲覧できるようにしたい場合 です。

実際の手順とともに解説します。

※本来のページを移動する必要がない、かつ、一部のユーザーだけ見られれば良い場合は後述します

テーマ間インクルードの使用例

まず、ティザーサイト用の子テーマを作成し、本来のページと同じファイル名で差し替え後のページを作成します。
ここではわかりやすくするために親テーマ名を公式の site2019 、トップページを _top.html にします。
本来のページは top_02.html に退避させます。

teaser@site2019
  ├ _top.html
  └ top_02.html

一般的な親子テーマの継承を考えると、この構成にした時点で、親テーマの _top.html はティザーサイト用のテーマに上書きされ、参照できなくなります。
このため、退避した top_02.html には親テーマと同じコードを書かなければなりません。

もしもティザーサイトを公開中に top_02.html だけを編集して、それを忘れたままテーマをもとに戻すと、トップページに巻き戻りが発生してしまいます。

ここで、テーマを超えたインクルードを使います。

top_02.html のファイルを空にして、冒頭の、他のテーマを参照するインクルードを書きます。

@include("/themes/site2018/_top.html")

これで、ティザーサイト用のテーマ側で、親テーマのトップページを編集することはなくなるので、期間が終了したらテーマをもとに戻すだけで済み、安全な撤収ができます。

一時的な差し替えへの様々な対処

ウェブ制作に最適化されたa-blog cmsは、一時的なページ差し替えには、テーマ間インクルードの他に様々な対処法が用意されています。

参照テンプレートを変更するURLコンテキストを使う

退避前のページが非公開で良い場合、改修後のページをチェックしてほしい場合に使えます。URLの末尾に /tpl/(テンプレートファイル名) を追加すると、指定したテンプレートに同じデータを反映したページを見ることができます。

条件分岐を使う

ログインしているときだけ退避前のページを表示したいときに使えます。ただし、更新担当者は常時ログインしているので、この方法だと難色を示されるかもしれません。

ルールを使う

cookieや端末で動的にテーマを差し替えたい場合に使えます。期間も設定できるので自動終了できますが、管理画面から設定するので、a-blog cmsの構築に慣れていないとルールが適用されていることに気づきにくいです。しっかり情報共有をしなければなりません。

以上、いろいろな手段が考えられるのですが、ファイル1点くらいの入れ替えであれば、テーマ間インクルードが一番共有もしやすいように思います。ファイルを見たら、一行しか書いていないので、親テーマをそのまま読み込んでいることがすぐわかります。

いつもの手法や、開発元が推薦している手法にこだわらず、現在のプロジェクトの状況でもっとも良い方法を選定したいものです。