Webフロントエンドにまつわるいろいろな話
ネコメシでは週に１回、持ち回り制で勉強会を開催しています。各々が気になっているトピックについてスライドを作って、30分～1時間くらいの発表を行います。
先日の勉強会にて、コーディング作業高速化について発表したので、その内容を公開します。拙速が大事ということで、スライド貼っ付けただけで、説明もなにもなしですが…。
スライドに説明文を追記しました (2019-07-18 22:04)
https://speakerdeck.com/tsmd/devtools-plus-perfectpixeldebao-su-kodeingu
とても個人的な話ですが、ここ最近で自分自身のプライバシー意識の高まりを感じて、ブラウザの設定を見直す機会がありました。見直したのはCookieの設定で、許可したドメインにしかCookieを記憶しないようにしました。設定変更によるある程度の不便は覚悟していました。とはいえ、ま〜せいぜい、初回アクセスの時のモーダルが何度も出るようになるとか、ログインできなくなるとか、そのくらいかなと思っていました。
しかし実際は、悪い意味で期待を裏切られることになりました。
Cookieが無効なだけで、“全く”動かなくなってしまうウェブサイトやウェブアプリが、本当にたくさんあることに気づいたのです。
全く動かなくなってしまう原因は単純（後述）だったのですが、ちょっとした対処で簡単に直せることなのに、サイト全体が一切使い物にならなくなってて、もったいない！！ と思いました。
BEMのいいところは、それが何者なのかが明白ということに尽きる。とある要素を見たときに、そのスタイルがどこに書かれているのか、何を表しているのかがクラス名を見ればわかる。手を入れる際も、どこに追記すればよいのか、どれくらいの影響を及ぼすのかの大部分が推測できる。
レスポンシブ・デザインと相性がいいとか、流行りのコンポーネント指向と相性がいいなど、BEMの良さは他にもいくつか挙げられるけど、決定的なのは明瞭さであると思う。
BEMを使いはじめてかれこれ３，４年くらい経った。その間に色々な命名規則や設計思想が登場してきたけれども、今のところは浮気する程の魅力を他に感じることもなくBEM一筋でやってきている。ただし実践するにつけて、より明瞭で破綻しづらい設計を実現するために、様々な制約やガイドを設けてやってきたので、「もともとのBEM」からは多少なり離れているかもしれない。
ただし、それはBEM的にはオッケーなのである。もともと「正しいBEMの書き方」というものはなく、みんなの中にそれぞれのBEMがある、という捉え方でオッケーなのだということだ（みたいなことが実は公式にも書いてある）。
少し長くなるけれど、私がいつも使っているプラクティスを紹介する。
みなさん、マークアップ好きですか？ 私はまあまあ好きです。デザインされたパーツをHTMLでどう組むかを考えたり、他の開発者と意見を戦わせたりするのは楽しいですよね！
ただ、自分はマークアップ行為そのものについて、「ここにそんな拘る意味あるのかな？」と疑ってしまうことがあります。<dl> を使うか使わないか、とか、パンくずナビはどうマークアップするか、とか、少しでも良いマークアップをするために切磋琢磨するのはきっと楽しいことなのでしょうが、エンジニアとしての自己満足に陥ってはいないだろうか？ と我に返る時があるのですよね。その時の感情を掘り下げてみようと思ったことが、この記事を書くきっかけとなりました。
この記事で私が最終的に述べたいことは、近い将来の標準的なWebプロジェクトにおいて、緻密なマークアップ作業の重要性は極めて低下するだろうということです。なぜ私がそう思うか、妄想を交えつつまとめてみようとおもいます！
なお、筆者は一人のWebエンジニアに過ぎません。これから少し触れる人工知能や機械学習の専門家でなければ、アクセシビリティの専門家というわけでもありません。いーかげんなことを述べているかもしれない点はご承知おきください。
レスポンシブテーブルという言葉をご存知でしょうか。テーブル（表組み）に対してレスポンシブデザインを適用する手法のことです。既存のものとは少し違った手法を考案したので記事を書きました。
株式会社プレートさんが、AUTOCODINGというサービスを開始されました。デザインファイルからコーディングを自動生成してくれるというサービスですが、さわりだけ聞くといかにも眉唾な感じです。ほんまにちゃんと作ってくれるんかいな？ ということで試してみました。
しばらく前からわたしはCSSグリッドシステムに取り憑かれたようになっている。このせいで成仏できないので取り憑く側といったほうが正しいのかもしれないが。
わたしが夢想しているグリッドシステムは以下の要件のもの。
ブラウザデフォルトの select 要素は、いろいろな事情で JavaScript でゼロから実装しないといけない場合はあるにせよ、特に理由がなければそのまま使うことが望ましい。独自に実装したものはどうしても、デフォルトのものよりユーザビリティーやアクセシビリティーの面で劣ってしまう。
とはいえそのまんま使うとデザインにそぐわない場面は少なくないし、デザイナーがゆるさんという場合だってある。見た目を変更しなきゃいけない時はよくある。
UA が提供する見た目があまりにもデザインとマッチしなければ select の見た目を CSS を使って調整することになる。このやり方は最近では一般的になってきていて、Google などでも使われている（路線検索時）など。やり方をググればブログなどがいくつか引っかかる程度にはメジャーだ。が、これらは全部、幅を固定しなければいけないという制約がある。
そういうわけで、幅を可変にしつつ、select の見た目を独自にデザインする方法を探った。
成果物はこちら。
