6年ぶりにマークアップの知識にアップデートをかけるよ！

こんにちは@hazumuです。

最近、久しぶりにマークアップをする案件が複数走ったので、これを契機に、学生時代から毛が生えたほどしか増えていない知識を、いっそ刷新してナウでヤングな開発ができるようになるために色々教り試行錯誤したので今回記事にしてみました。

せっかくなので、僕がWebを触り始めてからの歴史の変遷を辿った上で、長年に渡りこの分野を担当する人が戦ってきた問題を洗い出して現状どういう打開策や効率化が行われているか自分なりに整理し直した形にしています。
それでも、この分野の進歩が早いので1年ぐらい遅れてる話になってるかもしれませんが 笑

学生時代(2008年頃)

最初にHTML、CSSを友人から教わったのがこのくらいの時です。
僕より先輩の方はテーブルレイアウトでウェブページを作成してきた人が多いかもしれませんが、僕が始めた時には既にfloatでレイアウトを組むページが目立つようになっていました。頑張って新しくなったYahoo!トップやAppleのページ等の模写をやってました。 余談だけど、Dreamweaverって「夢を紡ぐもの」っていう中二病っぽい名前めっちゃ好きですよ。

この頃の思い出

• 対象ブラウザはIE6、FireFox2、Safari
  • SleipnirやLunascapeを使ってたのもこの頃
• XHTML
• Yahoo! Japanデザインリニューアル
  • Yahoo!JAPANのトップページリニューアルが市場に与える影響は？ (1/2)：MarkeZine（マーケジン）
• Dreamwearver

この頃話題だった本

Web標準の教科書

実践 Web Standards Design ~Web標準の基本とCSSレイアウト&Tips~

セマンティック HTML/XHTML

※思いの外Web標準の教科書が古かった件

新入社員時代(2010年)の状況

2010年に社会人になり、拙いながらHTML、CSS、JavaScriptの案件をこなしていました。
この頃はみんな必死でスマホサイトを組んでいたり、遊び心でCSS3のグラデーションをしれっと混ぜ込んで見たりと、それはそれで楽しい時期だったと思います。

この頃の思い出

• 盛り上がるHTML5 、CSS3
• IE6、7が現役
  • 残存するブラウザハック
• iPhone、Androidの台頭
  • 「スマホはWebkitだからCSS3使えるよね！」
• Graceful degradation vs Progressive enhancement
• Zencoding
• 手作りのCSSスプライト
• 高速化！高速化！

この頃話題だった本

徹底解説HTML5マークアップガイドブック

ハイパフォーマンスWebサイト ―高速サイトを実現する14のルール

一昨年ぐらい (2013年〜2014年頃)

数年間JavaScriptだけ書き続けていた時期があり、その後、少人数のプロジェクトでSingle Page Applicatonを作りながらマークアップをする機会があったのですが、その時は完全に浦島太郎状態でした。なんとなく存在は知っていましたが1年ぐらい遅れて導入したSassとCompassにはかなり作業を効率化させてもらいました。

「スプライト画像をデザイナーや、コーダーが作らなくていい！」みたいな

また、BEMやOOCSSなんかが叫ばれはじめたのも、この前後の年でしょう。おそらく2010年ぐらいから長期運用されてきたサービスの運用課題に対する一手が探され始めたからだと思いますが。

この頃の思い出

• IEは8以上対応
• HTML5タグを利用してマークアップ
  • sectiont, header, footer
• CSSアニメーション三昧
• ベンダープレフィックス
• レスポンシブデザイン
• CSSメタ言語
  • Sass、Less
• Compass
• BEM、OOCSS

この頃話題だった本

Web制作者のためのSassの教科書 これからのWebデザインの現場で必須のCSSメタ言語

Web制作者のためのCSS設計の教科書 モダンWeb開発に欠かせない「修正しやすいCSS」の設計手法

そして時代は流れて2016年春へ....

課題の整理

と、その前に、、

ここまで振り返ってみた上で、各年度ごとに挙がってきた課題の共通項を一旦整理します。その上でこれからマークアップを始める場合にどういう技術選択が潮流を捉えているのか、そして、どういう技術選択をするべきなのかを調査・考察してみます。

ざっくりとですが、長年にわたってマークアップの歴史は以下の問題との対峙の歴史のように見えます。

1. ブラウザの対応範囲の判断
2. レイアウト手法
3. 高速化
4. セマンティクスの厳密性
5. 保守性
6. 生産性の向上

1. ブラウザの対応範囲

企業やプロダクトのポリシーに依存する部分も大きいですが、この対応範囲如何によって開発の速度や保守性は大きく左右されます。
現在ではPCに加えスマートフォン(過去で言うとガラケー)のブラウザの種類 x OSの種類まで動作・表示を担保することになると、並の開発規模では太刀打ち出来ません。しかし、すべてを揃えることができる大企業であったとしてもその確認工数と対応工数は馬鹿にならないでしょう。
なので良きところで折り合いをつけて、プロダクト自体の改善に取り組む方向に注力すべきです。そのために、チーム全体の認識としてリリース時のブラウザ対応範囲と将来のサポートポリシーはしっかりと定めておきたいところです。

