2017年3月18日（土）、大阪で「FRONTEND CONFERENCE 2017」が開催されました。
こちらのイベントに、小畑がLTで参加してきたので、その時のメモとなります。

朝から参加して、合計7セッションを見ることができました。最後のコマは、自分のLTの最終調整で見れなかったので、、、残念。

エンジニアとデザイナーとの距離

株式会社TAMの安田さんのセッション。今回のカンファレンスで、一番聞きたかった内容。
イベント前に、スライドをきちんと公開されてるところが、素晴らしいなぁと思いました。

エンジニアとデザイナーとの距離 from Manabu Yasuda

https://www.slideshare.net/manabuyasuda1/ss-73215731

Github にも、いろいろとドキュメントなどが公開されてますので、併せてご確認いただければと思います。

デザイナーとエンジニアの認識のズレはなぜ起こるのか
デザインの意図やコンテキストをコードの名前にする
見た目を表す名前はNG
名前空間を使う
デザイナーの意図を組まないといけない
ボタンが「詳細情報」であるかではなく、「優先度」がどうかということ
デザイナーとの認識合わせが必要
見栄えは30分後に変わってるかもしれない。デザインの意図やコンテキストは基本的には変わらない
設計手法はECSSから始めるのがよい
デザインの意図とコンテキストを共有すると、長期的にはコスト削減になる
見栄えと一致させた場合、デザイナーはすべてのページに対して細かく支持したり、チェックしないといけない
デザインの意図とコンテキストを一致させた場合、使う場所は自然と決まってくるので、こまかく指示する必要がない
サイトの規模が大きくなる毎に意図とコンテキストの共有はとても大切
ドキュメントとして残しておけば、プロジェクトを引き継いだデザイナーやエンジニアに優しい
手戻りにならないように、デザインカンプ作成後ではなく、作成前に共有しておく必要がある
問題点を探す時間より、一緒に考える時間をふやしたい
完璧なデザインカンプより、コミュニケーションツールとして活用したい

ECSSは、名前は聞いたことがありましたが、実際にどんなものか調べるまで至っていませんでした。
今回の話を聞いて、ストレスが少ない設計手法だなと感じました。

特に、デザイナーとのやり取りに対して、「見栄えは30分後に変わってるかもしれない。デザインの意図やコンテキストは基本的には変わらない」ということを頭にいれておくと、作り手の意識も変化するはず。これは、社内で共有しておくべき事項ですね。

ECSSの話は出てきませんがｗ「はじめてのCSS設計フロントエンドエンジニアが教えるメンテナブルなCSS設計手法」が先日発売されたので、購入しました。ざっくり、CSS設計について学びたい方には、こちらの本もオススメです。事例が多く掲載されていますので、感じを掴むには最適かなと思います。

ただ、CSS設計って、正解がないし、追求すると終わりがない世界です。僕も15年ほど追っかけてますが、まだまだしっくりくる設計手法に出会えてません。時代の流れの中で、最適なものを選んで行けばいいと思います。それが、今回聞いたECCSなのかもしれません。早速、業務の中に取り入れていこうと思います。

HTMLスナップショット2016（改）

もんどさんのセッション。歴史の話から始まり、なぜW3CとWHATWGが別れて存在するのかとか、まぁマニアックなお話ばかりで、とても楽しかったです。歴史とか経緯とか知ると更に深い世界に入れると思いました。みんな、派手な方に目が行きがちですが、こういう地味なことをコツコツしてくれている方がいるから、世の中成り立ってるんだなと、実感しました。diffの作業、実際に話を聞いてると本当に大変そうです。

「HTMLスナップショット2016（改）」

本がでる！（いつ出るのか不明）
最近は、仕様書を読む人が少なくなった印象
個人的にも、仕様書を再度読み込む必要あり（コミットしていくことも必要）
各仕様のdiffを取っていくのが、かなり面倒だなと思った
dlの中にdivを入れれるようになったのは知らなかった(；´Д｀)
英語の勉強がてら、仕様書を読む必要ありそう
翻訳のワークフローがどうなってるか知りたい＠ますぴーさん
もんどポイント貯めていかなｗ

今回は、東京で行われた「HTML5 CONFERENCE 2016」のセッションの再演ということで、ぜひ下記映像もご覧ください。

https://www.youtube.com/watch?v=K2a4dftTp00#t=1h58m17s

ウェブを構成するUIの品質とHTML

サイバーエージェントのますぴーさんのセッション。以前、AccTalk大阪でお会いしてからの久々の再会でした。

http://masup.net/slide/frontconf2017/index.html#/

HTMLがUIの基礎的品質を担う
CSSはよりコンテキストに沿ったものを担保する
JavaScriptは機能的品質を担う
HTMLをなるべくHACKしない
WAI-ARIAは、HTMLに足りないものを補うこと

今回のセッションで、一番印象に残ってるスライドがコレ。

まぁ、これに尽きますねｗで、更には、HTMLのお話の中に、さりげなく「アクセシビリティ」の話を盛り込んでくるあたりが、さすがますぴーさんだと思いました。「アクセシビリティ」を意識させずに、どう意識させるかっていうことを考えさせられました。

お話させていただいたときも、なるべく「アクセシビリティ」って言葉を使わないようにしていると仰ってましたので、そのあたり、僕も意識して取り組んでいきたいと思いました。

