concrete5のテーマ化する際にCSSで気をつけること

concrete5の利点は「見ているページをそのまま編集できる」という点にあります。と言っても、実際には「見ているページで編集したいところをクリックすると編集用のウィンドウが開く」という挙動なのですが、次のメジャーバージョンでは完全に表示と編集がシームレスになるようです。 この編集スタイルは実際に編集する人には大変ウケがよいです。そりゃあ、実際に見ながら操作したほうがわかりやすいのは当然です。Wiki記法で文書を書くよりもMicrosoft Wordで文章を書く方が一般的には好まれます。ただし、concrete5の場合、技術的にひとつ問題を抱えていまして、表示しているページがHTMLとCSS（とJavascript）で書かれているのは当たり前として、編集する際に表示されるconcrete5が出力するアレコレのユーザーインターフェースもまたHTMLとCSS（とJavascript）であり、「お互いに干渉する可能性がある」ということです。そのため、下記のようなことに気をつけましょう。

concrete5のCSSとかぶるCSSクラス名は避ける

concrete5の管理画面は Twitter Bootstrap が使われています。したがって、 ほとんどは干渉しないように配慮されていますが、なぜか5.6.0.2では .row と .container はメジャーな名前なのにカスケードされずそのまま書かれています。この2つは使わないほうが無難です（将来のバージョンでは修正されるらしい）5.6.1から修正されました。編集中にconcrete5のCSSが読み込まれて、サイトのレイアウトを崩す可能性があります。 逆に、サイトのCSSがconcrete5のUIを崩すこともあります。特にフォーム系にCSSを書くとマズイです。できるだけbody要素にクラス名をつけて、そこからのカスケードとして書くほうが無難です（例： .page input { display:block; } など）。

body に position を設定しない

これ書いちゃうと編集できなくなります。

body { position: relative; }

z-indexは5未満にする

concrete5のUIがz-index:5以降を使いますので、もしサイト内でそれ以上の数字を使うと、concrete5の編集UIより上に来てしまいます。z-indexはできるだけ4以下で使ってください。一時的に表示されるモーダルなどではそれ以上を使っても構わないと思いますが、レイアウト目的で使うと、そのdiv内にはブロックが追加できないと言う症状になります。

ファイルのアップロード位置に依存したコードはなるべく書かない

テーマのフォルダ内に画像をハードコードする際は問題ないのですが、ユーザーに編集させようと思うとどうしてもファイルマネージャーに画像をアップロードさせることになります。concrete5のファイルマネージャーはサーバー上のfilesフォルダ内にランダムなフォルダが作成されて、バラバラに保存されます。 これは何万という数のファイルをアップロードしてもパフォーマンスが落ちないようになっているのですが、逆にどのフォルダにアップロードされるのか事前に予測がつきませんので、もし「画像にマウスを当てたら該当の画像のファイル名の末尾に『_over』を足した画像と差し替える」というようなJavascriptを書いていると動きません。

WYSIWYGエディタで編集できないコードは避ける

これはconcrete5に限りませんが、WYSIWYGエディタで編集するCMSの場合、エディタにボタンが無いHTMLタグはユーザーが入力できませんので、そのようなタグは避ける必要があります。現在のconcrete5はTinyMCEエディタを使用していますので、割と色んなタグが使えますが、たとえばdlタグは入力するボタンがありません。divの入れ子やspanも入力しにくいタグのひとつです。入力できるタグであっても、クラス名をいちいち入力することにストレスを感じるのは当然の反応でしょう。また、concrete5の次期バージョンで採用予定のRedactorエディタはTinyMCEよりさらにシンプルになっています。できるだけプレーンなHTMLで入力できるように配慮する必要があると思います。 一方、concrete5の場合、記事ブロック（WYSIWYG）を使わずに、独自でブロックを作成したり、あるいはナビゲーションやページの一覧などはオートナビブロックやページリストブロックを活用することになるでしょう。これらのブロックの場合はテンプレートで自由なマークアップが再現できますので、このような制約はありません。記事ブロックを使うところはシンプルに、それ以外のブロックを使うところは自由に、マークアップすることができます。ここの見極めは事前に設計しておいたほうが、コーディングを担当する方が迷わずに済むと思います（と言いつつあまりやっていません、ごめんなさい）。

うーん、面倒くさいね

確かにWeb制作者にとっては、制約が増えて面倒です。ただ、実際に日々サイトを運用する方にどれだけ喜ばれるかという意味では、必要なことだと思います。クライアントに喜ばれるための一手間です。コーダーも実際に編集する方の顔を想像しながら作業するのが良いのではないかなと思います。 ほかにも気をつけることはあると思いますので、随時追記していこうと思います。他にもあるの知ってるよ！という方は、ぜひコメント欄で教えてください

---