5年前と、web制作における環境が大きく変わってきています。 よって、実装方法や制作フローも変えていくべきです。 どのようなポイントを抑えておけばいいのかを解説します。 社内向けの勉強会で使用したスライドです。（一部手を加えています）

1. 脱！Web制作における
5年前の常識

2. • フロントエンドエンジニア
• マークアップエンジニア
• ディレクター
2011年3月にインターンで入社。
webサイトの新規制作や運用で、
数多くの案件に携わっています。
ちょっとしたデザインや、ちょっとしたCMS改修、
ちょっとしたディレクションもできます。

3. この5年で、
状況が大きく変わっています

4. 時代は本格的にHTML5/CSS3へ
• きれいなソース書きたい
• 古い書き方だと運用つらい
• 楽したい！！
2014年4月9日
IE6のサポート終了
2016年1月12日
IE8のサポートが終了

5. 2014年10月28日
HTML5がW3Cの勧告になる

6. スマホ普及率が高くなる

7. • IE6のシェア率
• HTML5/CSS3対応ブラウザのシェア率
• スマホからのアクセス数
5年前と大きく状況が変わっている！
DOWN
UP
UP

8. • トレンドの技術が使えるようになってきた
• パソコン、スマホ、タブレットなど
多様な見せ方を求められてきている
Web制作に、よりスピード感が
求められている
結局どういうこと？

9. 現状は、この変化に
今一歩踏み出せていない…

10. ポイントを知り
みんなで幸せになろう！

11. ポイント
1. ○CSS
×画像
2. ○モジュールをデザイン
×画面をデザイン
3. ○ブラウザの解釈に委ねる
×デザインの完全再現

12. 1. ○CSS
×画像

13. 角丸で見るCSS3

14. 昔のやり方
画像を3つ作り、
3つのdivそれぞれに
背景画像として設定

15. イマドキなやり方
border-radius: 10px; たったこれだけ！

16. ソースの比較

17. 86.4%
8.2%
5.4%
2010年1月
非対応 対応 21位以下
18.3%
72.3%
9.4%
2015年3月
非対応 対応 21位以下
5年前と比較する角丸（border-radius）対応状況
http://news.mynavi.jp/news/2015/04/06/311/http://news.mynavi.jp/news/2010/02/01/020/
※Net Applications調べの各年のシェア率20位以上のブラウザで調査

18. 角丸が対応してないブラウザでは、
どう表示されるのか
崩れるわけではなく
角丸にならないだけ

19. 古い書き方（10分）
• HTMLで「radiusBlockLarge」
というクラスを振る
• デザインデータを探す
• デザインデータを編集し、画
像を3枚書き出す
• 画像をディレクトリに格納
• CSSで横幅を400pxにする記述
を書く
• CSSで画像パスを設定する
イマドキの書き方（30秒）
• HTMLで「radiusBlockLarge」
というクラスを振る
• CSSで横幅を400pxにする記述
を書く
もし、サイズ違いが必要になった時…
95%
OFF

20. このように、画像ではなく
CSSで表現することで…

21. HTML/CSSがきれいになる！
制作すべき画像が減る！
ページが軽くなる！

22. CSS3でできること

23. ボタンもCSSでこんなにリッチになる

24. ほかにも！

25. フォント：デバイスフォント

26. もしMSゴシックまでしかなかったら…

27. フォント：webフォント

28. CSSで図形を描く

29. 画像ではなくCSSで表現するメリット
• ページが軽くなる
• 工数が下がる
• ソースがきれいになる
• サイズ違い、色違いが作りやすい
（拡張性がある、スマホ対応しやすい）

30. 極力、画像ではなく
CSSで表現できるデザインを！

31. 2. ○モジュールをデザイン
×画面をデザイン

32. 全ページデザインデータに
落とす必要はない！

33. PC：25ページ
SP：25ページ
の場合

34. デザイン数の比較
PCトップページ
（1P）
PC主要ページ
（4P）
PC全ページ
（20P）
SP全ページ
（25P）
PCトップページ
（1P）
PC主要ページ
（4P）
PCモジュール
（1P）
SPトップページ、
モジュール
（2P）
84%
OFF
昔
イマ
ドキ

35. デザインもなしに、
クライアントに
デザインFixをしてもらえない…

36. 結局全然Fixしてくれないから、
むしろフィードバックに強い
やり方を採用したほうがいい！

37. 昔の確認のタイミング
トップページ 主要ページ 全ページ
デザイン
全体
テイスト
確認
主要ページで
枠組み
確認
全ページ
確認
コーディング トップページ 主要ページ 全ページ
トップページ
確認
主要ページで
枠組み確認
全ページ
確認

38. イマドキな確認のタイミング
トップページ 主要ページ モジュール
デザイン
全体
テイスト
確認
主要ページで
枠組み
確認 全ページ
確認
コーディング トップページ モジュール 主要ページ 全ページ
トップページ
確認
主要ページで
枠組み
確認

39. モジュール単位でデザインするメリット
• フィードバックがあっても、
マークアップだけで対応できる
• デザイナーの工数を下げることで、
クリエイティブに時間がかけられる

40. 制作フローを変える余地が
まだあると思います
一緒に模索しましょう

41. 3. ○ブラウザの解釈に委ねる
×完全再現

42. 点線（border-bottom: 2px dotted #666;）
の表示解釈差

43. 全く同じに見える必要はあるのか
違うブラウザなので、
全く同じにならないのは当たり前

44. ブラウザ間の差を解消するために
工数を割く必要性はあるのか…

45. 他社フロントエンドエンジニアに
「まだIE8対応してるの？！」
と言われた

46. 繰り返しになりますが…
崩れるわけではなく
角丸にならないだけ

47. それよりも
クオリティアップに
時間割きたい！

48. フロントエンドはやることがたくさん！
• ページの大量生産
• スマホ対応
• モーダル、スライダーなどの実装
• META、リンクの設定
• マウスオーバー、アニメーション

49. 少しでも時間が増えれば、
クオリティアップできるところは
たくさんある！

50. ブラウザの解釈に委ねる方針にする
メリット
• ソースがきれいになる
• ブラウザ対応への工数が下がる
• チェック工数が下がる
• 他のクオリティアップに時間が使える

51. まずは、摘要とレギュレーション
一番むずかしいのが
クライアントが納得するかどうか

52. さいごに
営業、ディレクション、デザイン、
マークアップ、システム、運用…
分業体制を取っている以上、
負担が偏ったり増えたりするのは必須です。
どうしたらもっといいものを作れるのかを
業種を跨いで考えていきたいです。

53. まとめ
• CSSで表現できるデザインを
• 制作フローも変えましょう
• ブラウザ対応への理解を変えましょう
• 業種を跨いで連携しましょう！