Hatena::ブログ(Diary)

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

2016-07-23

Re:知らないと恥ずかしい。今さら聞けない、読みにくいタグ用語15選。

別に読めなくても恥ずかしくはない。

【HTML&CSS】知らないと恥ずかしい。今さら聞けない、読みにくいタグ用語15選。【プログラミング】 - いしだの話

どちらかというとタグではないものをタグと呼んでいるあたりが気になるかな。

あとどこから手に入れた知識かは知らないけど読み方は一部を除いてあまり気にする必要はないと思う。

a

アンカーは正式名称。普通はエーと呼んでいる。むしろアンカーでは通じないことが多いと思う。

href

これタグじゃなくて属性ね。

エイチレフ、なんでhだけ別なんだと言うけど、英語では最初の文字だけアルファベットで読むことはよくあること。

元になっているのはHypertext referenceだから、エイチレフと読む方が意味を忘れにくくなる。

ちなみにリンク先を指示する属性にはsrcもあり、ソースと呼ぶらしいが僕はエスアールシーと(心の中では)読んでいる。sorceから来ているから正しくはソースなのだが、タイプするときはエスアールシーと唱えている。

alt

だからそれは属性だと(ry

まあ、オルトだよね。キーボードのAltもオルトだし。オルタナティブ代替)だからオルトだ。imgタグにはaltを付けろ。中身が空でもaltを付けろ。付けないやつはアレだよアレ。

dir

これも属性(3度目)。


なんか元記事の人がごちゃまぜにしている感じがあるので念のため書いておくと、単にタグというと<>で示された文字列のことを指し、「何とかタグ」というときは通常「要素(要素名)」のことを指す(分かりやすい解説はこちら)。「pタグ(p要素)」、「divタグ(div要素)」ということはあっても、「altタグ」なんて言い方はしない。


dirは滅多に使わないので念のため調べてみたけど、要素としてのdirも、遠い昔には存在していたらしい。しかし今は非推奨要素なので使うべきではない(<DIR>?HTMLタグリファレンス)。

現在HTMLで使うdirは属性において使われているdirのことを指し、このdirはディレクトリ」ではない。directionalityのdirだ。(参照)

縦書きサイトやアラビア語など、文字の記述方向を制御する際に使う。

width, height

ウィドスと読む人も多いし日本じゃそれで通じるから気にすんな。ウィズやウィズスやウィスと読む人もいる。英語圏ではウィス(スは舌を噛む発音)とハイトでないと通じないので覚えておいて損はないはず。面倒なので幅と高さと言ったっていい。

i, p, q, u, em, HTML

全部普通にアルファベットで読め。 いちいち正式名称で読むな。これらを全部正式名称で読むやつに出会ったことはない。qをクォートと読んだら「<q>」ではなく「'」の方を思い浮かべる人の方が多くて誤解を招きかねないのでむしろ正式名称で読むべきではない。

別に読めなくても恥ずかしくはない。

大事なのはどうやってうまくコミュニケーションするかという問題であって、正しい読み方なんてのは些末なこと。「正しい」のを知っていても顧客が間違った読み方の方で覚えていたら、そっちに合わせた方がスムーズに話が進むし角が立たない。恥ずかしいのは「間違った読み方」をすることではなく、「通じない話し方」の方ではないだろうか。

そもそも多くのウェブデザイナー・コーダーは正しい読み方なんてちゃんと習わずにやってきた。大事なのは正しく使うことであって正しく読むことではない。

2016-07-06

Windows游ゴシックがかすれる問題対策

少し前に話題になったWindowsの游ゴシック、游明朝が汚い(かすれる)という問題について、表示をまともにするための方法を検討することにしました。

これまでの経緯

Windowsで游ゴシックが汚いのは、どう考えてもWebデザイナーが悪い? | Cherry Pie Web

Windows で游ゴシックが細字になってしまう件は誰が悪いのかについて CSS 仕様から考えてみる | WWW WATCH

Re : Windowsで游ゴシックが汚いのは、どう考えてもWebデザイナーが悪い! - to-R

表示検証

環境

今回は游ゴシック体のみで確認。

OSWindows10

font-family: "游ゴシック", "Yu Gothic", YuGothic, "ヒラギノ角ゴ Pro W3", "Hiragino Kaku Gothic Pro", "MS Pゴシック", "MS PGothic", sans-serif;

