Hatena::ブログ(Diary)

Webデザインの日々日記 RSSフィード

2016-11-07

WordPressプラグイン PS Disable Auto Formatting は削除すべき時期に

WordPressのビジュアルアエディタ、TinyMCEのおせっかい機能(勝手にpタグを入れたりbrタグを削除したり)を停止させてくれる優れたプラグインでしたが、TinyMCEの仕様変更で機能しなくなっていました。

ちなみに同様の機能を持つ各種のプラグインも軒並み、おせっかいの停止機能に不具合が生じるようになっています。(有効にしているとビジュアルエディタとテキストエディタの切り替えができなくなるトラブルに見舞われる)

そのため導入していたサイトのほとんどでこのプラグインの機能を停止させていたのですが、本日プラグインサイトを見ると、更新が2年前から止まっていました。

PS Disable Auto Formatting — WordPress Plugins

いつか復活するのでは? との望みを捨てきれずにいましたが、更新停止が1年を超えてくるとセキュリティ面の不安が生じます。

優れたプラグインを提供してくれた開発者さんに感謝しつつ、現在入れているサイトから順次削除していくことにしました。

2016-11-06

ウェブデザイン技能検定2級対策:フォーム

普段コーディングしていて、実はform周りはあまり使う機会がありません。WordPressとかだと、プラグイン使っておしまいですからねぇ。。。

で、このformが実技に毎年出ています。内容はほとんど同じなのでこれを機会に勉強してしまおうというのが今回の記事の趣旨。

下準備

XAMPPを使っているので練習はhtdocsフォルダで。

htdocsに新しいフォルダを作って、そこで取り扱いを覚えます。

エディタDreamweaverを使用。

新規フォルダ内に index.html と form.phpを作成。

試験問題の中身としては、

  • form のactionとmethodの指定
  • inputのタイプの適切な選択(text, password, hidden, mail, radio, checkbox, submit, reset)
  • textareaの設定
  • selectの設定と配列での送信
  • valueプロパティ(初期値)の取り扱い

あたりが出題範囲。

以下復習。

form

<form action="form.php" method="post">
</form>
form

送信するデータの入力エリア

action

データの送信先。ここではform.phpに入力したデータを送信する。送信されるデータは$_POSTあるいは$_GETのスーパーグローバル変数に入っているので、受け手のPHPプログラムはデータをこれらの変数から取り出す。

method

postまたはget。通常はpost。GoogleMapなどデータをURLに追加してやり取りする場合にgetを使う。

enctype

デフォルトでは指定不要だが、フォームからファイルを送信する場合は、enctype="multipart/form-data"を指定する。

label

<label for="name名">ラベル名</label>

name名のinput要素に対するラベル。for=""で対応するinputのname名を指定することで、ラベル名をクリックしたときに入力エリアにカーソルが入る。アクセシビリティを高めるためこの関連付けは大事。

検定試験では送信する各パラメータのタイトル名を入れる。

input

<input type="type名" name="name名" value="初期値" size="">
name=""

action先に渡す変数に入れるキーの名前

name, tel, user, emailなど、分かりやすいものを入れる。検定試験ではHTTPリクエストインターフェイスに指定されている文字列を使用する。

配列を入れたい場合は、name="name[]"として入れるか、name="name[0]" name="name[1]"…のように配列番号を入れる。

[]内に番号を入れない場合は最初に出てきたものから順番に0、1、2…とキーが割り当てられる。

value=""

inputの初期値を入れる。textであれば入力フィールドに最初からその文字が入る。

size=""

入力フィールドの長さ(文字数)を指定する。省略可。

type="text"

1行テキスト入力フォーム

type="mail"

メール専用のテキスト入力フォーム。メールアドレスのフォーマットではない文字列の場合、ブラウザの方で勝手に警告を出して拒否してくれるので便利。

type="password"
<input type="password" name="" size="" maxlength="">

パスワード入力フィールド。入力した文字が伏字になる。maxlengthで最大文字数を指定することができる。