Enduring CSS

ピクセルグリッドの高津戸さんのセッション。安田さんのお話に続き、ECSSの内容でした。
ECSSは、CodeGridでも取り上げられてた記憶なので、また読み返してみます。

Enduring CSS from Takazudo

http://www.slideshare.net/Takazudo/enduring-css

それぞれの設計手法には、メリット・デメリットがある
名前空間という考え方
ECSSは、ページごとに設計する感じ
実装する際の、ストレスが少ない印象
無理して、共通化する必要もない←この考えが結構新鮮でした
同じようなものでも、別で設計する
複雑化を防ぐため
モジュールの粒度は、分離できることが大事
ECSSの定義：視覚的に認識できる、個別の機能領域のもっとも大きな区分
モジュールを名前空間でグルーピングする
各空間毎に、読み込むCSS、JS、画像類を完全に分離←ここも新鮮でした
分離することで、今後のメンテナンスにストレスを与えない

個人的に、BEMの命名規則は慣れないので、このECSSの考え方は実践してみる価値はあるなと思いました。特に、チームで作業する場合には、同じ方向を向きやすい。見ただけで、どこで使われているモジュールかが理解できるという点は、素晴らしいと思いました。これ、ストレスないですし、コミュニケーションコストもあまりかからないのでは。もちろん、慣れるまでには時間が必要でしょうが、一度理解してしまえば、モジュールの分け方で悩む必要がなくなりそうです。

CSSのミニマルさだけが美しさではない

この言葉は、ぐさっと刺さりましたｗあとで、編集することを考えたらどう設計すべきかを考えておく必要がありますね。分けて考える。これが結構重要なんだなという実感です。今までの自分の設計を見ても、やっぱりしっくりこないままやってきた感があるので、ECSSの考え方は救世主になりそうな予感。とはいえ、どの設計手法もメリット・デメリットがありますから、使いながら、良いところを吸収して、使いこなせればいいなと思っています。

CSSフレームワークをつくろう

長崎から来られた、キタジマタカシさんのセッション。

https://speakerdeck.com/inc2734/csshuremuwakuwotukurou

Wordpressのテーマ「Habakiri」や、CSSフレームワーク「Basis」を開発されている、キタジマさん。実際に、フレームワークを作るってどういう思考なんだろうと思って参加させていただきました。社内でも、オレオレフレームワークを作ろうと思いながら、まったく手を付けれてないので、この機会に考えていかなければ。。。早速、このブログもテーマを「Habakiri」に変更しました！

使いもしない色のバリエーションなし
hoverのスタイルもなし
FLOCSSベース
上書きではなく、付け足す設計（ボタンの事例）

ソースコードも早速ダウンロードさせていただきました。中身見て研究させていただきます。特にSassのファイルやフォルダの構造は人の実装を見ることがないので、非常に興味深いです。FLOCSSをベースにしているとおっしゃってましたので、こちらも再度見ておかなければ。。。

FLOCSSといえば谷さん。谷さんと言えば、書籍（通称メロン本）「Web制作者のためのCSS設計の教科書」がオススメです！

サイン本も持ってますｗこちらも見直さな、、、

LT : アクセシビリティのあれこれ〜まずは、意識することから始めよう〜

キタジマさん以降、自分のLTの準備でそわそわしてましたw

ということで、自分のLTの資料となります。

https://speakerdeck.com/kobatatakayuki/akusesibiriteifalsearekore-mazuha-yi-shi-surukotokarashi-meyou

周りのLT芸人さんに混じって、アクセシビリティのお話をさせていただきました。まぁ、どうなることかと思いましたが。。。あえなく時間切れでちーん。。。いやぁ、、、LT芸人の皆様は心得ていらっしゃる。今回のLTをして学んだのは、5分間のLTにスライドは40枚もいらないということｗまじで、作りすぎたわｗ

肝心の内容の方ですが、、、意識させるにしても、「なぜ、アクセシビリティが必要なのか」を説いていく必要があるんじゃないか？というご意見をいただきましたので、確かにその通りだと。こういうフィードバックは本当にありがたいです。勉強の方法は、その後でどうにでもなると。自分的に、盲目になってた部分もあるので、もう少し掘り下げて伝えれるようにしていきたいと思います。

あと、見積り項目にどう乗せていくか。という話題にもなり、現時点ではシングルAレベルだと、当たり前過ぎて乗せれないという印象（Alt付けるのは当たり前で、わざわざ見積もり項目に載せるレベルじゃないしなぁと感じてますが）を持ってたけど、そこは、対応しているのであれば、項目としては乗せておく（付加価値として）べきなのでは？というご意見もいただきました。

この「対応している」というのが、どのレベルまでなのか、誰が判断して「対応している」といえるのか、など。自称であればいくらでも言えるけど、その信憑性はどこにあるのかっていうのも今後の課題なのかなと思いました。見積もりに載せるとなると難しい。

そういう点で言えば、、、時代工房さんが作られた「A11yc アクセシビリティバリデーションサービス」は使えるな。。。

一緒にLTさせていただいた小渕さんとお話させていただいたんですが、LTでは自己紹介を最後に回すスタイルの人もいるよーと教えていただきました。確かに、最後に回したほうが、話したい内容を伝えれる確率は上がりますね。ということで、自己紹介は最後に回すスタイルで行こうと思います。