font-size: 16px;

結果

ブラウザは左からchrome, Firefox, Edge, IE11

※コメントからの指摘で気づきましたが、以下のスクリーンショットではchromeの欧文書体が游ゴシック以外のものになってます。指摘後、"游ゴシック"のみの指定して、また元に戻したら欧文フォントも游ゴシックになったので何でこんなことになったのかさっぱり分かりません。スクリーンショット撮り直すのも面倒なんでこのままにしときます。

1.特に何も指定しない場合

f:id:k3akinori:20160706181734p:image

2.font-weight: 500; を適用した場合

f:id:k3akinori:20160706181735p:image

chromeの表示がましになる一方、他のブラウザのフォントも濃くなりました。

3.font-weight: normal; color: #000; text-shadow: 0px 0px 0px #000; を指定した場合

f:id:k3akinori:20160706181736p:image

chromeは細さそのままで色が濃くなり、Firefoxはfont-weight: 500;とほぼ変わらず。Edge, IE11ではジャギーが発生して汚くなりました。(Wの斜め線で顕著にみられます)

4.font-weight: normal; color: #333; text-shadow: 0px 0px 0px #666; を指定。IEのジャギーがごまかせないか試してみました。

f:id:k3akinori:20160706181737p:image

成果はあまり芳しくありません。

結論

今回の問題は、Windowsの問題という面もありますが、それ以上にChromeのレンダリングが下手くそという面も大きいのではないかと思います。Chromeがノーマルで游ゴシックLightを使う問題(バグ?)ということかと思います。(コメントを受け修正)

text-shadowで濃くするのも一定の効果はありますが、今度はIEがshadowのレンダリングが苦手、ということが分かりました。

すべての条件下できれいに描画したのはFirefoxで、さすが、Mosaicの系譜といったところでしょうか。

追記:現時点の対策法

問題がWindows chromeに限定されていて、それはfont-weight: 500;で解消されることまでは間違いないので、JavaScriptを使ってUAを判別し、chrome専用のCSSを読み込ませて解決することにしました。

<head>内に以下を記述

<script>
 var ua = window.navigator.userAgent.toLowerCase();
 if (ua.indexOf("chrome") != -1){
    document.write('<link rel="stylesheet" type="text/css" href="chrome.css" />');
 }
</script>

chrome.cssに以下を記述

html {
	font-weight: 500;
}

2016-07-02

主要なCSSプロパティを5つ紹介するよ!

ここ数日なんか流行っているので悪乗りしてしまおうという魂胆。

主要なプログラミング言語 5種類を徹底解説! - Programming share

主要なプログラミング言語8種をざっくり解説 - shi3zの長文日記

主要でもないプログラミング言語200種を一行で解説 - Qiita

文系のおっさんが主要なプログラミング言語8種をざっくり解説 - だるろぐ

てかプログラミング言語って200以上もあるんだ……

プログラミング言語はよく知らないのでCSSでいってみよー!

max-width

レスポンシブデザインが主流になってからものすごく出番が増えたプロパティ。

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

ってやると、元画像サイズよりもウィンドウ幅が小さくなったら自動的に縮んでくれます。

たまにレスポンシブ対応を謳っているのにwidth:100%;だけでサイズ指定していて、大画面だと画像が引き延ばされてボヤァ〜ってなっちゃう残念なテンプレートがあったりして悲しくなることもありますね。

display

あらゆる要素の特性を変えてくれたり存在そのものを消去してしまう魔法のプロパティ。

使う値はblock, inline-block, table, table-cell, none, flex が多いですね。

たとえば

a {
 display: block;
 width: 100%;
 height: 100%;
}

って指定すると親要素全体がクリック可能なリンクボタンに化けてくれます。スマートフォンでタップしやすいリンクボタンを作るのに大変重宝します。

また、

td {
 display: block;
}

なんてやると、テーブルを崩して横に並んでいるセルを縦並びにしてしまうことができます。パソコンモニタのサイズでは普通の表を、スマートフォンでは縦に並べたい、なんてときに使えますね。

table-cellはtableと組み合わせて、横並びのナビゲーションメニューや文字の上下左右の中央揃えに活用することが多いですね。