type="hidden"
<input type="hidden" name="" value="">

ユーザーが入力する必要のない情報を送信するための非表示フィールド。value値必須。

type="radio" value=""
<input type="radio" name="name" value="選択肢1" id="radio1" checked><label for="radio1">選択肢1</label>
<input type="radio" name="name" value="選択肢2" id="radio2"><label for="radio2">選択肢2</label>
<input type="radio" name="name" value="選択肢3" id="radio3"><label for="radio3">選択肢3</label>

ラジオボタンを設置する。

label for=""の値に対応するのはidになるので注意。

どちらかというとinputごとlabelで囲むとこれらの指定が省けるので楽。

排他選択になるため、nameの値はすべて同じものにする。

value値は必須。

checkedを付けたラジオボタンは初期で選択された状態となる。

type="submit" value="送信"

送信ボタン

type="reset" value="リセット"

リセットボタン

type="file" accept="MIMEタイプ"

フォームでファイルを送信するときに使う。

※Edge,iOS Safari,iOS Chromeは対応していないため、試験問題として出る可能性は低いかもしれない。

textarea

<textarea name="" rows="" cols=""></textarea>
name

action先に渡す変数に入れるキーの名前

rows

行数

cols

select

<select name="" size="">
<option value="" selected>選択肢1</option>
<option value="">選択肢2</option>
<option value="">選択肢3</option>
</select>
name

action先に渡す変数に入れるキーの名前

size

デフォルトは1。指定した数字がリストボックスの表示行数となる。

option

選択肢。選択肢の数だけ列挙する。

value

送信値。選択肢の文字列をそのまま送信する場合は指定不要。

selected

デフォルトで選択される選択肢に対して指定する。

正しく送信されているか確認

送信側(index.html)のフォームのコード

※selectのオプションは一部省略。

<form action="form.php" method="post">
	<p><label for="name">名前</label></p>
	<p><input type="text" name="name"></p>
	<p><label for="mail">Emal</label></p>
	<p><input type="email" name="mail"></p>
	<p>日時</p>
	<p><label><select name="date[0]">
	<option>1</option>
	<option>2</option>
	<option>3</option>
	</select>月</label>
	<label><select name="date[1]">
	<option>1</option>
	<option>2</option>
	<option>3</option>
	</select>日</label>
	<label><select name="date[2]">
	<option>0</option>
	<option>1</option>
	<option>2</option>
	<option>3</option></option></select>時</label></p>
	<p><label for="address">住所</label></p>
	<p><input type="text" name="address"></p>
	<p><label for="question">お問い合わせ内容</label></p>
	<p><textarea name="question"></textarea></p>
	<input type="submit" value="送信">
</form>

受信側(form.php)のコード

<?php $date = $_POST["date"];?>
<p>名前:<?php echo $_POST["name"] ;?></p> <p>email:<?php echo $_POST["mail"] ;?></p> <p>日時:<?php echo $date[0] ;?>月 <?php echo $date[1] ;?>日 <?php echo $date[2] ;?>時</p> <p>住所:<?php echo $_POST["address"] ?></p> <p>お問い合わせ内容:</p> <p><?php echo $_POST["question"] ;?></p>

index.htmlで送信ボタンを押すと、form.phpへページが遷移し、入力結果を表示することができる。

2016-11-04

WordPressプラグインLightbox Plus Colorbox が公式ディレクトリから消滅していた。

少なくとも半年前(2016年4月ごろ)には公式ディレクトリからなくなっていた模様

クライアントのサイトをメンテしていたところ、Lightbox Plus Colorboxが公式ディレクトリで検索しても出て

フォーラムで「見当たらないよー」という声がありました。

Lightbox plus colorbox plugin I can't find it anywhere? - SiteOrigin

このプラグインは特別な操作なしに使えたので重宝していたのですが、こうなっては速やかに代替プラグインを探すしかありません。(セキュリティ面でよろしくない状態になりますので)

