セレクタの詳細度の概要と(とデバッガ?)の話

はじめに

株式会社イメージ・マジックの技術ブログ、今週の担当のsoenoです。

オフィスが移転し二週間がたちました。

文京区は神田に比べて子供の姿をよく見ます。

少なくとも神田でベビーカーを見た記憶がないのでしみじみと地区による差を感じています。(さすがに記憶にないだけですれ違ったりはしていたのだと思いますが。)

さて、今回はcssのセレクタの詳細度の概要(とデバッガ?)について書きます。

CSSが反映されないとき。

cssを触りだすと、反映してほしい指定が来ないことがあります。

(赤くなってほしいところが赤くならない等々。)

大体そういう時は

・その指定を反映させるための条件が足りていない。

・よその指定が反映したい指定を打ち消している。

あたりだったりします。

そんなときはCSSがimportantまみれになる前に要素の指定の方法を見直していきます。

状況の確認方法(chrome ディベロッパーツール)

選択中の要素にどんな指定がされているかは下記の手順で確認できます。

・調べたい要素を右クリック。
・出てきたメニューから検証を選択。
・ディベロッパーツールが要素を指定した状態で開きます。
(選択中の要素はelements内をクリックするなどで変更可能。)
・右のエリアのstyleの項目に表示されているのがその要素についているcssです。

※手順の記載の都合でchromeで書きましたが大体のブラウザで同様のことができます。

ディベロッパーツールで要素を選択しているのにかけたはずの指定が見つからないときはcssのリンクや指定で間違いがあるかもしれません。スペルの間違いや、ファイルのパス等そのほかの部分が違う可能性の方が高そうです。

指定した項目に打消し線(文字にかぶさる横線)が入っていて反映されないという場合。おそらく詳細度で何とかできる問題です。

重複した指定と詳細度の関係

cssではそれぞれ数値が割り振られており、それを合算した結果でcssで使われる指定が決まります。

割り振られている値を詳細度と呼びます。

ですので設定したい項目が何かに打ち消されている場合は打ち消している項目よりも反映させたい項目が詳細度が高くなるように指定すれば解決します。

厳密な指定がいる場合は詳細度の数値、計算方法について調べてみてください。

計算するサイトや、詳しいサイトありますのでいろいろ見てみるのがいいと思います。

また、厳密な計算が必要なほど込み入っているのであればスコープや設計を見直たほうが早いかもしれません。

要素の詳細度について

さて、以下詳細度が高い順に記述すると

1.important

記述例

css

.btn-red{
  background:red !important;
}

2.htmlのタグに直接書かれるスタイル

記述例

html

<div style="background:red"></div>;

3.idにあてられたスタイル

記述例

html

<div id="red-btn"></div>;

css

#red-btn{
   background:red !important;
}

4.クラスへあてられたスタイル

記述例

html

<div class="red-btn"></div>;

css

.red-btn{
  background:red !important;
}

5.その他

疑似要素などありますがこの辺りの衝突はあまり見ないのと、大体他のクラスにつけて記述することが多いと思いますので省略します。

尚、同じ詳細度の指定が複数個所にあった場合は後に読み込まれる方が優先されます。

一応優先度の反映のされ方をざっくり書くと

優先度が高いものが反映されますので、importantが赤といえば他が何を言っても赤です。

importantがいないときはタグに書かれたスタイルが優先されます。

importantの指定もタグの指定もなければidの指定が優先されます。

そのすべてがいないときはclass、classさえいないときはその他疑似要素等への指定が使われます。

ここまで把握したら反映させたい項目を邪魔している指定を見てみます。

詳細度が反映させたい要素より高いはずです。

自身の詳細度を高める、相手方の詳細度が不必要に高いときは下げるなどして調整すれば正しく反映されます。

終わり

詳細度についていろいろ書きましたが、厳密に調整しないといけない状況はなかなか大変なので設計で何とかできるようになりたいです。

補足(Chromeディベロッパーツール)

ディベロッパーツールのstyleではスタイルの左に表示されるチェックボックスのオンオフでスタイルの着脱ができます。
衝突している指定についてブラウザ上で相手側の指定をオフにして試してみることができます。
同じスタイルの指定が複数個所にされていて反映されない場合はディベロッパーツールであらかじめみることができます。

inputのtypeが”file”の時の選択エリアの話

はじめに

株式会社イメージ・マジックの技術ブログ、今週の担当のsoenoです。

今朝の神田は雨でした。

技術が発達すると傘を差さずにぬれずに通勤なんてことも可能になるのでしょうか。

さて、今回は仕事中にはまったcssについてです。

というか、タイトル通り<input type=”file”>で指定したはずの選択エリアの話で、

指定したつもりのエリアと食い違うことがあるという話です。

前提

状況としては結構色々やらないと発生しないのでニッチな投稿となるのですが、

– <input type=”file”>を使用している。
– カスタマイズしている。<input>は非表示にして使用。
– ボタンエリアは結構狭め。

な感じで発生します。

挙動

ボタンの外を押してもイベントが発生する。

要素にボーダーを付けたりして調べてもそれらしきサイズの要素がない。

再現可能なコードはこんな感じ


