LoginSignup
20
22

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

@8845musign(hiroki yokouchi)

HTML/CSS/JavaScript覚書 1

Last updated at Posted at 2015-05-06

案件の振り返りです。

レスポンシブ関連

小さなものから大きなものへ

モバイルからPCへ、という順序でメディアクエリの設計を行う。その方が記述量が減る。

PCへのスタイル変更が最低限のプロパティ追加で済む。

逆の順序で設計を行った場合、PCのスタイルを大量に打ち消しした上でモバイル向けのスタイルを記述しなければならない。


/*
 * Good
 */
.box {
  /* ... */
}

@media screen and (min-width: 768px) {
  .box {
    width: 50%;
    float: left;
  }
}

/*
 * Bad
 */
.box {
  width: 50%;
  float: left;
  /* ... */
}

@media screen and (max-width: 768px) {
  .box {
    width: 100%;
    float: none;
  }
}

ただし、後者の設計も

  • IE8以下は固定レイアウト

といった要件があった場合、意識せずとも要件を満たせるため、ケースバイケースである。
注.IE8以下では@media内のスタイルは無視されるため、PC向けのスタイルのみ有効になる。

どこまでFluid/Liquidにするか

画面幅に対して柔軟にレイアウトを行うのがレスポンシブデザインの特徴だが、どこまでに柔軟にするかはプロジェクトによってばらつきがある。
例えば僕が見た中では下のようなパターンがあった。

  1. 各要素の横縦は固定値、pxでマージンやパディングをとりつつ要素自体は%
  2. 各要素の横幅のみ%指定でマージンやパディングをとり、要素自体は%、縦のレイアウトについてはpxの固定指定
  3. 縦横全てが%

3までいくとやりすぎかとは思うが、要求される柔軟性はプロジェクトによって違ってくるので、最初に共通認識を作っておきたい。

ドキュメントタイプ

HTML5のものを使う。レスポンシブを選択した時点でHTML5必須。


<!DOCTYPE html>
<HTML>
<HEAD>
...

UIコンポーネントの重複

UIコンポーネントの重複はなるべく避ける、例えばPC/SPでメニューを二つ用意するなど。実装の複雑さとトレードオフになるが、重複したコンポーネントを持つことで、修正対応で漏れが発生しやすくなる。

また、あらゆるものを重複してコーディングすれば、もはやレスポンシブではなくなってしまう。（１ページにPCとSPのコードをそのまま混在させる結果となる）

やるとしたら、テンプレートエンジンなど使ってコンテンツとUIの構築を分離して欲しい。修正時/更新時に事故る

JavaScriptでのレスポンシブ

  • matchMedia()を使う

jsでHTML/CSSと同じmediaQueryをつかうことができる。
windowのwidthなどを取得して適当に判別に描画ポイントの判別に使うとスクロールバーの有無などで問題が発生する。スクロールのありなしで取得できる画面サイズが変わるため、HTML/CSSの切り替えポイントと若干違いがでる危険性がある。
IE9やAndroid 2.Xなどは対応していないため、pollyfillを使うと良い。

matchMedia.js

IE8・・・？

ユーザによるズーム操作

  • 禁止しない
    アクセシビリティを考えると、ユーザのズーム操作を禁止することはアンチパターン。
<!--Good-->
<meta name="viewport" content="width=device-width, initial-scale=1">

<!--Bad-->
<meta name="viewport" content="width=device-width, minimum-scale=1, maximum-scale=1, user-scalable=no, initial-scale=1"/>

CSS

命名ルール

.btn01や.nav02といった命名は避ける。名前が意味を表していない。
例えばページやカテゴリなどを使った命名.topNavといったものはそのクラスのスコープ（どこで使われるのか、）どういったコンポーネントを構築するのに使うのかが明白になる。

ユーティリティ系のCSSではこの限りではない

/*
 * マージン
 */
.m10 {
  margin:10px !important;
}

.m20 {
  margin:20px !important;
}

辞書

命名に使える単語辞書が欲しい、欲しいです…

探してみた

UIモジュールの共通化

  1. サイト全体
  2. カテゴリ全体(hoge.com/category/以下共通)
  3. ページ内

1.は考えるが、2.については見落としがち、ページ量産でテキトーにCSSをコピペすると後で 地獄を見る(というか見た)

コードを書く前に先ず、複数画面にわたってPSDを眺める

フレームワークやjQueryのプラグインに同梱されているCSSの上書き

直接弄らないで、別途用意したスタイルや変更したい箇所と同じセレクタを定義して上書きして欲しい。

例えば、Bootstrapはたまにアップデートされてバグが直っている。アップデートされたbootstrap.cssを直接編集したbootstrap.cssに上書きすると壊れる。

jQuery(JavaScript)

気軽にコピペしない

  • コピペしない

あるa.htmlに書いてある処理が他のページ共通で使えると考えない。ちゃんとどういった処理があり、コピー先のページに必要なものはどれかを考える。

JS書く人はそのコードがなんなのかコメントちゃんと書く

コメントは必ず書く、そして読む

気軽にcommon.jsしない

なんでもかんでもcommon.jsに入れない、理由は上と同じ。

「このcommon.js（エラーでまくり）、政治的な理由で外せません…」

で何度も泣いた。

common.js
$("#hoge_page_onlyId").なんちゃらメソッド();

などの、固有のページにのみ適応される処理を入れ込まない。こういった処理が原因でバグが生まれるケースもある。
本当に共通化されたヘッダーメニューの処理なんか以外は避けたほうがよいと個人的には思う。

ここら辺はチームでちゃんと話して進めて欲しい。

プラグイン/ライブラリの1ファイル化

プラグインやライブラリはlib.jsとかにまとめて欲しい。minifyしているやつを一つのjsにまとめて読み込む。

lib.js
/**
 * hogeプラグイン
 * MIT license ...なんちゃら
 */
!($function(){})(...);

/**
 * higeプラグイン
 * MIT license ...なんちゃら
 */
!($function(){})(...);

この際ライセンスも必ず元のファイルから転記する。

lib.jsのファイルサイズは増えるが、キャッシュが効くのでページは軽くなる。

minify

jquery.jsではなくjquery.min.jsみたいなやつ
スペースや改行を削ってファイルサイズを小さくしたもの

プラグイン探し

案件ごとに探し直すのは面倒なのでこれというプラグインを探したい。
また、更新が行われていない/要件に合わないプラグインもでてくるので定期的にナレッジを更新していく。

全体

インデント等が

汚くなったらDirty Markupとかで綺麗に整形する。
自分が作ったファイルでなくとも綺麗にする。あとに編集する人のことを考える。

ファイル名

index.htmlに対してtop.jsなど若干おしいファイル命名をやらない
index.htmlにはindex.jsとする。

コメントアウト

コメントアウトしたコードは大抵の場合復活することは少ない。また、別の作業者が説明なきコメントアウトを見て意図を汲み取ることは難しい。結果として、プロジェクトが進むにつれコメントが散逸していき、取り除いて良いかどうかの判断がもはやつかなくなる。

バージョン管理してあるのであれば、コミットコメントに理由を明記して、思い切って削除すれば良い。

20
22
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
20
22

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?