Responsive Lightbox by dFactory が移行しやすい

移行手順としては、

  1. テストサイトでLightbox Plus Colorboxを停止。
  2. テストサイトでResponsive Lightbox by dFactoryをインストール、有効化。
  3. テストサイトでの動作確認。必要に応じて設定を変更。
  4. 正常に動作するなら、本番サイトのデータをバックアップして上記1〜3の手順を実施。
  5. 本番サイトで正常動作を確認後、本番サイト、テストサイトともにLightbox Plus Colorboxを削除。

今回のサイトではこのプラグインで問題ありませんでしたが、他のサイトではプラグインの衝突などあるかもしれませんのでテストサイトでの確認は必須ですね。

2016-09-23

floatで並べていたタイルをflexboxで書き直す

タイルレイアウトをfloatで実現するにはタイルの高さをそろえるためにheightを固定するとかしなきゃいけない。

WordPressみたいに記事からタイトルとサムネイルを取り出して並べる場合はタイルの中身がはみ出すというトラブルによく遭遇する。何でそんな縦に長い写真を使ってるんだとかお前タイトル長すぎだろうとかそういうのが原因。

仕方がないので、height固定はあきらめてmin-heightである程度高さを持たせてレイアウトすることが多い。

そんなことをやっていたのは1年ほど前までで、IE8も9も公式には存在しないことになっている今となってはflexboxレイアウトを導入することができるよねと。

で、これまでfloatで配置していたものをflexで書き換えるにはどうするかと。

このとき、heightではなくmin-heightで調整していたのなら簡単で、並べているタイルの一群をラップするdiv箱を作って、そこにflexboxのプロパティを設定するだけでよい。

例えばラップするdivのクラス名を"flex"とした場合、CSSには以下の記述を追加する。

.flex {	
  display: -webkit-box;
  display: -webkit-flex;
  display: -ms-flexbox;
  display: flex;
  align-items: stretch;
  -webkit-flex-direction: row;
  -ms-flex-direction: row;
  flex-direction: row;
  -webkit-flex-wrap: wrap;
  -ms-flex-wrap: wrap;
  flex-wrap: wrap;
}

webkit系のベンダープレフィクスはもう要らないかも。

子要素の幅の調整とかは従来floatで行っていたwidthの値がそのまま生きるから気にしなくていい。

また、子要素にfloatの指定が残っていても、flexboxの方が優先される。つまりfloat: left;で、親要素に flex-direction: row-reverse; がある場合、子要素は右詰めで並ぶ。

floatとの混在はあまりきれいなものとは言えないかもしれないが、IE9以下がしぶとく使われそうな日本の状況では残しておくとレガシー対応となってよい感じになる。

新規に作る場合でレガシー対応せざるを得ない場合

デバッグ済みのフレームワークを使う。bootstrapとかは重くて扱いにくいのでKomitsuboshi-cssを使っている。自分で作るのは大変だけどかなり勉強になる。

IE8,9でもmatchheight.jsを使えばflexboxみたいに高さを合わせることができる。ただしdisplay:none;してる要素の高さも計算するらしいのでその点は注意が必要。

「時代遅れになるUX」ってのはUXの話じゃ無いんじゃね?

UX論は間違っているんじゃなくて時代遅れなんじゃないの?という疑問 - architecture_database

そもそもUXって、「時代遅れになる」ような代物じゃないだろうと。「事業計画の立案は時代遅れになる」なんてことを言っているようなものである。

UXってのは「お客さんの体験」であり、UX論は「お客さんにどんな体験をしてもらうのか」って話。

UXを提供するのも、UXを考えるのも、そこら辺のお店の店員がずーっとやってきてる。時代遅れも何も、商売の基本だよね。物やサービスを売ることって、流行したり廃れたりするものなの? 経済の土台とともに存在しているんだから、これが「時代遅れ」になるってのは、経済そのものが終わってからの話になるんじゃないだろうか。

