フロントエンドエンジニア・うぇびんのよしなし語り
HTMLのチェックボックスとラジオボタンは、各ブラウザのデフォルトUIのデザイン調整が難しいため、CSSで擬似的なアイコンを表示するのが一般的です。
様々な手法が公開されているのですが、自分でもいろいろ検討した結果、納得できる手法に行き着いたのでサンプルを公開します。
なお、公開中のCSSフレームワーク「echo.css」のチェックボックスとラジオボタンは、すでに実装済みです。
https://cms-skill.com/echo-css/styleguide/module-checkbox.html
「CSSのfont-sizeプロパティの単位には何を使うべきか」という話に思うところがあったので、現時点の私の見解を書いておきます。
まずひとこと言いたいです。
この件に関しては、「論争」も「闇雲な信仰」も起きていません。
「記事を書いた人たちの周辺ではそう見えた」のかもしれませんが、技術者それぞれが考えるべき議題に、煽るような表現を使うことには良い気がしないです。これから学ぶ人が、細かい理由を知る前に萎縮してしまいます。
昨年末からTwitterを周辺に広がっている「コーダーとプログラマの呪い合い」も、根底にはそれがあると思っています。
ということで本題に入ります。
ポケモンがたくさんとれる公園
結婚して半月が経ち、だいぶ生活が落ち着いてきました。
先週から、ウェビングスタジオとしての業務も再開しております。
今後は一般の土日祝以外に、木曜日もお休みをいただきます。
土曜日を勉強や自分のサイトの作業に宛て、日曜日と木曜日は完全に仕事をしない日にするつもりです。
これは以前から決めていたことで、夫の唯一の休みが木曜日というのが主な理由ですが、私自身の今後を考えてのことです。
ここ数年、勉強に充てる時間が取れないことが悩みになっていました。世の中はどんどん新しい技術が登場していて、この先もウェブの仕事を続けていくには必須の知識もあるのですが、通常業務をこなすのに手一杯で、勉強会の準備をプライベートの時間や睡眠時間を削ってやるような状況でした。
若い頃はそれでなんとかなっていましたが、40歳を超えたあたりから体がついてこなくなってきて、「ブログの更新や勉強に充てる休日」が必要だと考えるようになりました。周囲でも海外では週休三日だという話がちらほら出ていました。
一緒に暮らす人ができたことで、少しだけ必死に働かなくてもよくなり、その代わり、少しだけ家事が増えました。
ウェブの仕事は私の天職なので生涯続けたいですが、続けるために、敢えて仕事のボリュームを減らそうと思います。
しかし、初回から理想通りに行っていません。木曜日はのんびりできましたが、土日は働いていました…
まあ、人生は長いです。焦るとすぐ力尽きてしまうので、試行錯誤しながら新しいライフサイクルに慣れていきたいと思います。
このたび、北海道札幌市から愛知県豊橋市に転居し、結婚いたしました。
緊張のあまり「けっきょん」とタイピングしてしまったのは内緒です。
結婚は、一般にはプライベートのお知らせです。ですがフリーランサーの場合は事務的なご連絡もあり、全国の友人知人にご説明するのもなかなか大変ですので、公開記事とさせていただきます。
9月23日に書いた記事「CMSの管理画面でクラス名を変更できるようにしたことを後悔している」の続きです。
この記事を読んだプログラマの友人に
「モジュールに設定したクラス名一覧を資料化すればいいのではないですか？」
と聞かれました。
当初はこれについても書くつもりでしたが、結論から言うと諸々の問題で難しいのと、ますます記事が長くなるので追記しなかったのでした。
この件について改めて書いてみたいと思います。
一時期、管理画面で表示されている「モジュールID一覧」のHTMLをPDFに書き出し、資料として納品時にお渡ししていたことがありました。
a-blog cmsは、CMS内の設定（IDがnewsのカテゴリーのエントリーを5件呼び出す）に名前をつけて「モジュールID」として使い回すことができます。DrupalのViewsも同様だったと思います。
これもクラス名と同様、管理画面でしか参照できないものです。なので友人の指摘の通り、資料化しようと考えたのです。
ですが、これには以下のような問題がありました。
これはウェブ制作全体の問題ですが、「サイトマップ」「マニュアル」以外の資料には、あまり価値を見いだされません。企画を重視していない案件では「カスタマージャーニーマップ」さえ予算がつくのが難しいでしょう。それ以前に私は受注制作がメインなので、予算に関われる案件はまずありません。
もしこちらから「モジュールID一覧もお送りしますね」と言っても、たぶん「いやー、いらないですよ！」と返事が来ます。
なので、できるだけシステム化して、こちらの見積内に組み込むことになります。よほど効率化しないとタダ働きになります。
そうやって頑張って作成しても、サイトの改修自体がないことが多いです。私自身も完全納品だと、その後は声がかからないので使うことはありません。前回の記事のように、常時改修をお手伝いさせてもらっている案件もまれにありますが、全体の一割くらいです。
もしかすると、多くの納品先が、このような資料を必要としていたのかもしれません。しかし何も言われないのでわからないのです。あー、SNSでつながっている方、その後必要だったかこっそり教えて下さい…
オフラインの資料にしてしまうと、管理画面の内容を更新したときに資料も更新しなければなりません。資料と最新の状態が食い違うのはまずいです。 これは友人も指摘していました。むしろ資料作成を重視するプログラマさんやSIerさんは、こっちを気にすると思います。
そこで「管理画面に、モジュール関連の必要な情報だけを一覧できるテンプレートを作ればいいのでは？」と考えました。
テーマ内に含むようにできれば、毎回資料を作成する手数もなくなります。
a-blog cmsなら簡単にできるかもしれないと、管理画面にざっと書いてみたテンプレートがこれです。
<!-- BEGIN_MODULE Admin_Module_Index -->
<!-- BEGIN module:loop -->
mid: {mid}<br>
モジュールID: {identifier}<br>
<!-- BEGIN status#open -->
<span class="acms-admin-label acms-admin-label-info admin-status-label acms-admin-text-nowrap"><!--T-->有効<!--/T--></span><!-- END status#open --><!-- BEGIN status#close -->
<span class="acms-admin-label acms-admin-label-danger admin-status-label acms-admin-text-nowrap"><!--T-->無効<!--/T--></span><!-- END status#close -->
<br>
<!-- BEGIN_MODULE\ Admin_Module_Edit ctx="bid/%{BID}/mid/\{mid\}" -->
説明: \{description\}<br>
追加クラス: \{module_exclass\}<br>
追加属性: \{module_exattr\}<br>
<!-- END_MODULE\ Admin_Module_Edit -->
<hr>
<!-- END module:loop -->
<!-- END_MODULE Admin_Module_Index -->Admin_Module_Indexモジュールは、モジュールIDの最低限の情報を一覧表示するモジュールです。
ループ内でエスケープされているAdmin_Module_Editモジュールは、指定したモジュールIDの詳細情報を出力し、GET送信すれば編集可能にするモジュールです。
いずれも管理画面専用です。
ここまで一画面で表示できればかなり便利になると思ったのですが…
残念ながらAdmin_Module_Editに属性値でIDを渡すことができないようで、説明文やクラスは表示できませんでした。何か間違えているのかもしれませんが。
となると、PHPを書いて、データベースへの直接のアクセスが必要になります。さすがにそこまでする必要があるかは微妙です。
かつては汎用CMSとは、本格的なエンタープライズCMSではなく、ごくごくシンプルなものでした。
ですが利用者が多いWordPressであっても、納品後にもコーディングに関与できる「リッチCMS」の採用が当たり前になっています。
制作側もこれまでのように作るだけで終わらせず、納品から半年後、一年後の改修で無駄な工数を食わないよう、対策を講じなければならなりません。
消化不良ですがこの話題はまたいつか。