2018年10月11日 21時00分から開催されました「#2 WP ZoomUP『2018年のフロントエンドのトレンドから見るコーディング事情』」に参加しました。
今回は事前にZoomの使い方もおさらいして、#1の時の様な使い方が分からずパニックに陥るという失敗は冒さない様、下準備ばっちり。
WP ZoomUPとは
#2 WP ZoomUP『2018年のフロントエンドのトレンドから見るコーディング事情』の内容
今回は、イー・ネットワークスの前川昌幸さんによるという内容についてお話いただきました。
メモした事をまとめます。
途中お話に聞き入ってメモを取り忘れたりもしたので、スライドが公開されたら編集するかもしれません。
HTML5.2
W3CとWHATWG(ワットワーキンググループ)2つのグループがHTMLの仕様を考えていて、5.2はW3Cの方が決めているそうです。
WHATWGはバージョンを区切らず常に刷新しているんですって。こちらは
Apple、Chrome、Operaが設立した団体でHTML Living Standardと呼ばれています。
「HTML5.2に書いてあることは大体OK」と私のメモには記されていますが、「何がOKなんだよ」と自分で自分に疑問を持ちます。
たしか、WHATWGの仕様はHTML5.2の内容に沿って大丈夫という意味だったと思います。
5.2から出来る様になった事のひとつに、dl要素の中にdivを配置しても良くなったというのがあるそうです。前までは下記のdt、ddの中にしか置いては行けなかったdiv
5.2ではこんな事できちゃいます。
divで囲った要素だけになにかできますね!
ウェブアクセシビリティ
今年は障害者差別解消法の施行がありました。
国内のアクセシビリティ規格「JIS X 8341-3:2016」に関するお話では、100点満点を満たすページを1ページ作るなら、50点が100ページある方が良い!と、界隈の方々は語るそうです。
「100点一つとれるより、そこそこの点数を稼ぐ方が有用的!」
この言葉は胸に響いたので2回書きました。
やらないよりはちょっとでもやった方が絶対的に良いのです。
また、達成条件はA(シングルエー)、AA(タブルエー)、AAA(トリプルエー)の三段階ですが、AAAを満たすには「動画には必ず手話と字幕を付ける」など、コスト面で不可能に近い達成条件が存在する為、仕様書等の基準はAAとなっている事が一般的。
私がこれまで読んだ仕様書のアクセシビリティ条件もこの通りです。
「トップページはAAAである事」と書いてあった時はデザイン段階で工夫して仕様を満たすのに苦労した思い出があります。
アクセシビリティは余計なことをしないほうがいい
もうひとつの衝撃、それはアクセシビリティには「テキストの大・中・小切り替えボタン」および「背景色変更」機能は付けなくて良いというお話でした。
実際に弱視の方はディスプレイの表示を5倍、10倍にして閲覧する。
大・中・小切り替えボタンでなんとかなる人は居ない。誰も使っていない。
とのことでした。
また、「白黒反転でウェブを見ている人」は確かにいらっしゃいますが、これもOSがやる事でウェブがやる仕事ではないそうです。
特にiOSは技術が進んでいるのでわざわざCSSで一生懸命実装しても無駄だよ~って。
この話、仕様書を策定する誰かに確実に届いて浸透するといいなぁと感じました。
所詮テキストにしか影響しない「テキストの大・中・小切り替えボタン」は要らない!
背景色変更もOSがやるから要らない!
これもガツンと胸に響いたので2回書いておきます。
Sassの活用がデファクトスタンダード
横文字ぐぐりました。 「de facto standard=事実上の標準」
つまり今やSassを使う事が標準化しているのだそうです。
使った事が無い自分はなんて時代遅れなんだろうと衝撃を受けました。
今までチーム内で規模の大きなサイトを初期から構築する人間が自分だけだったので、学びをつい怠ってしまっていました。
ここからはしばらくこのお話について何か新しく始めるヒントになることはないかとメモをひたすら取っていました。
まず、RubySassの開発は停止し、2019年4月でメンテナンス終了だそうです。
ウェブで調べて出て来る情報はRuby時代のものが多いので気を付けてとの事でした。
Rubyの廃止により、Dart Sassへの移行とLib Sassの開発となり、Lib Sassが開発のメインとなるのか?といえば、コードを書く人はあまり意識しないとの事でした。
DartSassかLibSassかはあまり気にしないで、ほぼ同等の機能ですって。
これについてはこちらがおすすめの本だそうです。(会社で買ってもらおう)
Web制作者のためのSassの教科書 改訂2版 Webデザインの現場で必須のCSSプリプロセッサ
ちなみにclass設計の決定版はみつからないそうです。
BEMに傾く人が多く、今はFLOCSSが良いかなってお話がチャットに流れていました。GutenbergもBEMなんですって。
(今の所BEMが分からない私は妖怪人間の事を少し思い出しました。全然違うんです。)
FLOCSSの勉強に関するオススメの本はこちらだそうです。
柴犬でもわかるFLOCSS(PDFダウンロード版です)
脱jQuery
衝撃3つ目。それはこの言葉でした。
「jQueryはオワコン」
元々jQueryは日本中のエンジニアが入団した「旧IEブラウザシネシネ団(架空)」が心安らかな理想郷に辿り着くべく広まった箱舟だったんですよね。
しかしブラウザの進歩で「ブラウザーの差異を埋め世界を平和にする」という使命を帯び旅に出る勇者は姿を消していきました。
CSSアニメーションの普及、SPA等の新アーキテクチャ。
DOMを直接操作するjQueryには厳しい実装も、Angular、React、Vueが普及し叶うようになりました。
これまではjQueryに頼らざるをえず、パフォーマンスを諦めていた部分を上記アプリケーションやフレームワークを使うことで改善しましょうということでした。
でも、絶対そうという訳ではなくて、ホームページにはやっぱjQueryでしょ。簡単だもん。利点は多いよっていうお話もあったので、ここまで「村の1歩外に出てみたら空飛ぶ自動車飛んでました感」を抱いていた私は救われました。
非常に進歩したJavaScript
最新仕様のES2018はTypeScriptがaltJS言語のメインストリームに(チームでの開発に非常に助かる言語)なっているんだそうですね。
でもどちらもそのままではブラウザーでは動かない。
ツールのお話
Sass、TypeScriptはそのままブラウザでは動かない。
ES2018はブラウザーがアップデートされないと動かないんだそうです。
コンパイル・トランスパイルが必要とのこと。
またEdgeはIEでなければ動かないシステムがたくさんあるので普及しないだろうってお話でした。そうなんですよね。シンクラ環境とかずーっとIEですもんね。
少なくとも私たちはあと8年程、IEと戦い続けることになりそうです。
チャットではこのポップアップJSが紹介されていました。IEユーザーにChromeを促します。名前は過激。
IE BUSTER(https://ie-buster.qranoko.jp/)
また、CSSのベンダープレフィックスの付与これらの作業を行うためにコマンドラインツールとして、
タスクランナー:Grunt→gulp
バンドラー:webpack
で、今後はwebpackが増えていくのかなという雰囲気だそうです。
無理に慌てて移行する必要はなく、新規案件など何かのきっかけの際にでもというお話です。
アプリ・サイト問わず求められること
それは「スピード」
何が原因かを把握できるようにしましょう。
Chromeのデベロッパーツールを使ってサイトスピードの解析を行う方法をご紹介いただきました。
- Chromeで解析対象ページを開く
- デベロッパーツールを起動してNetworkタブを開く
- リロードすると解析される
ここで、ページの表示に係った時間配分がわかり、何が原因で重いのかを判別するヒントになります。
- 緑バーが長い:サーバーの処理
- 青色が長い:ファイルサイズ
- 白色が長い:ファイルが多くて待っている
「この辺りはHTTPのプロトコルのやり取り(クライアントからサーバにリクエストが飛んできてから、クライアントへレスポンスを返し、ブラウザがレンダリングするまで)の仕組みをある程度把握しておいた方が良いですよ」というお話でした。
表示スピードを勉強するならこの本
超速! Webページ速度改善ガイド ── 使いやすさは「速さ」から始まる (WEB+DB PRESS plus)
また、前川さんのお話では「 あまり情報に振り回されないように(とはいえ鈍感でも問題)」との事でしたので、何が自分の仕事には必要で、何がお客様の求めているものなのかをしっかり精査したいと思いました。
このほか、これから覚えるならいきなりwebpackにいかないでgulpが良い。
npm-scriptsスタートもありだけどgulpがとっつきやすいかなとのことです。
npm-scriptの仕組みはまず知っておく必要がある。
(webpack、npm、覚える事は多そうです。)
Gulpの参考書
Webデザイナーの仕事を楽にする! gulpではじめるWeb制作ワークフロー入門
著者
「gulpではじめるWeb制作ワークフロー入門 」著者によるセルフライナーノーツ
Sass
その他
以下はチャットのログからあとでヒントにしたいと思って抜き出したメモです。
- https://sass-lang.com/install
こちらのページの左側にあるツールがGUIツール関係。個人的なおすすめならPrepros。 - VSCodeはEasy Sassが楽かも
https://marketplace.visualstudio.com/items?itemName=spook.easysass - gulp 便利だとは思うとそんなに自動化したいことがないのでnpm scripts。
いろんなお話がありますね。
感想
参加中、猫達が背後で遊ぼう遊ぼうと大暴れしていましたが、なんとか邪魔されず最後まで聞く事ができました。
HTML5.2、アクセシビリティ、脱jQuery、サイトスピード、今の自分が直接関係するお話が多く、あっという間の時間となりました。
第2回WP ZoomUP が終わった後、強く思った事は「Sassを勉強するべき!」でした。
どういう物なのかお恥ずかしながらぜんぜん分からないのでまずはご紹介頂いている本を買って読んでみるところから始めてみたいと思います。
欲しい本が一気に決まった。
お話頂いた前川さん、充実の時間をありがとうございました。
Chromeのデベロッパーツールのお話は、説明してもなかなか納得しづらいような状況のクライアントさんに視覚的に説明するツールとして活用できそうです。
開催中に感情に任せてサーバー会社の悪口みたいな事を書いた私にもご丁寧なコメントを頂いて恐縮です!前川さんのコメント読みたい方はこちらからどうぞ!!
仕事でどう工夫しても遅いサイトがあって、お客様がご契約されているサーバー会社に問い合わせたら私が作ったWordPressテーマのせいって言われたことがあったけど、ChoromeのデベロッパーツールのNetWork見たら緑の棒が果てしなく横に伸びてたよあのサーバーめーーー #wpzoomup
— えび子 (@evicco) October 11, 2018
余談
WP ZoomUPが始まってからうちの猫たち何度も遊ぼうと誘いに来てくれましたが聞き流していましたところ、終わってからしばらくは目をまったく合わせてくれなくなっていました。
いつもはウットリ見つめてくれるのに、どこに回り込んでもサッと視線を逸らされるんですよね。
放置してごめんでした。
コメントを残す