さらに、要素ごとなかったことにしたい場合は、display: none; を使うことがあります。

こいつはなかなか凶悪な魔法でして、コードには残って見えるけど、ブラウザ検索エンジン、スクリーンリーダーなどは完全に無視するようになります。display:none; 内にあるJavaScriptも動かなくなります。

ハンバーガーメニューやタブなど、普段は隠していてクリックしたら表示する、という動作をさせたいときに display: none; を使うのは避けましょう。

デフォルトで非表示のコンテンツは無いものと認識され、インデックスされない恐れがあります。またスクリーンリーダーユーザーにとっては最悪UXになりますので、まともなCSSコーダーは本当に限られた場所でしか使いません。

規約に書いてないのに勝手に広告を挿入されてせっかくのデザインを壊される、なんて場合につかうとよいと思います。

最近はflexが注目株となっています。関連プロパティと値と挙動を覚えるのが大変ですが頑張りましょう。

margin

グリッドレイアウトを作る際、これがないといろいろ大変なことになります。何が?って人は、bootstrapのrowに当てられているCSSを読んでください。幅をちょっと広めにして、そのちょっと広めた分をネガティブマージンでずらすだけで、グリッドを幅ぴったりに合わせてくれるんですよ! 最高じゃないですか。

float

いくらdisplay: flex; が有用だからと言ってfloatの出番がなくなるわけではありません。用途が違う用途が。

画像にfloat: left; とか適用する場合、親要素がその画像の高さを無視してしまうためデザインが崩れることがあります。親要素にはclearfixを適用することを忘れずに。

box-sizing

border-box最高です。デザインが堅牢になります。あまりに使い勝手が良いのでユニバーサルポインタにborder-box適用したりしてます。

position

かけだしCSSコーダーが恐れる超強力魔法の一つ。うっかり使うとすさまじい勢いでサイトデザインが崩壊します。そして「absoluteこわいabsoluteこわい…」とうわごとを繰り返すほどのダメージ受けてしまいます。

とはいえ関連ルールさえちゃんと把握しておけばデザインの自由度を大きく広げてくれるプロパティです。少し頑張ればレスポンシブのクリッカブルマップだって作れます。

overflow

ハンバーガーメニューを実装する際、親要素に hidden の値を設定しておき、デフォルトではメニューの要素を親要素の外に出しておくと、メニューの出し入れを制御することができます。隠し要素扱いされないようにマウスオーバーやフォーカスで表示するとよいかと思います。ただ、hoverで制御するとiOSSafariで動いてくれないことがあるので、今のところJavaScriptで制御することが多いです。新しいOSでは解消されてるんでしょうか。

そんなこんなで

主要なというか、自分がよく使うプロパティでした。レスポンシブデザインが主流になってからこれらを使う機会が増えてる気がします。

2016-06-19

CSSのネーミングでもう悩まない! BEM+OOCSSのネーミングルール

BEMの利点と落とし穴

BEMは使用箇所が明確で、何に使っているのかがすぐ分かって、関連するほかのクラスもすぐに見つけられて、そのため保守性が高い。

見た目は確かに醜いけれど、それ以上に利点が大きい。使わない手はない。


とはいえ、それなりに経験を積まないとちゃんとしたネーミングができない問題がある。

よくある間違いが、HTMLの構造の通りにCSSにネーミングしてしまうこと。そこまでいかなくても、ネストが深くなりやすい。

Sassなどを使っていればコードを書く負荷は下がるけど、出力されるCSSは肥大化するし、CSSの可読性が大幅に下がる。HTMLもクラス名のせいで読みにくくなる。一回これをやらかした。


本当にこれでいいのか?


よくないに決まっている。そこで一旦BEMから離れた。しかしこれが強力な手法であることに間違いはない。

なぜ正しくないアプローチをしてしまったのか?

BEMは、Block, Element, Modifierの順で名づけを行う。デザインをモジュールで把握して、「Block__Element--Modifier」の順で名前を付ける。

日本語で書くなら、「箱__箱--装飾・状態」である。

さらにBlock用のModifierとElement用のModifierを作ることができてそれらを1つの要素に詰め込むことができる。


これだけでも結構ややこしくなる。

BlockとElementをどこで判別するのか。これはElementだけれども、見方によってはBlockになる、どうすればいい?

