Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

大規模サイトにおける本当は怖いCSSの話

102,671 views

Published on

WDF.Vol.8で話したCSSについてのスライドです。

HTMLの見た目を制御するCSS。
CSS3やsassなど技術的な話題を目にすることは多いですが
その運用方法について多くは語られていません。
大規模サイトを大人数で制作する状況でCSSはどうあるべきか。
DMM.comという巨大サイトの運用を通じて得た経験を話したいと思います。

  • Be the first to comment

大規模サイトにおける本当は怖いCSSの話

  1. 1. 本当は怖いCSSの話 大規模サイトにおける Makoto Inoue Talk of CSS fearful in fact
  2. 2. 井上 誠 三重県伊勢市出身 金沢美大工芸科卒業 DMM.com Labo勤務 入社8年目 デザイン部チーフ twitter: @in0in0 facebook: http://www.facebook.com/in0in0 Makoto Inoue Talk of CSS fearful in fact
  3. 3. CSSの何が怖いの? A thing with what dreadful of CSS?
  4. 4. 影響範囲が広い エラーを吐かない id,classがサイト中に分散する
  5. 5. 小規模だと問題は起こりにくい
  6. 6. 規模が大きくなるとトラブルが…
  7. 7. 確認する <p class=”btn check”> チェックボックス✓ <input type=”checkbox” class=”check”> 段落です p span{color:blue; margin:20px} <p class=”btn”> <span>ボタン</span></p> ボタン 定義済みのid,class名をつけた 要素の再定義で崩れた
  8. 8. ボタン check! ボタン check! ボタン check! hoge.html fuga.html moge.html ボタン check! hage.html ボタン ボタン ボタン .button{ ...} .bt{...} .botan{ ...} ボタン .btn{...} 影響範囲が大きく修正しづらい 無計画にコピペされている
  9. 9. 共通ボタン 例外ボタン共通ボタン デバイスの向きを変えられる ユーザはいつでも、さまざまな理由でiOSデバイスの向きを変えることができます。たとえば、実行 する操作が縦長の向きのほうが自然に感じられる場合もあれば、横長のほうがより多くの情報を表示 できると感じられる場合もあります。デバイスの向きを変える理由が何であれ、アプリケーションの 主要な機能が見やすいままであることをユーザは期待します。 ユーザはホーム(Home)画面からアプリケーションを起動することが多く、そのためすべてのアプリ ケーションが同じ向きで開始することを期待する傾向があります。iPhoneとiPadではホーム(Home)画 面の表示の仕方が異なるため、このような期待がアプリケーションに与える影響も異なります。 ● 直接操作 ユーザは、画面上のオブジェクトを、別のコントロールを通じてではなく直接操作すると、より深く 作業に関わることになり、アクションの結果をより簡単に理解できます。iOSユーザは、Multi-Touch インターフェイスのおかげで、直接操作の感覚をより高度に感じることができます。ジェスチャを使 用することで、ユーザはマウスなどの手段を用いることなく画面に表示されるオブジェクトにタッチ することができるため、それらオブジェクトに対してより強い親しみの感覚や制御している感覚を持 ちます。 たとえば、ズームのコントロールをタップする代わりに、ピンチのジェスチャを通じてコンテンツの 領域を直接拡大、または縮小することができます。ゲームでは、プレーヤーが画面上のオブジェクト を直接動かしたり、対話をしたりします。たとえば、ゲームによっては、回して開くダイヤル錠を表 示するものなどがあります。 iOSアプリケーションでは、以下の場合にユーザが直接操作を体験できます。 ● 画面上のオブジェクトに影響を与えるため、デバイスを回転させたり、動かしたりするとき ● ジェスチャを使用して画面上のオブジェクトを操作するとき ● 自身のアクションが目に見える結果を即座にもたらす様子を見ることができるとき フィードバック ディスプレイはサイズに関係なくもっとも重要 iOSデバイスのディスプレイは、ユーザ体験の中心的位置を占めています。ユーザはきれいな文字、 グラフィック、メディアを見るだけでなく、(画面を見ることができなくても)Multi-Touch画面と指 で物理的にやり取りして操作を進めます。 iOSデバイスにはさまざまな寸法や解像度のディスプレイがありますが、使い勝手に関する限り、考 え方はいずれも同じです。 ● タップ可能なUI要素の快適な最小サイズは44×44ポイントです。 ● ユーザは一般に、アプリケーションアートワークの質を敏感に意識します。 ● 画面表示が良好であれば、デバイスの違いを意識せず、本来の作業に集中できます。 注意: ピクセルとは、画像編集アプリケーションにおいて、デバイスの画面のサイズや作成 デバイスの向きを変えられる ユーザはいつでも、さまざまな理由でiOSデバイスの向きを変えることができます。たとえば、実行 する操作が縦長の向きのほうが自然に感じられる場合もあれば、横長のほうがより多くの情報を表示 できると感じられる場合もあります。デバイスの向きを変える理由が何であれ、アプリケーションの 主要な機能が見やすいままであることをユーザは期待します。 ユーザが対話するのは一度に1つのアプリケーション フォアグラウンドに表示できるのは一度に1つのアプリケーシ ションから別のアプリケーションに切り替えると、前のアプ し、そのユーザインターフェイスも表示されなくなります。こ ユーザが再起動または停止するまで、アプリケーションをバ ます。 ほとんどのアプリケーションは、バックグラウンドに移行す 状態のアプリケーションはマルチタスクUIに表示されるので、 易に切り替えることができます。マルチタスクUIは画面の一番 ションのUIまたはホーム(Home)画面の下に表示されます(次 リ ケーションの場合)。 共通化しすぎて最適化できない レギュレーションが足かせに
  10. 10. 全部実際に起こりました
  11. 11. これなら怖くない! 大規模サイトCSS設計の勘所 The vital point of a large-scale site CSS design
  12. 12. 指定の衝突、ダメ絶対!1
  13. 13. 全体共有のセレクタは明確に .worklist{...} 場所をなるべく限定する #list .worklist p #list p .d-worklist{...} 例:接頭辞で明確にして衝突を回避する
  14. 14. 将来の修正、変更を考える2
  15. 15. id,classの命名は意味的に .caution{color:red} .red{color:red} 指定がなくてもclassをつける <div class=”listbox”> <div>
  16. 16. 組織の要件に合わせた CSS設計をする 3
  17. 17. ストラクチャタイプ HTML構造を重視、構造に沿ったCSS指定をしていく 組織の要件に合わせた CSS設計をする 3
  18. 18. ストラクチャタイプ HTML構造を重視、構造に沿ったCSS指定をしていく #page-top #list {…} #page-top #list .worklist li {…} <body id="page-top">   <div id="list">     <ul class=”worklist”> <li>...</li> </ul> CSS HTML
  19. 19. ・ページごとに最適化が可能 ・デザイン修正のみならCSSだけで対応できる メリット ・パーツを使いまわしにくい ・記述が冗長で開発、修正に時間がかかる デメリット デザイン、最適化重視の要件 sassで 解決 ストラクチャタイプ HTML構造を重視、構造に沿ったCSS指定をしていく
  20. 20. 組織の要件に合わせた CSS設計をする 3 モジュールタイプ 可搬性のあるパーツ単位でHTMLとCSSを作成する
  21. 21. モジュールタイプ 可搬性のあるパーツ単位でHTMLとCSSを作成する ul.worklist li {…} ul.favoritelist li {…} <ul class="worklist">   <li>... </ul> <ul class="favoritelist">   <li>... </ul> CSS HTML
  22. 22. スピード、保守コスト重視の要件 モジュールタイプ 可搬性のあるパーツ単位でHTMLとCSSを作成する ・パーツ一覧からコピペで開発ができる ・デザイン統一がしやすい メリット ・パーツ修正の検証範囲が広い ・ページ単位のデザイン最適化がしにくい デメリット
  23. 23. 組織の要件に合わせた CSS設計をする 3 オブジェクトタイプ class指定の組み合わせでパーツの見た目を定義する
  24. 24. オブジェクトタイプ class指定の組み合わせでパーツの見た目を定義する .headline{font-size:18px} .caution{color:red; font-weight:bold} .center{text-align:center} <p class="headline caution center">... <div class="caution center">... CSS HTML
  25. 25. フレームワーク重視の要件 オブジェクトタイプ class指定の組み合わせでパーツの見た目を定義する ・CSSファイルを触らずに開発ができる ・コピペで開発ができる メリット ・CSS設計にスキルを要する ・CSS修正による影響予測が困難 デメリット
  26. 26. 組み合わせて使用してOK 単一ページ:「ストラクチャタイプ」 サイト全体:「モジュールタイプ」 未使用 :「オブジェクトタイプ」 うちの要件には合わなかった DMMでは…
  27. 27. まとめ ・大規模サイトでは運用を考慮する ・CSS指定の衝突は絶対避ける ・組織の要件に合わせて設計する
  28. 28. ご清聴ありがとうございました Makoto Inoue Talk of CSS fearful in fact

×