そもそもUXってのはお客さんにどうやって物事を提供するのかを改めて考え抜きましょうよと言う話であって、本質的には事業者が日常やっていることでしかない。

だからこそあなたも私もUXデザイナー、社長も下っ端もみんな「UX」考えましょうということになる。

もしかしたら、「UXデザイナー」なんてなじみのないオシャンティな名前が壁になって、関係者を巻き込めない、なんてことになっているかもしれない。そういう視点からは、「『UX』という単語で事業の見直しを行うのは悪手になりつつある。」ということは言えるかもしれない。


「退会させない設計」やソシャゲのガチャ設計の問題は、それが劣悪であるというだけでそれが「UX」であることに間違いはない。その事業者はそういう選択をしたというだけのこと。

射幸性の高い設計を好むかどうかはユーザー次第であり、高い射幸性を求めるユーザーを満足させたいUX設計が他のタイプのユーザーに不適切であるのは当然のこと。万人を満足させるUX設計は無い。

そして違法性や倫理性の問題はUX以前に考えることでありUXの話ではない。「UXデザイナーは法律への対応もしてくれるのか」なんてのは、物理の授業で「国語は教えてくれないの?」と言うようなものである。日本語で教えているからと言って物理の授業で国語も教えるべきなどと言うのはただの暴論である。



ここまで書いておいてこんなことを言うのもなんだが、私はUXにはあまり関心がない。なので上で書いている「UXって要は客の『体験』を考え抜いた設計だろ?」という私の解釈が正しいというつもりはない。しかしあれもこれもUXと言うのであれば、それは「事業」という日本語で適切に代替できる。改めて名前など与えなくても、みなすでに真剣に考えていることである。それを新しいことのように解釈することにどれだけの意味があるのだろう?

2016-09-07

「プロが実践するモダン CSS の書き方入門テクニック20選まとめ」を補足

プロが実践するモダン CSS の書き方入門テクニック20選まとめ - PhotoshopVIP

1. 縦方向のマージン

他のプロパティとは異なり、縦方向のマージン幅はうまく効きません。

「うまく効かない」ではなく「相殺される」「重複する」と訳すべきでしょうね。

横方向のマージンは単純に足していけばよい一方、縦方向のマージンは相殺(重複)されるのが仕様です。

この特性が余白に関して想定していない問題を発生させることはよくあります。その代表的な例を2つ紹介します。

親要素にマージン・パディング・ボーダーがなく、子要素にマージンが設定されている場合、子要素のマージンが親要素のマージンに見える

例えば、

<header><h1>タイトル</h1></header>

というコードで、headerのmargin-top、padding-top、border-topが0で、h1にmargin-topがある場合、headerの上にh1のマージンが設けられます。

ここでheaderに背景色を設定していると、headerの上に白い余白が発生します。

「なんだこの余白?」と思ってデバッグしようとするとheader内にあるすべての要素のmargin-topの設定を確認しなければならず、面倒くさいことになります。

ボックス要素が入れ子になっているときに、縦方向に想定以上の余白が発生する

親要素にpadding-top, border-topがない場合、親要素のmargin-topと子要素のmargin-topは相殺されます。

一方、親要素にpadding-topまたはborder-topがある場合、子要素のmargin-topは、親要素のcontentから計算されます。その結果、親要素のmargin-topと子要素のmargin-topは相殺されなくなります。

この時、親要素に背景やborder-topがない場合、子要素の上の余白が妙に広く見えることになります。


margin-topを原則0にして、margin-bottomで縦方向のマージンを制御する方法は、これらの問題の回避に有効です。

2. レイアウトに Flexbox

日本では古いIEがしぶとく生き残る傾向があるので、Flexboxの活用はもうしばらく先のことになりますね。

jQueryライブラリmatchHeight.jsを使うことで、floatを使いながらもカラムの高さをそろえることができます。

また、横方向の等幅分割を実現する際には、Flexboxよりもdisplay: table; table-layout: fixed;を使う方がブラウザ間の差異をなくすことができます。

