cssこんにちは@hazumuです。最近、久しぶりにマークアップをする案件が複数走ったので、これを契機に、学生時代から毛が生えたほどしか増えていない知識を、いっそ刷新してナウでヤングな開発ができるようになるために色々教り試行錯誤したので今回記事にしてみました。僕がWebを触り始めてからの歴史の変遷を辿った上で、長年に渡りこの分野を担当する人が戦ってきた問題を洗い出して現状どういう打開策や効率化が行われているか自分なりに整理し直した形にしています。学生時代(2008年頃)最初にHTML、CSSを友人から教わったのがこのくらいの時です。僕より先輩の方はテーブルレイアウトでウェブページを作成してきた人が多いかもしれませんが、僕が始めた時には既にfloatでレイアウトを組むページが目立つようになっていました。頑張って新しくなったYahoo!トップやAppleのページ等の模写をやってました。余談だけど、Dreamweaverって「夢を紡ぐもの」っていう中二病っぽい名前めっちゃ好きですよ。新入社員時代(2010年)の状況2010年に社会人になり、拙いながらHTML、CSS、JavaScriptの案件をこなしていました。この頃はみんな必死でスマホサイトを組んでいたり、遊び心でCSS3のグラデーションをしれっと混ぜ込んで見たりと、それはそれで楽しい時期だったと思います。Applicatonを作りながらマークアップをする機会があったのですが、その時は完全に浦島太郎状態でした。なんとなく存在は知っていましたが1年ぐらい遅れて導入したSassとCompassにはかなり作業を効率化させてもらいました。「スプライト画像をデザイナーや、コーダーが作らなくていい!」みたいなまた、BEMやOOCSSなんかが叫ばれはじめたのも、この前後の年でしょう。2010年ぐらいから長期運用されてきたサービスの運用課題に対する一手が探され始めたからだと思いますが。見るそして時代は流れて2016年春へ....課題の整理と、その前に、、ここまで振り返ってみた上で、各年度ごとに挙がってきた課題の共通項を一旦整理します。その上でこれからマークアップを始める場合にどういう技術選択が潮流を捉えているのか、そして、どういう技術選択をするべきなのかを調査・考察してみます。長年にわたってマークアップの歴史は以下の問題との対峙の歴史のように見えます。企業やプロダクトのポリシーに依存する部分も大きいですが、この対応範囲如何によって開発の速度や保守性は大きく左右されます。OSの種類まで動作・表示を担保することになると、並の開発規模では太刀打ち出来ません。すべてを揃えることができる大企業であったとしてもその確認工数と対応工数は馬鹿にならないでしょう。良きところで折り合いをつけて、プロダクト自体の改善に取り組む方向に注力すべきです。そのために、チーム全体の認識としてリリース時のブラウザ対応範囲と将来のサポートポリシーはしっかりと定めておきたいところです。レイアウトテーブルレイアウトからWeb標準準拠でfloatを利用したレイアウトと変遷してきたこの分野は、閲覧メディアの多様化やCSS3のフレキシブルボックスレイアウトの出現に寄ってこれからどのように変わるのでしょうか?Webページの骨組みの部分なのでしっかりと抑えたいところですね。高速化アマゾンがページの表示速度を数倍したら売上がXX%上がったという発表をしたことにより、2010年ごろWebページの高速化の波がバズワードの様に広がりました。一方で、無茶なCSSスプライトの手運用や画像の圧縮でフロントエンド側のタスクが増えたり、サバクラ間でのボトルネックの取り違いによる余計な作業が増えたりもしていました。丁寧に計測しつつ運用や納期とのバランスを取って実装を行いたい箇所ではあります。セマンティクスHTML5でマークアップできる時代なりましたが、どの程度厳密にやる必要があるのでしょうか。クローラーや音声リーダーはどのくらいセマンティクスを認識しているのか。開発者側はそれを理解し、どこまでセマンティックに書くべきか、もしくはセマンティクスを排除してdivだけでUIを構築すべきなのか判断基準を持っておいたほうがよいでしょう。開発〜リリース時は、現場にいるデベロッパーたちのオレオレルールでも良いのですが、部署異動や退職もあり人は常に流動的です。そのため、更新されないドキュメントよりも何かしら普遍的なルールを適応して保守性の担保に勤めるべきということが長い議論になっています。言ってしまえば元も子もありませんが、手早く作業を終わらせると言うのは永遠の命題です。利用するエディタというレベルからHTMLのショートカット記法の利用、スプライトの作成などは最も早く自動化すべき事項だったりします。ブラウザの対応範囲PCブラウザについてこれに関しては何よりも、2016年1月12日にIEが旧バージョンのサポートをやめたことが大きなインパクトになったのではないでしょうか。10年、20年続いているサービスならまだしもこれから開発を始めるサービスでは、全てのブラウザにおいて最新版をサポートターゲットとすればいいと思っています。エンドユーザーが利用できないレベルの表示崩れならまだしも、スタイルの多少のズレは、メジャーなブラウザでの表示を担保した上で、多少許容していかなければ、ビジネス側から求められる開発速度にはついていけなくなると思っています。Browserだけのセッションを調査したところ大体こんなものでした。2.x系は完全に無視していいレベルですね。Browserなので、数字を見る限り存在自体は無視できないレベルではありますが、優先度は下げてあげてもいいと思われます。OSで見るとこんな記事も。レイアウトさてさて、ブラウザのサポートバージョンを最新のものに揃えたとしてこのご時世レイアウティングはどうすべきなのか。Lite(以下MDL)というGoogle製のフレームワークを教わっていたので、そのHTMLとCSSを解析するとこにしました。MDLのダッシュボードというテンプレートのCSSを読んでみる。www.getmdl.io結果フレキシブルボックスレイアウトのみ!ころころ仕様が変わってデベロッパーを翻弄していたあれですね。以前わけがわからなくなって一度記事にしています。俺、サービス売って家買うんだMDLで面白かったのが、いいのか悪いのかを別にしてこういった横並びの部分。ソースコードを見ると、spacer-gifならぬspacer-divみたいな組み方してるんですねこれ。ここまでしてフレキシブルボックスレイアウトを追求するとは。Supportって書いてあったりはするもののフレキシブルボックスレイアウトに移行しようと考えています。世の各種FWがそうなってるなら染まらずを得ない潮流になってくるでしょうし。結論フレキシブルボックスレイアウトで!3.高速化ここ数回マークアップの作業をしてて思ったのですが、高い画質の画像を多用するようなブラウザのゲームでもない限り、LTEやFTTH下にいて細やかなスプライト画像の作成や、CSSのミニファイ、ユニファイをする必要もなくなってきているのでは無いでしょうか。その手を環境を整える手間やGrunt、Gulpで利用しているモジュールが将来5年にわたって使えるのかどうか考えると結構怪しい物が多いので、多少妥協した方が都合が良いと考えています。これからHTTP2への移行が行われていくのであれば、現在利用しているバッドノウハウがいよいよ必要なくなってくるので、今からの開発でフロントエンド側の高速化に気を配りすぎるのも運用面を考えても筋の良い打ち手では無くなりそうです。運用や開発速度とのトレードなので、下記のように最低限のことは気をつけるべきですが。ネットワーク回線の細い途上国向けのサービスの場合は最大限気を配る馬鹿でかい画像の多重ロードはしない。http2結論スプライトや結合はバッドノウハウなので最小限+最後の手段として行うべき気を配らないと行けない時もあるので要計測4.セマンティクスさてさて、どの程度セマンティックにHTMLを書くべきなのでしょう。SEOに関して昨今SEOを頑張っているキュレーションメディアのHTMLを色々調査しましたが利用されているタグはnavやsectionぐらいでした。以前はHTML5を利用してセマンティクスを整えるだけ効果があるものかと思っていのたですが、結局コンテンツの質やサービス自体の質に寄ってしまうので、現実的には直接的な効果はなさそうです(あったとしても捉えきれない程度)。そもそもググったところでこの話題に関して2012年より先の情報がほとんど出てこなかったので、誰ももうこの件に関しては気にしてないのかもしれませんね。Overでmainタグとnavタグで遊んで見たのですが読み上げられる順序が変わるとかはなかったです。この分野はこの分野で深いのでまた今度ということで。個人的に一番の鬼門がここです。うまくマークアップをやれる同僚からはFLOCSSめっちゃおすすめされてます。これこれそちゃんと勉強し直さないとできない奴やん\(^o^)/BEMの時点でそうなのですが、なまじ積み重なった経験がある分、ガラッと概念を変えないときついですね。生産性の向上に関してはとりわけ大きな学びがありました。文章にしても読み切れないので箇条書きで。Fontsなどなどとこの辺が新しく使えるようになっていましたね。生産性向上のために入れられるツールの潤沢化といったところに大きな変化が見られました。おもいっきりCSSやHTMLが変わってストーリボードで云々みたいな変化はないので以前からの知識でもまだまだ対応できるし、むしろツールが潤沢になっているので前よりもコーディングが楽になったとすら感じました。CSSの保守性に関する運用ルールに関してはBEMやOOCSSなどを取り入れても、個々人のスキルレベルや解釈の違いにより崩壊しない運用は難しそうで銀の弾丸かといわれると「う〜ん」と言わざるを得ない感じでした。言え、ほんとに色々変わったな〜。Bot「アルフレッド」を公開しましたこんにちは。(1)スターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。