1. 8845musign

    Posted

    8845musign
Changes in title
+HTML/CSS/JavaScript覚書 1
Changes in tags
Changes in body
Source | HTML | Preview
@@ -0,0 +1,243 @@
+
+ある案件の振り返りです。
+
+## レスポンシブ関連
+
+### 小さなものから大きなものへ
+
+モバイルからPCへ、という順序でメディタクエリの設計を行う。
+その方が記述量が減る。
+
+PCへのスタイル変更が最低限のプロパティ追加で済む。
+
+
+逆の順序で設計を行った場合、PCのスタイルを大量に打ち消しした上でモバイル向けのスタイルを記述しなければならない。
+
+```css
+
+/*
+ * 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/Lquidにするか
+
+画面幅に対して柔軟にレイアウトを行うのがレスポンシブデザインの特徴だが、どこまでに柔軟にするかはプロジェクトによってばらつきがある。
+例えば僕が見た中では下のようなパターンがあった。
+
+1. 各要素の横縦は固定値、pxでマージンやパディングをとりつつ要素自体は%
+2. 各要素の横幅のみ%指定でマージンやパディングをとり、要素自体は%、縦のレイアウトについてはpxの固定指定
+3. 縦横全てが%
+
+3までいくとやりすぎかとは思うが、要求される柔軟性はプロジェクトによって違ってくるので、最初に共通認識を作っておきたい。
+
+### ドキュメントタイプ
+
+HTML5のものを使う。レスポンシブを選択した時点でHTML5必須。
+
+```html
+
+<!DOCTYPE html>
+<HTML>
+<HEAD>
+...
+
+```
+
+### UIコンポーネントの重複
+
+UIコンポーネントの重複はなるべく避ける、例えばPC/SPでメニューを二つ用意するなど。実装の複雑さとトレードオフになるが、重複したコンポーネントを持つことで、修正対応で漏れが発生しやすくなる。
+
+またあらゆるものを重複してコーディングすれば、もはやレスポンシブではなくなってしまう。(1ページにPCとSPのコードをそのまま混在させる結果となる)
+
+やるとしたら、テンプレートエンジンなど使ってコンテンツとUIの構築を分離して欲しい。修正時/更新時に事故る
+
+### JavaScriptでのレスポンシブ
+* matchMedia()を使う
+
+jsでHTML/CSSと同じmediaQueryをつかうことができる。
+windowのwidthなどを取得して適当に判別に描画ポイントの判別に使うとスクロールバーの有無なんかで死ぬ。スクロールのありなしで取得できる画面サイズが変わるため、HTML/CSSの切り替えポイントと若干違いがでる危険性がある。
+IE9やAndroid 2.Xなどは対応していないため、pollyfillを使うと良い。
+
+[matchMedia.js](https://github.com/paulirish/matchMedia.js/)
+
+IE8・・・?
+
+## ユーザによるズーム操作
+* 禁止しない
+アクセシビリティを考えると、ユーザのズーム操作を禁止することはアンチパターン。
+
+```html
+<!--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ではこの限りではない
+
+```css
+/*
+ * マージン
+ */
+.m10 {
+ margin:10px !important;
+}
+
+.m20 {
+ margin:20px !important;
+}
+
+```
+
+### 辞書
+
+命名に使える単語辞書が欲しい、欲しいー
+
+__探してみた__
+
+* [HTMLとCSSクラスでよく使う命名について]
+(http://qiita.com/pugiemonn/items/eaa597b79fe59a1f1506)
+* [もう、class名やid名で悩まないんだからっ!!](http://css-happylife.com/archives/2007/0115_1345.php)
+
+### UIモジュールの共通化
+
+1. サイト全体
+2. カテゴリ全体(hoge.com/category/以下共通)
+3. ページ内
+
+1.は考えるが、2.については見落としがち、ページ量産でテキトーにCSSをコピペすると後で __地獄を見る(というか見た)__
+
+コードを書く前に先にPSDを見ようー
+
+### フレームワークやJSのCSSの上書き
+
+直接弄らないで上書きして欲しい。
+
+例えば、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](http://www.dirtymarkup.com/)とかで綺麗に整形する。
+自分が作ったファイルでなくとも綺麗にする。あとに編集する人のことを考える。
+
+### ファイル名
+
+```index.html```に対して```top.js```など若干おしいファイル命名をしない。
+
+```index.html```には```index.js```とする。
+
+### コメントアウト
+
+コメントアウトしたコードは大抵の場合復活することは少ない。また、別の作業者が説明なきコメントアウトを見て意図を汲み取ることは難しい。結果として、プロジェクトが進むにつれコメントが散逸していき、取り除いて良いかどうかの判断がもはやつかなくなる。
+
+バージョン管理してあるのであれば、コミットコメントに理由を明記して、思い切って削除すれば良い。
+
+