モーダルダイアログのようなUIには、それが出現している間はダイアログの外の領域が操作不能になっているという慣習があります。ダイアログが取り扱うタスクだけにユーザーを集中させるために、あえてダイアログ以外の操作ができないようになっています。 またモーダルダイアログをはじめとしてディスクロージャーなど、ユーザーの操作に応じて表示と非表示が切り替わるUIもあります。こうしたUIは視覚的には隠れているようでも、実装としては、つねにDOM上に存在しているHTML要素の属性だけを書き換えてレンダリング結果を制御するのが一般的です。 こうしたケースでは、特定の領域を操作できないように実装を行う必要があります。CSSでdisplay:noneかvisibility:hiddenが指定されたHTML要素はそれだけで操作できない状態になりますが、それ以外の方法で非表示になったHTML要素は、利用状況によっては

ここ数年で、「デザインシステム」はウェブ開発やデザインのコミュニティでとても人気の話題になりました。そして「コンポーネント」として定義される一連のデザイン成果物を開発・メンテナンスするために、StyleguidistやStorybookといったツールが多くのプロジェクトで一般的に使われています。このプロセスはデザインシステムという概念の一部として、コンポーネント駆動開発（Component Driven Development）と定義することができるでしょう。 さて、コンポーネント駆動開発にまつわる資料のほとんどは、ReactやVue、Angularといった、フロントエンドのビューのためのメジャーなライブラリを利用することについてのものです。しかしもっとトラディショナルな技術スタックの場合はどうすればいいでしょう？ 例えば私たちスタンダードデザインユニットでは、静的なHTMLとCSSのアセ

Sassに新しいモジュールシステムが導入されます。具体的には@useと@forwardという2つのルールが登場し、@importルールは将来的に廃止される予定です。現在、Sassのおもな実装としてDart SassとLibSassがありますが、まずDart Sassへの実装が進んでいて、今年10月に安定版がリリースされる予定です。この新しいモジュールシステムを簡単に紹介したいと思います。 なお、ここで言うSassの「モジュール」とは、メンバー（変数、関数、ミックスイン）のコレクションを指し、具体的にはSassのソースファイルのことです。 背景 新しいモジュールシステムが開発された背景として、@importルールがかかえる多くの問題があります。ファイルスコープがないため依存モジュールの把握が困難になったり、名前空間を持たないためにライブラリの作者と利用者が命名を工夫しないといけなかったり、と

デザインカンプを基に実装する難しさはあらゆる場面で語られます。私の場合は特にレスポンシブデザインに関する仕様の解釈に悩む場面が頻繁にあります。 その問題点はどこにあるのでしょうか。私の制作したツールの紹介を通して、グリッドシステムのあり方やレスポンシブデザインの意味などを考察しました。 デザインカンプとワークフローの関係性 ウェブサイト制作のワークフローでは、クライアントとの上流での合意形成と開発者への指示書との役割をデザインカンプが兼ねるパターンがよくあります。デザイナーはウェブページの実装仕様を決定しながらデザインカンプを制作し、開発者はデザインカンプを通して前工程での決定を読み取りながら実装します。 デザインカンプを基に実装する難しさの一因は、それがシステムが取り得る状態のうちの一場面を切り取った単なるスナップショットでしかない構造です。 仕様を理解するためには、デザイナーが想定する