2. レイアウト

テーブルレイアウトからWeb標準準拠でfloatを利用したレイアウトと変遷してきたこの分野は、閲覧メディアの多様化やCSS3のフレキシブルボックスレイアウトの出現に寄ってこれからどのように変わるのでしょうか？
Webページの骨組みの部分なのでしっかりと抑えたいところですね。

3. 高速化

アマゾンがページの表示速度を数倍したら売上がXX%上がったという発表をしたことにより、2010年ごろWebページの高速化の波がバズワードの様に広がりました。一方で、無茶なCSSスプライトの手運用や画像の圧縮でフロントエンド側のタスクが増えたり、サバクラ間でのボトルネックの取り違いによる余計な作業が増えたりもしていました。
丁寧に計測しつつ運用や納期とのバランスを取って実装を行いたい箇所ではあります。

4. セマンティクス

HTML5でマークアップできる時代なりましたが、どの程度厳密にやる必要があるのでしょうか。クローラーや音声リーダーはどのくらいセマンティクスを認識しているのか。開発者側はそれを理解し、どこまでセマンティックに書くべきか、もしくはセマンティクスを排除してdivだけでUIを構築すべきなのか判断基準を持っておいたほうがよいでしょう。

5. 保守性

開発〜リリース時は、現場にいるデベロッパーたちのオレオレルールでも良いのですが、部署異動や退職もあり人は常に流動的です。
そのため、更新されないドキュメントよりも何かしら普遍的なルールを適応して保守性の担保に勤めるべきということが長い議論になっています。
(特にCSS！)

6. 生産性の向上

言ってしまえば元も子もありませんが、手早く作業を終わらせると言うのは永遠の命題です。
利用するエディタというレベルからHTMLのショートカット記法の利用、スプライトの作成などは最も早く自動化すべき事項だったりします。

そして2016年春

では、先の項目で挙げた課題たちと、これから僕たちはどのように対峙して行けばよいのでしょうか？

1. ブラウザの対応範囲

PCブラウザについて

これに関しては何よりも、2016年1月12日にIEが旧バージョンのサポートをやめたことが大きなインパクトになったのではないでしょうか。

10年、20年続いているサービスならまだしもこれから開発を始めるサービスでは、全てのブラウザにおいて最新版をサポートターゲットとすればいいと思っています。とりわけ、エンドユーザーが利用できないレベルの表示崩れならまだしも、スタイルの多少のズレは、メジャーなブラウザでの表示を担保した上で、多少許容していかなければ、ビジネス側から求められる開発速度にはついていけなくなると思っています。

Internet Explorer End of Support

Android Browserについて

2〜3年前はこれでもかというほどAndorid2.x系のバグとパフォーマンスの悪さに悩まされていましたが、運営しているサービスの直近1ヶ月のAndroid Browserだけのセッションを調査したところ大体こんなものでした。2.x系は完全に無視していいレベルですね。
(既にみんな切ってるかもですが)

4.3系以前の標準がAndroid Browserなので、数字を見る限り存在自体は無視できないレベルではありますが、優先度は下げてあげてもいいと思われます。

Android Browser単品

Android OSで見ると

こんな記事も。
滅び行くAndroid 標準ブラウザをサポート外にして悩みの種をなくす話 - Qiita

結論

• PC
  • 各ブラウザ最新のみ対応
• Android
  • 4系以上のAndroid BrowserとChrome
• iOS
  • 書いてないけど8, 9(あまり大きくバグる印象がない為)

2. レイアウト

さてさて、ブラウザのサポートバージョンを最新のものに揃えたとしてこのご時世レイアウティングはどうすべきなのか。前職の同僚からMaterial Design Lite(以下MDL)というGoogle製のフレームワークを教わっていたので、そのHTMLとCSSを解析するとこにしました。

MDLのダッシュボードというテンプレートのCSSを読んでみる。 www.getmdl.io

結果

フレキシブルボックスレイアウトのみ！
ころころ仕様が変わってデベロッパーを翻弄していたあれですね。以前わけがわからなくなって一度記事にしています。

CSSのdisplay: box;ってどうなったんだっけ問題 - 俺、サービス売って家買うんだ

MDLで面白かったのが、いいのか悪いのかを別にしてこういった横並びの部分。

ソースコードを見ると、spacer-gifならぬspacer-divみたいな組み方してるんですねこれ。 ここまでしてフレキシブルボックスレイアウトを追求するとは。。

色々プロダクトで試したところChromeとSafariでまだフレキシブルボックスの解釈が違ったりCan I useでIE11がPartial Supportって書いてあったりはするもののフレキシブルボックスレイアウトに移行しようと考えています。世の各種FWがそうなってるなら染まらずを得ない潮流になってくるでしょうし。

結論

• フレキシブルボックスレイアウトで！

3.高速化