また、ウェブページはBlockの入れ子構造になっている。関係性を明確にするのであれば、どのBlockまでさかのぼってネーミングすべきだろうか?


もう一つ。BEMではBlock, Element, Modifierのそれぞれで、ハイフンやアンダースコアを使って単語をいくつも結合できるようになっている。

制限がないので、詳しく書ける。そうすればあとから読む人がすぐに意味を把握できる。もとよりBEMはそこを重視している。

ここに落とし穴があった。


自由度が高すぎるのだ。多すぎる選択肢で悩む。

また、長く、複雑すると名前の重複を避けることができる。利点である一方、同じスタイルを別の名前で再生産するリスクも増える。ページの追加が多いサイトなら、条件次第ではCSSが膨大になる。

これではいけない。何か制限するものが必要である。より良い方法を見つけるための他のCSS設計を調べることにした。

OOCSS、SMACSS、FLOCSS…

プログラミングになじみがないため、オブジェクト指向やプロジェクト、クラスといった用語に戸惑ったが、サイトの構造やモジュールの性質を分類・理解するための助けになった。


ネーミングについては、レイアウトにはl-接頭辞を、モジュールにはm-接頭辞を、などというのはあるのだけど(SMACCS)、微妙に両方の性質を持っているモジュールがあったりして、こちらはむしろ悩みが増えることに。

救世主はBootstrap

今まで使わない機能が9割だったので、グリッドシステムやセマンティックなネーミングを取り入れるだけだったのだけどこれが「これならいけるんじゃね?」という答えをくれた。

col-sm-6

グリッドの列分割で、スモールサイズ以上の画面幅では、6グリッド。


「…なんかこれ、BEMっぽくね?」


なんというか、旅をして帰ってきたら青い鳥がそこにいました的な。

「機能」−「適用場所」−「詳細」

なんかこれがすべてのモジュールに適用できそうな気がした。レスポンシブデザインに最適じゃないか。

実際に検討してみたらそう簡単でもなかったのだけど、以下のように整理することができた。

「役割」−「使用場所または担当範囲」−「詳細」

これを適用すると、

col-sm-6
gnav-item
btn-card-submit

てな形になる。


自由度をなくすために、単語はハイフン一つで結合し、アンダースコアやキャメルケースは禁止。これで名前が冗長にならないようにできる。(ハイフン一つの縛りはWordPressコーディング基準と互換性を持たせるためでもある)


上記の命名ルールを英単語に置き換えると、

Role-Position-Detail

となる。頭文字を拾うとRPD。ほかの設計概念より無味乾燥な感じだけど、強引に「ラピッド」と呼ぶことにした。「RPD-CSSNamig」さっさと決めようクラス名。

さらにOOCSSの概念を導入

実はこれだけではネーミングはできても、サイトは構築できない。

Detailのところに装飾を担わせると、単語数が不足するのである。装飾のバリエーションは広いので1単語では足りない。


とはいえ、ネーミングの問題を検討していた当初から機能と装飾は完全に分離した方がよいと考えていた。

そもそもこの「ネーミングどうすべ?」問題、CSSフレームワークを自作するときに生じたもの。--Modifierでわずかに違うだけの同じスタイルを繰り返し使うと、CSSファイルが肥大化する。Sassを使えば管理は楽だが、Sassを使っていないコーダーがいる場合、編集されるのはCSSの方になる。そうすると同じスタイルが繰り返し出てくると保守性が下がる。

そのためこのフレームワークは主に構造あるいは機能に絞り、装飾は最小限にとどめるようにしていた。スタイルを上書きではなく追記することで、多くのサイトに使いまわせるようにという魂胆である。


当初はフレームワークのクラスに追記すればいいかな?と思っていたが、OOCSSのおかげで装飾専用のクラスを作る方が合理的だと考えなおした。

装飾専用のクラスを作り、モジュールとセットで運用する。


これを「従属セレクタ」と呼ぶことにした。単体ではスタイルを持たず、他のモジュールと組み合わせた時に、その装飾部分のスタイルを担当させるのである。

これなら、HTMLとCSSのどちら側でも装飾の修正や追記を簡単に行える。

また、従属セレクタの名前は、他のモジュールにも使いまわすことができる。