新しいプロパティを活用するのはウェブデザインの楽しみの一つですが、安定した「枯れた」テクニックを活用するのもプロに求められる資質ではないかと思います。

3. CSS リセット, 4. Border-box をすべてに適用

原則的に既存のライブラリを使うべきです。元記事では全称セレクタを使ったやり方が紹介されていますが、これは基本的にバッドノウハウです。(言い切っていいのか?)

全称セレクタを使ってよいのは box-sizing: border-box; くらいで、他のプロパティを全称セレクタでリセットするのは継承が失われる副作用の方が強いので避けた方がよいです。

5. イメージファイルは背景に適用するべきではない

なぜimg要素の代わりにbackground-imageを使ってはいけないのか。

理由の筆頭は、「アクセシブルではないから」です。背景画像にはalt属性を付けることができません。装飾以外の機能を持たない画像ならともかく、メインコンテンツの一つとして画像があるのなら、このようなテクニックの採用は即却下すべきです。

アクセシブルではないサイトは、SEOの面で不利になります。

また、この方法は空divというあまり褒められないコードが増えるため、この点でも評価は下がるでしょう。

これらの問題を解決するために、背景画像を用意したdiv要素内にalt属性にあたる解説文を付けるという方法もあるかもしれません。しかしその文字は画像の上に被って表示されます。alt属性の代替とするには text-indent: -120%; overflow: hidden; なんて方法を使わなければなりません。(今はどうかわかりませんが)MacOSChromeだとこれでも1文字だけは表示されます。そしてGoogle検索エンジンは隠しテキストと判断してやはりサイトの評価を下げるでしょう。

元記事にはこの点への言及があるものの、翻訳記事の方でこの重要なポイントをばっさり削除してしまっています。

その結果、まったく褒められない行為を推奨する記事と化してしまったことは残念なことです。

レスポンシブデザインに対応するなら、次の方法が最も簡便に行えます。

画像にはheight: auto; を活用する。

例えば、画像の幅をウィンドウ幅の50%にして、縦横比を元画像と同じにしたいときはこうします。

img {
  width: 50%;
  height: auto;
}

これだけです。わざわざdivを用意して、それぞれに高さ、幅を付けて、背景画像を用意して、なんて面倒なことは不要です。

十分なサイズ(表示したいサイズの2〜3倍の解像度)の画像を用意すれば、スマートフォンのような高精細ディスプレイでもきれいに表示されます。

十分なサイズの画像が用意できず、width: 50%; では画像が引き延ばされてぼやけてしまう場合は次のようにします。

img {
  width: auto;
  max-width: 50%;
  height: auto;
}

これで画像は元サイズ以上に引き延ばされることはなくなります。

6. リストテーブル

まあ、border-collapse: collapse; は基本ですね。ここではレスポンシブ対応について補足します。

テーブル要素のレスポンシブ対応

ちょっと気になるのは、「リスト用テーブル」ってところでしょうか。リスト目的ならdl要素を使うのがセマンティックにできると思います。

もっとも、dlは枠線のコントロールなどが少し面倒になるので、十分な時間がない場合はtableの利用もありうるでしょう。タイトル部にthを、説明部にはtdを使えばそれなりに意味は通ります。

さて、タイトルと説明、というような2列しかないテーブルをレスポンシブデザインに対応させるときには、displayプロパティを活用します。

ブレイクポイントを通過したところで、th, td 要素に display: block;を適用すると、横並びの表組を崩して縦に並べることができます。

リスト用ではなく、本来の意味での表組で、横並びを崩すことができない場合は、tableをdivで囲み、

div {
  width: 100%;
  overflow-x: scroll;
}
table {
  width: 100%;
  min-width: 640px;
}

のようにして、一定の幅を下回ると(上記の場合640px)表のみ横スクロールが発生するようにします。

7. 読みやすいコメントを記述しよう。