ここ数回マークアップの作業をしてて思ったのですが、高い画質の画像を多用するようなブラウザのゲームでもない限り、LTEやFTTH下にいて細やかなスプライト画像の作成や、CSSのミニファイ、ユニファイをする必要もなくなってきているのでは無いでしょうか。その手を環境を整える手間やGrunt、Gulpで利用しているモジュールが将来5年にわたって使えるのかどうか考えると結構怪しい物が多いので、多少妥協した方が都合が良いと考えています。
また、もう少し先の話かもしれませんが、 これからHTTP2への移行が行われていくのであれば、現在利用しているバッドノウハウがいよいよ必要なくなってくるので、今からの開発でフロントエンド側の高速化に気を配りすぎるのも運用面を考えても筋の良い打ち手では無くなりそうです。

あくまで運用や開発速度とのトレードなので、下記のように最低限のことは気をつけるべきですが。

• ネットワーク回線の細い途上国向けのサービスの場合は最大限気を配る
• 馬鹿でかい画像の多重ロードはしない。遅延ロードさせる等
• ランディング、且つ離脱ページなのにプロダクト全体向けの大きなスプライト画像は読み込まない

※参考
HTTP2 時代の Web - web over http2

結論

• スプライトや結合はバッドノウハウなので最小限+最後の手段として行うべき
• 気を配らないと行けない時もあるので要計測

4.セマンティクス

さてさて、どの程度セマンティックにHTMLを書くべきなのでしょう。

SEOに関して
昨今SEOを頑張っているキュレーションメディアのHTMLを色々調査しましたが利用されているタグはnavやsectionぐらいでした。

以前はHTML5を利用してセマンティクスを整えるだけ効果があるものかと思っていのたですが、結局コンテンツの質やサービス自体の質に寄ってしまうので、現実的には直接的な効果はなさそうです(あったとしても捉えきれない程度)。そもそもググったところでこの話題に関して2012年より先の情報がほとんど出てこなかったので、誰ももうこの件に関しては気にしてないのかもしれませんね。 (むしろちゃんとやればやるほど広告部分がアプリから記事を閲覧するビューアーから弾かれて売上が下がりそうな(ry..)

音声リーダーに関して

Voice Overでmainタグとnavタグで遊んで見たのですが読み上げられる順序が変わるとかはなかったです。この分野はこの分野で深いのでまた今度ということで。。

結論

• HTML5タグを利用してもいいけど、よりセマンティックにする悩みに大きな時間をかけてもリターンはそこまで大きくない
• 現状見えてるメリットとしてはソースコードの可読性があがるぐらい
• GmailみたいにインタラクティブWebアプリケーションで且つクローラを相手にしないならdivだけでいい

5.保守性

個人的に一番の鬼門がここです。

うまくマークアップをやれる同僚からはFLOCSSめっちゃおすすめされてます。 ただ、、ただ、、これこれそちゃんと勉強し直さないとできない奴やん＼(^o^)／

BEMの時点でそうなのですが、なまじ積み重なった経験がある分、ガラッと概念を変えないときついですね。
ここまでくると、誰か、専門で、やってくれる、人が、いな..いと....（´・ω...:.;:: ..

結論

• ルールは何かしら入れた方がいい
• 学習コストとレビューで開発速度が落ちるぐらいなら3年ぐらいプロダクトを崩壊から守れるルールで良い
  • というか記述ルールよりネームスペースが存在しないCSSにどうやってそれを与えるかを考察すべき
    • リクエスト数を犠牲にしてページごとにファイルを分けるとか

6.生産性の向上

生産性の向上に関してはとりわけ大きな学びがありました。だらだら文章にしても読み切れないので箇条書きで。

HTML

• HTML、CSSの納品案件でもejsなどのテンプレートエンジンを利用する
  • 共通部分のincludeや変数の利用で最終的にレンダリングしたものを納品物とする

CSS

• ベンダープレフィックスは書かない
  • autoprefixerがよしなにやってくれる
• Compassよりもnode-sassやspritesmithを利用してnodeのエコシステムだけで完結させるようにする

フォント

• Icon Fontの多用
  • An Introduction to Icon Fonts with Font Awesome and IcoMoon
  • Material icons - Google Design
• ちょっと重いけどWebFontの実用化
  • Google Noto Fonts

などなどとこの辺が新しく使えるようになっていましたね。

まとめ

まとめに整理しておくと、2010年から比べると

• ブラウザの対応範囲
• レイアウトの方法
• 生産性向上のために入れられるツールの潤沢化

といったところに大きな変化が見られました。おもいっきりCSSやHTMLが変わってストーリボードで云々みたいな変化はないので以前からの知識でもまだまだ対応できるし、むしろツールが潤沢になっているので前よりもコーディングが楽になったとすら感じました。

やはり、ただただCSSの保守性に関する運用ルールに関してはBEMやOOCSSなどを取り入れても、個々人のスキルレベルや解釈の違いにより崩壊しない運用は難しそうで銀の弾丸かといわれると「う〜ん」と言わざるを得ない感じでした。やっぱ難しいですよね。。

とは言え、ほんとに色々変わったな〜。
なんとか若い子について行きたいですね　(ง `ω´)۶ｵﾗｯｵﾗｯ