従属セレクタは運用が特殊になるため、他のモジュールとは明確に区別する必要がある。そこで従属セレクタにはdep-(depend)という接頭辞を付けることにした。

モジュールとセットで運用する場面があるのはJavaScriptのセレクタも同様である。そこでこれも従属セレクタとし、接頭辞js-を付けることにした。IDセレクタを使う場合はjs-は要らない。


いずれも接頭辞のあとはRPDのルールを適用する。(とはいえほとんどの場合、役割名だけで済むだろう)

Baseの概念も入れておく

ここまで検討してきたのはすべて何らかの機能を持ったモジュールに関するものになる。

実際にはHTML要素のリセットや、mt-10(margin-top:10px;)などのような微調整用のセレクタも必要になる。FLOCSSでいえばFoundationやUtilityにあたる。

大概1単語で片が付くし、ネーミングは大概決まっているためここまでの検討対象に入れていなかった。

全ページ共通で使いまわすため、これらをBaseとして分類することにした。

おおむね出来上がったので

GitHubにまとめておいた。

ネーミングに使える単語数が制限されているので、モジュールは小さいものから大きいものへとやっていくのがコツではないかと思う。親モジュールに振り回されないため、再利用性は上がるはず。

RPD-CSSNaming

一応、このアイデアはHTML/CSSコーダーにとってはとっつきやすいのではないかと思う。覚える・理解することも少なめで意思統一コストは低いのではないかと。

ただ、BEMの持つ親Blockとの強力なつながりが、RPDでは見えなくなるという欠点がある。モジュールは構造のみを担い、他のBlockでも使える(そのBlock独特の装飾部分は従属セレクタが担うはずである)ので大きな問題ではないと思うが、これはどういうプロパティを従属セレクタに任せるかの判断が重要になってくる。下手に組むと使いにくくなるだろう。


RPD-CSSNamingのアイデアは、プロジェクトによっていろいろカスタマイズできると思う。小規模なサイトであれば装飾セレクタを使わずBEM的なつくりの方が効率的に組めるのではないかと思うし、関わる人が多くて大規模になるのならSMACSSやFLOCSSのルールの方に寄せていった方が管理しやすいと思う。

これでCSSのネーミングに悩む人が減ったらよいなと思う。

2016-06-14

コンポーネント化CSSは簡単ではない

これからのWebデザインは、コンポーネント化を意識しよう | Webクリエイターボックス

上のリンク先で言われていることは大体みんなやってきたことなんじゃないかと思います。一人でやる案件なら別に意識するまでもなくやれるでしょうが、複数名でやると簡単に泥沼になるのがWeb制作の現場なので、単にコンポーネント化といってもどこに気を付けてやるべきかを熟考しなければなりません。

コンポーネント化の範囲をどうするか

今私がやっているのは「機能単位」でのコンポーネント化です。ただ、これが最適解かどうかは結論が出ていません。たぶん、これが最善と思ってはいますが。

コンポーネント化の単位として考えられるのは以下のパターンです。

  1. レイアウト単位
  2. 機能単位
  3. 装飾単位
レイアウト単位のコンポーネント

代表的なものはグリッドレイアウトです。12グリッド、n/mグリッドが主なパターンになるでしょう。12グリッドはカラム分割や複数枚の画像+記事の回り込みなどといったレイアウトには最適ですが、ヘッダーに横並びの等幅分割でグローバルメニューを設置するような場合はあまり向いていません。

機能単位のコンポーネント

横並びグローバルメニューや、カードモジュールのようなあらかじめ決まった形でそこにしか使わないようなものはまとめてしまう。

装飾単位のコンポーネント

色違いのボタンなど

コンポーネント化の落とし穴

全部入りの欠点

上記の3種のコンポーネントは、Bootstrapなどの大規模CSSフレームワークでは最初から入っています。Bootstrapのようなものを自分で作ろうとすると痛感しますが、非常に考え抜かれたコンポーネントであることが分かります。

なら黙って有名どころのフレームワークを使えばいいじゃん、となるのですが、そういうわけにもいかないのがWeb屋のジレンマです。(私もBootstrapは一度だけ試しに使いましたが、以降は自前でグリッドを用意するようになりました)