//~略~
<style>
.uploadArea{
  position: relative;
  color: #fff;
  background: #2ab1e7;
  width: 30px;
  height: 30px;
}
.uploadBtn{
  position: relative;
  height: 100%;
  width: 100%;
  opacity: 0;
  cursor: pointer;
}
</style>

//~略~

<body>
 <div class="uploadArea">
  <label for="uploader">
   <input id="uploader" type="file" class="uploadBtn">
  </label>
 </div>
</body>

//~略~

解決法

opacityを1にしてみると何が起きているかすぐにわかります。

inputのタイプがfileの時はアップロード用のボタンがあるが、それがはみ出てしまうというのが今回の不具合の理由でした。

なので修正はuploadAreaのcssに overflow: hidden;を足すだけ。

わかってみるとショックなほど簡単なことなのですが、inputエリアのタイプがfileの時はボタンを持っている。というのを忘れていると、この範囲何?誰?みたいなことになります。

最初に疑ったのはz-indexだったり、opacity:0にした時点で見つけにくくなるわで、結構はまったので取り上げてみました。

開発サイドから見るバグ報告の話

こんにちは株式会社イメージ・マジックのsoenoです。

私はフロントエンド側でバグを受け取る側にいます。
いざバグが上がってくると手一杯になり伝えられない報告について。
もらうと助かる報告とその理由などについて書いてみようかと思います。

まず不具合の発生時に報告を上げる側は以下のような思いを抱いているのではないかと思います。
・壊れているので直してほしい。
・クレーム来てるから早く動いてほしい。
・細かいことはわからないけどとにかく何とかして。

急いでほしい、早く結論が知りたい。
そんなときほど初期に上がる報告が重要です。
開発側で報告を受けたとき、いろいろと調べるポイントがあります。
素敵な報告をいただくと調べなくてはいけない箇所が減ったり、
うっすらと見当がついたり、もしくは重点的に確認するべき場所を決定できます。

ではもらってうれしい報告を手軽に書く方法について考えてみます。
あってほしい情報や、必要な項目について抜けなく上げるために
作文などでなじみのある5w1hに照らし合わせて考えました。
5w: いつ、どこで、だれが、何を、どうした。
1h: どのように

報告時に書く5w1hを言うと以下のようになります。

・いつ(When)
内容:バグ発生時刻(特にサーバー周りのバグの時に重要)
理由:記録を確認するときに膨大な情報の中から探す場合、時刻がわからないと探しきれないことがあります。

・どこで(Where)
内容:ネットワーク接続環境など。社内で接続しているかそれとも社外か。遅い回線ではないか。
理由:ネット回線のスピードによる挙動の場合そのスピードでないと再現しないことがあります。
対処する場所、対処可能な部署が違うこともあり得ます。

・だれが(Who)
内容:バグ発生時の環境、ブラウザ、ブラウザバージョン、端末(pc?smartphone?)、OS(windows?mac?linux?…)
理由:特定のブラウザのみで発生する動きがあるので、そのブラウザしか再現しないことがあります。

・なにを(What)
内容:ウェブでいうとどのページの(url等)どの要素に対して操作を行っていたか
理由:ページとどの要素かがはっきりしていると違うページの違う要素を延々調べなくて済むようになります。

・なぜ(Why)
内容:そもそも何のためにその操作をしたか。
理由:操作の意図ですが、想定した操作外での不具合の把握でしょうか。
バグ取りというよりはサイト改修、改善時に知っておきたいところです。

・どのように(How)
内容:バグ発生のための手順
理由:手元の環境で再現するかどうかはとても重要です。壊れていないものを直すためには
どうしたら壊れるのか、どこが壊れるかもしれないのかなど、上の5W総出で類推することになります。
特徴的な動作や、何か心当たりやひらめきがないと難しいということもあります。

追加でもう一つ5w1hでは足りなかった要素として”hope”を足します。

(英語的に正しいかの検証はしません。)

・どうなってほしかったか(Hope)
内容:正しく動いていたらどうなるか
理由:バグと仕様との判断と、一見正しく動いているように見える挙動の際に何が問題になっているかを特定します。

何か特殊な状態があればそれも追記してあるとなおいいです。
例として思いつくものを上げると
・同一画面を複数ブラウザで開いていた。
・ブラウザで戻るボタンを押してのフォーム入力。
等々

この報告を私が読む場合、下に書いた順番になります。
0、特殊な操作、状態の報告
1、どのように(How)
2、どうなってほしかったか(Hope)
3、なにを(What)
4、だれが(Who)
5、いつ(When)
6、どこで(Where)

順番は個人の手法、サーバー担当かフロント担当かで違ってくると思います。
特に抜けて困るのは1、2、3番。
サーバー側は加えて5番。(多分)

早く回答してほしい、今すぐ着手してほしい。
そういうときほど初期の報告が大切です。
そんなこと言ってもちゃんと書いても遅いじゃん。
という意見もあるかと思います。
ですが、ちゃんと書いていなければきっともっと遅かったはず!
というわけでもらってうれしい報告について書きました。

最後に、こちらの記事は一個人としての意見ですのでご注意ください。
フロント周りやってますのでサーバーあたりに抜けがあるのではないかと思います。
開発にもいろいろあります。自分のケースによりあうものを参考にするといいと思います。
(web上に既にきれいに書かれているものもあります。)