DevTools+PerfectPixelで爆速コーディング

ネコメシでは週に1回、持ち回り制で勉強会を開催しています。各々が気になっているトピックについてスライドを作って、30分~1時間くらいの発表を行います。

先日の勉強会にて、コーディング作業高速化について発表したので、その内容を公開します。拙速が大事ということで、スライド貼っ付けただけで、説明もなにもなしですが…。

スライドに説明文を追記しました (2019-07-18 22:04)

スライド

https://speakerdeck.com/tsmd/devtools-plus-perfectpixeldebao-su-kodeingu

もっと読む

フロントエンドの「想定外」に対応する考え方とTipsいくつか

とても個人的な話ですが、ここ最近で自分自身のプライバシー意識の高まりを感じて、ブラウザの設定を見直す機会がありました。見直したのはCookieの設定で、許可したドメインにしかCookieを記憶しないようにしました。設定変更によるある程度の不便は覚悟していました。とはいえ、ま〜せいぜい、初回アクセスの時のモーダルが何度も出るようになるとか、ログインできなくなるとか、そのくらいかなと思っていました。

しかし実際は、悪い意味で期待を裏切られることになりました。

Cookieが無効なだけで、“全く”動かなくなってしまうウェブサイトやウェブアプリが、本当にたくさんあることに気づいたのです。

全く動かなくなってしまう原因は単純(後述)だったのですが、ちょっとした対処で簡単に直せることなのに、サイト全体が一切使い物にならなくなってて、もったいない!! と思いました。

もっと読む

細かすぎるけど伝わってほしい私的BEMプラクティス30(ぐらい)

BEMのいいところは、それが何者なのかが明白ということに尽きる。とある要素を見たときに、そのスタイルがどこに書かれているのか、何を表しているのかがクラス名を見ればわかる。手を入れる際も、どこに追記すればよいのか、どれくらいの影響を及ぼすのかの大部分が推測できる。

レスポンシブ・デザインと相性がいいとか、流行りのコンポーネント指向と相性がいいなど、BEMの良さは他にもいくつか挙げられるけど、決定的なのは明瞭さであると思う。

BEMを使いはじめてかれこれ3,4年くらい経った。その間に色々な命名規則や設計思想が登場してきたけれども、今のところは浮気する程の魅力を他に感じることもなくBEM一筋でやってきている。ただし実践するにつけて、より明瞭で破綻しづらい設計を実現するために、様々な制約やガイドを設けてやってきたので、「もともとのBEM」からは多少なり離れているかもしれない。

ただし、それはBEM的にはオッケーなのである。もともと「正しいBEMの書き方」というものはなく、みんなの中にそれぞれのBEMがある、という捉え方でオッケーなのだということだ(みたいなことが実は公式にも書いてある)。

少し長くなるけれど、私がいつも使っているプラクティスを紹介する。

もっと読む

絵文字😇を含むテキストを表示する @font-face 設定(Unicode 10.0対応版)

CSSで絵文字を表示するための @font-face 設定を紹介します。この方法はモダンな閲覧環境ではほぼ問題なく表示できます。またJavaScriptを使用して絵文字を画像に置換するタイプ(EmojiOneTwemoji)と比較して、表示速度や利便性などの面で大きく有利です。

絵文字を含むテキストを表示する @font-face 設定(Unicode 10.0対応版)

デモページもご覧ください。

以下のCSSを指定すると絵文字がきれいに表示されます。
もっと読む

マークアップのいらない未来を考える

みなさん、マークアップ好きですか? 私はまあまあ好きです。デザインされたパーツをHTMLでどう組むかを考えたり、他の開発者と意見を戦わせたりするのは楽しいですよね!

ただ、自分はマークアップ行為そのものについて、「ここにそんな拘る意味あるのかな?」と疑ってしまうことがあります。<dl> を使うか使わないか、とか、パンくずナビはどうマークアップするか、とか、少しでも良いマークアップをするために切磋琢磨するのはきっと楽しいことなのでしょうが、エンジニアとしての自己満足に陥ってはいないだろうか? と我に返る時があるのですよね。その時の感情を掘り下げてみようと思ったことが、この記事を書くきっかけとなりました。

この記事で私が最終的に述べたいことは、近い将来の標準的なWebプロジェクトにおいて、緻密なマークアップ作業の重要性は極めて低下するだろうということです。なぜ私がそう思うか、妄想を交えつつまとめてみようとおもいます!

なお、筆者は一人のWebエンジニアに過ぎません。これから少し触れる人工知能や機械学習の専門家でなければ、アクセシビリティの専門家というわけでもありません。いーかげんなことを述べているかもしれない点はご承知おきください。

もっと読む

デザインPSDからコーディングHTMLを自動生成してくれるサービスAUTOCODINGを使ってみた

株式会社プレートさんが、AUTOCODINGというサービスを開始されました。デザインファイルからコーディングを自動生成してくれるというサービスですが、さわりだけ聞くといかにも眉唾な感じです。ほんまにちゃんと作ってくれるんかいな? ということで試してみました。

もっと読む

あと一歩のところでうまくいかないCSSグリッドシステム

しばらく前からわたしはCSSグリッドシステムに取り憑かれたようになっている。このせいで成仏できないので取り憑く側といったほうが正しいのかもしれないが。

わたしが夢想しているグリッドシステムは以下の要件のもの。

  • HTMLとCSSだけで動く。JavaScriptに依存しない
  • リキッドレイアウトである
  • 行ごとに要素で囲む必要がない
  • グリッドの内容は、%指定でフレキシブルにすることもできるし、固定サイズにしておき領域幅をオーバーしたら改行するようにもできる
  • 使用があやういハックは使いたくない
  • IE8以上に対応する

もっと読む

select を JS と CSS で独自にデザインする方法(幅可変版)

ブラウザデフォルトの select 要素は、いろいろな事情で JavaScript でゼロから実装しないといけない場合はあるにせよ、特に理由がなければそのまま使うことが望ましい。独自に実装したものはどうしても、デフォルトのものよりユーザビリティーやアクセシビリティーの面で劣ってしまう。

とはいえそのまんま使うとデザインにそぐわない場面は少なくないし、デザイナーがゆるさんという場合だってある。見た目を変更しなきゃいけない時はよくある。

UA が提供する見た目があまりにもデザインとマッチしなければ select の見た目を CSS を使って調整することになる。このやり方は最近では一般的になってきていて、Google などでも使われている(路線検索時)など。やり方をググればブログなどがいくつか引っかかる程度にはメジャーだ。が、これらは全部、幅を固定しなければいけないという制約がある。

そういうわけで、幅を可変にしつつ、select の見た目を独自にデザインする方法を探った。

成果物はこちら。

もっと読む