HTML5 Conference 2018 の登壇資料のまとめです。 資料を発見次第随時アップデートしていきます。 HTML5 Conference 2018 https://events.html5j.org/conference/2018/11/ 2018年11月25日（日） 東京電機大学 千住キャンパス 1号館 タイムテーブル https://events.html5j.org/conference/2018/11/session/ ハッシュタグ 総合: #html5j ホール（2階）: #html5j_h 各ルーム（1階:A-C/2階:D,E）: #html5j_a #html5j_b #html5j_c #html5j_d #html5j_e セッション ZOZOのグローバルECのフロントエンドアーキテクチャ設計 （権守健嗣さん） 光を超えるためのフロントエンドアーキテクチャ （
この記事はGoodpatch Advent Calendar 2018 1日目の記事です。 フロントエンド開発をしているとアニメーションを実装する機会が度々あります。たとえば、私が担当しているモチベーションクラウドでは、以下のように円グラフにアニメーションを加えています。 アニメーションを用いる上で意識したいポイントとして「パフォーマンス」があります。アニメーションのパフォーマンスについて、この記事では主に“滑らかさ”を指すことにします。 昨今ではハードウェアの進歩もあり、あまり意識しなくてもアニメーションのパフォーマンスが問題になることは少ないかもしれませんが、少し複雑なアニメーションやアニメーション以外の要因によってアニメーションの品質劣化が起きる場合には多少のテクニックが必要になってきます。 今回はUIにおいてアニメーションのパフォーマンスが重要とされる背景とWebアニメーションにお
Webページやスマホアプリのレイアウトに使用する、margin, paddingなどのスペースをCSSで効率的に定義する方法を紹介します。 em, remの相対的な単位を使い、calc()を効果的に活用し、拡張性やメンテナンス性にも優れたデザインシステムを構築できます。 Create your design system, part 4: Spacing by CodyHouse 下記は各ポイントを意訳したものです。 ※当ブログでの翻訳記事は、元サイト様にライセンスを得て翻訳しています。 はじめに CSSの変数を使用して、スペースのシステムを設定する方法 すべてのコンポーネントにデフォルトのpaddingを設定する方法 marginのユーティリティ スペース値を追加する場合 固定のスペース値が必要な場合 スペースを定義したSCSSファイル はじめに 元々は、近日公開予定の「Web Comp
Predictable 予測しやすい Reusable 再利用しやすい Maintainable 保守しやすい Scalable 拡張しやすい 参考：https://philipwalton.com/articles/css-architecture/ CSS設計の必要性 コスト削減 実装者の単価を減らせる 実装工数を減らせる 既存のコンポーネントを使うことで工数を減らせる デグレが起きる確率が減り改修工数を減らせる 部分的な改修を行うことで並行して実装ができる 観測した限りのCSS設計 OOCSS オブジェクト指向 Bootstrap BEM（MindBEMding） シングルクラスにする命名規則 SMACSS OOCSSやBEMなどから影響を受けている Base、Layout、Module、State、Themeのカテゴリーから構成される MCSS（Multilayer CSS） OO
なぜこの記事を書こうと思ったか 配属されてからは、業務でCSSを書くといったら、Bootstrapのclass名を付与したり、機能追加の際にちょっと書くといったことだったのですが、大幅にサービス全体のCSSを見直さなきゃいけない機会があったので、どんなことを考えたのか書いておきます。 CSSのリファクタリングや再設計は工数がかかる上に、そこまで対価がない結構辛いことだと思います。また運用していて数年が経てば大体の場合がCSS設計は崩壊していきます...。 特に途中で気づいた、最初に決めておけばよかったということも多々あったので参考になればと思います。 前提条件 下記のような時に、この記事は役に立つのではと思って書いてます。 すでにあるWebサービスの大幅なデザイン改修がある 新しくCSSを書かなきゃいけないページが5ページ以上ある 既存のCSS設計を見なさなきゃいけない（CSSファイルが6
Web制作会社、フリーランスを経て、株式会社ピクセルグリッドに入社。数多くのWebサイト、WebアプリケーションのHTML、CSS、JavaScript実装に携わってきた。受託案件を中心にフロント周りの実装、設計、テクニカルディレクションを行う。スケーラビリティを考慮したHTMLテンプレート設計・実装、JavaScriptを使った込み入ったUIの設計・実装を得意分野とする。 著書に『改訂版 Webデザイナーのための jQuery入門』（技術評論社、2014年11月14日）がある。 CSS Nite 2011ベストセッションにおいて、全170セッションの中から、ベスト10セッションに、CSS Nite 2013ベストセッションでは、全278セッション中、ベスト20セッションに選出。
CSSをちょっと書けば、こんなレイアウトが出来てしまいます！ 当記事では、こんなレイアウトを可能にする CSS Grid Layout の解説をしていきます。 尚、CSS Grid Layout は現時点（2017年4月）ではまだ新しいモジュールのため、対応ブラウザが少ないです。 （Fx52～、GC57～、Safari10.1～、Opera44～ など） Can I use... CSS Grid Layout しかし、2017年3月にはFirefox, Google Chrome, Opera, Safari などが CSS Grid Layout 対応のバージョンをリリースしており、今後に対応ブラウザが急増するのは確実なので、ぜひともマスターしておきたいです。 この記事は4部構成の中の 基礎編 です。 CSS Grid Layout を極める！（基礎編） ←これ CSS Grid La
Solved with CSS! Logical Styling Based on the Number of Given Elements Did you know that CSS is Turing complete? Did you know that you can use it to do some pretty serious logical styling? Well you can! You don’t have to set all of your logic-based styling rules in JavaScript, or even have to use JavaScript to set classes you are styling against. In many cases, CSS can handle that itself. I’m stil
ヘッダでロゴを左寄せにしたり、検索窓を右寄せにしたり、画像をページの中央に配置したり、ページ上のあらゆる要素を揃え整列させるFlexboxをベースにしたスタイルシートのスニペットを紹介します。 サイトやブログの全体で利用できるユーティリティのclassとして、保存しておくと便利なスニペット集です。 Speed up alignment in CSS with Flexbox utility classes by CodyHouse 下記は各ポイントを意訳したものです。 ※当ブログでの翻訳記事は、元サイト様にライセンスを得て翻訳しています。 CSSで面倒なのは要素を整列させること Flexbox以前 Flexboxで簡単に CSSで面倒なのは要素を整列させること CSSで面倒なのは、要素を整列させることでした。しかし、Flexboxが登場して、理にかなった方法で整列させることが可能になりまし
たぶん1000回くらいは言われてきているがいまだに絶滅しないので、もう1回言う。ファイル名でもソースコード上の変数でもCSSのセレクタでもなんでもいいけど、相対的なネーミングはやめよう。 Safe Harbor Statement この投稿は個人の（中略）であり、所属する組織とは関係ありません。 なぜ相対的なネーミングをしてはいけないか 名前をつけた人の主観が入り込むため 時間が経つにつれ名前が実態と乖離し混乱を招くため 実装に無駄な制約をかけるため なぜ相対的なネーミングがなくならないか なにが相対的なネーミングなのか理解していないため じゃないかな多分。 避けるべき語 というわけで相対的なネーミングを回避するための禁止ワードのうち代表的なものをあげておきます。 new, 新, latest, 最新, old, 旧 など これらの時系列を表す語は、比較対象がないと新なのか旧なのかわかりま
各CSS設計を、自社のサービスに取り入れる場合どんなメリット・デメリットがあるんだろう、と思って調べたので個人的なメリット・デメリットを含めてまとめました。 ちなみに弊社はSMACSSを採用していたのですが、思った以上に「似ているけれども少し違うため使い回せないパーツ」と「内容に依存するパーツ」が多かったので、そのあたり上手くクリアできる設計手法無いかなと思って探しました。 一覧 OOCSS BEM SMACSS FLOCSS ECSS MCSS OOCSS 特徴 オブジェクト指向 マルチクラス 構造とスキン（見た目）を分離する コンテナと内容を分離する メリット 構造と見た目を分離することにより、パーツの使い回しがしやすい （例：btnとbtn-submitを組み合わせて投稿ボタン作るとか） コンテナと内容を分離するので、作ったパーツをどこでも使える。場所に依存しない。 デメリット 初見
レスポンシブデザインは あくまで見た目の調整、表示・非表示のコントロールなので 下手に使うと、デバイス毎にインタラクションが違うUIのstateが無茶苦茶複雑になっていく コンポーネントという概念が無かった時代の設計を、SPAに持ってくるのはおかしい 画面サイズ毎にCSSで手軽にを切り替える、というのなら良い しかし、画面サイズ毎にインタラクションが違う部品が出てくると設計が破綻する 画面サイズ毎のがごちゃ混ぜになる コードが追えなくなり、バグの温床になる では、どうするか？ 素直に画面サイズ毎、デバイス毎、あるいはインタラクション毎のReactコンポーネントを書けばいい 使いまわせる部品は、コンポーネントとして切り出して再利用する 歴史を紐解く 2011年頃、レスポンシブデザインが生まれた 当時のwebにはコンポーネントが存在しなかった 単体で複雑な状態遷移をするインタラクティブなパーツ
日本語で「CSS設計」を検索すると、記事やつぶやきなどでセレクタの命名規則に関する話題が多いです。 CSSを設計する上で、命名規則は重要な要素でしょう。 簡単なセレクタ名だと他のスタイルと重複する可能性もあります。他のスタイルと重複しないようにセレクタの子孫数を増やしてしまうと、今度はスタイルの取り回しが悪くなります。 またデザインをコンポーネントに分ける粒度について紹介されていますが、命名規則の分け方のように紹介されているよう感じます。 論理的に構造をわけて命名していくため、覚えやすく、伝えやすさもあわさって、現在の「CSS設計 = 命名規則」のような構図ができあがったと感じています。 CSS設計は命名規則だけか 命名規則はCSS設計において、重要な要素です。 しかしCSSは命名規則させ気を付ければ良い、というものではありません。 私は、すでにあるサイトの一部のコンテンツの作成やすでに用
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