全部入りの欠点は、CSSファイルの肥大化が挙げられます。Bootstrapの機能の8割は使わない、という人も多いのではないでしょうか。「パフォーマンス」の御旗のもとにCSSやJavaScriptファイルのミニファイなどという涙ぐましい努力を推奨される一方で、こんな無駄が許されるのか、という問題はついて回ります。

レイアウトのみのコンポーネントは無駄がない

一方、グリッドシステムだけが用意されているような場合は、無駄がありませんが、制作時に作らなければならないものが多く、スピードが損なわれます。

レイアウト+機能は比較的バランスが良い

装飾にかかわるプロパティが最小限にとどめられている機能別コンポーネントではレイアウトのみの場合よりも制作スピードは上がります。ただし、その機能で使われる装飾が決まっている場合は、装飾までコンポーネントに入れるのが最適だと思います。機能と装飾を完全に分離してしまうと、セレクタの重複が増え、CSSが肥大化するからです。もっとも、装飾の変更が多い場合は完全分離のほうが管理しやすくなると思います。

装飾単位のみでコンポーネント化するのは避けるべき

スタイルガイドもがっちり作られ、コンポーネント化もされているにも関わらず、レイアウト・機能・装飾の分離がなされていないがためにコンポーネントの無駄な肥大化、同じレイアウトに複数のコンポーネントが割り当てられ、スタイルガイドも追記が頻発、という場面に出会ったことがあります。

主な要因は、レイアウトと機能と装飾を全部同じコンポーネントにまとめようとしていたこと。下線を付けるかつけないかだけでコンポーネントごと新たなセレクタに複製してしまうようでは効率的とは言えません。この辺はCSS設計者の腕の見せ所だと思います。

バランスをどこで見極めるか、が大事

CSSのモジュール化を進めると、必ずどこかで無駄と不足が発生します。不足をなくせばCSSは肥大化し、CSSの無駄と不足を最小にしようとするとクラスが細分化され、今度はHTML側の負担が増えます。これではHTML3の時代と同じじゃないか、ということになりかねません。

上流のCSS設計がまずいとこういう大変なことになるのですが、CSS設計の勘所というのは場数を踏む(そしてあとでまずかったところを把握する)必要があります。

のんびり場数を踏む余裕がない場合は以下の方法が効率的です。

Bootstrapなどのコードを読む

セマンティックな名付け、コーディングテクニックなどを学ぶことができます。フレームワークは大手のウェブサービス会社が公開しているので、いくつか目を通しておくと、いろいろな設計思想が学べて効果的です。特にBootstrapFoundationPureは勉強になります。

BEMを使ってみる

名づけのルールがBase, Element, Modifierとなっており、上記のコンポーネント化の目安となります。

最初のうちは深くしすぎるなどの失敗をするので練習用のサイトを用意して何回か試行錯誤すると勘所がわかるようになります。

BEMのルール上は__,--を何段にしてもよいみたいですが、3段くらいを限度にするとちょうど良いかなー、という印象です。

そして、導入する、ではなく使ってみる、というのがポイント。一度「このあたりがコンポーネントの境界だな」というのがわかれば、名づけをBEM方式にこだわる必要はありません。

Sassはほぼ必須かも

パフォーマンスをよくするためにはCSSファイルは1つにまとめたい。しかしファイルが大きくなると必要となるセレクタがどこにあるのか探すのに苦労する。またコンポーネント化をする上では土台となるCSSは触りたくない、といった面倒を解消してくれるのがSass。よくバグるけどKoalaを使えばコマンドラインを触ることもなく、CSSとほとんど変わらない感覚で編集・デバッグを行えるのでまだの人はすぐにでも導入すべきでしょう。

自分でCSSフレームワークを作ってみる

これをやると「案件ごとに専用コンポーネント作ったほうが楽じゃね?」ってことに気づきます。どの案件でも使いまわせるのはグリッドシステムくらいのものじゃないかと。

この点大規模フレームワークはすごいなと思います。

まとめ

  • コンポーネント化は目的・役割を固めたうえで、ちょうどよいバランスのところを考える必要がある。
  • 有名どころのCSSフレームワークやBEMは、たとえ使わなくても読んでおくほうがいい。設計思想を学ぶことができる。
  • 一度自分でフレームワークを作ってみると良いと思う。