あと、CSSの冒頭にコメントアウトで目次を付けるのも有用です。

8. クラス名に「串刺しスタイル」を利用

WordPressのCSSコーディング基準はそうなってますが、それが絶対ということはありません。

私もハイフンつなぎを好んで使っていますが、みんな好きにすればいいんじゃないですかね。MindeBEMdingなんてハイフン2個とアンダースコア2個なんて気持ち悪い感じ(いまだに慣れません)でやってますし。

とはいえ、アンダースコアは、ハイフンに比べて2つの点で劣ります。

一つ目は、アンダースコアはハイフンに比べて目立たず、存在を見つけにくいという点。

二つ目は、タイプ時にShiftキーとの組み合わせが必要で、かつキーボードホームポジションから最も遠いためタイプミスを犯しやすいことです。

そのほか、相性面での問題として、WordPressの場合、コーディング基準に違反することになります。また、Bootstrapなどの主要なフレームワークの多くはハイフンつなぎなので、それらと組み合わせると命名に規則性がなくなり、メンテナンス性が悪化します。この相性問題はキャメルケースを使った場合も同様です。

9. 繰り返しを避けよう。

補足は必要ないですね。

特にフォント回り(font-family, font-size, line-heigt)に関してはhtmlかbodyで初期値を設定します。

これを全称セレクタ(*)に適用してしまった場合は地獄を見ることになります。

その他

10〜20は大きく補足するようなことはないかなと。

14. 大文字

CSSで制御すべきなのでしょうか。状況次第のような気がします。

元サイトでは「賛同できない。セマンティックにやるなら<em>を使うべき。」とのコメントが寄せられていますね。

15. rem

remは、IE9,10ではショートハンドでは使えないという制限があります。

元記事において

pxはもっとも正確性がありますが、レスポンシブデザインでは拡大縮小スケールに対応していません。

とあるのですが「拡大縮小スケールに対応していない」というのがよく分からないですね。普通にctrl+マウスホイールでレスポンシブに拡大縮小できるので。

一方、IEではpxで指定した場合、メニューから「文字サイズの変更」を行っても文字サイズが変わらないという問題があります。それゆえアクセシビリティ/ユーザビリティ界隈ではpxの使用を避けるように言われているのですが、メニューから文字サイズの変更を選ぶ人ってどのくらいいるんでしょうね。

HTMLにfont-size: 10px;として、文字サイズをremで指定すると計算しやすくてよいかもしれません。

16. 大きなプロジェクト

Sassは書き方がCSSに近いため、学習コストが低いのが特徴です。まだ試してない人はさっさと導入しましょう。

大きいプロジェクトであれば、Sassの他にコードの可読性を上げるCSSCombの利用も重要だと思います。主要なテキストエディタのほとんどで利用可能です。

18. 圧縮コードの利用

私は圧縮コード(ミニファイ)には否定的な見解を持っています。画像などと異なりもともと大したファイルサイズではないですし、改行コードやスペースを削除したところで大幅にファイルサイズが減るわけじゃありません。

読み込み時間を改善するのなら、まず読み込むファイルの数を減らすのが先だろうと思います。CSSやjsファイルはなるべく一つにまとめる、CSSで代替できる箇所には画像を使わない、WordPressであればプラグインを入れすぎていないかなど、検証すべきところは多々あります。

本気で取り組むならgzip圧縮やCDNの活用の方がはるかに効果的でしょう。

また、CSSフレームワークではBootstrapが人気ですが、これは(CSSファイルにしては)巨大で、しかもその機能の7割くらいは使われず無駄になっています。またBootstrapのグリッドシステムはその構造上、HTMLの肥大化を招きやすい問題(グリッド間の余白を作るのに内部にdivを追加する必要があるなど)を抱えています。

読み込み時間を短くしたいのならまずは上記のような無駄をそぎ落とすのが先であって、それらをやったうえで、1バイトでも無駄を削り切りたいときにミニファイは行うべきだろうと思います。