ウェブデザインにおけるline-heightってけっこう曲者で、CSSを理解してデザインしないと「空き」の設計が破綻したりコーディングで苦労することになります。FigmaやAdobe XD、Affinity Designerなどのグラフィックアプリでline heightの扱いが異なるので、使うツールの挙動を理解するのも大切です。 ということで、今回はCSSのline-heightについてまとめてみます。 実は調べれば調べるほど奥が深いCSSのline-heightの世界ですが、まずは基礎からまとめていこうと思います。 目次 以下はページ内のセクションへのリンクです。 CSSのline-heightでは文字の上下にスペースができる ウェブで使われるハーフ・レディングとは 印刷とウェブにおけるレディングの違い デザインツールでのline heightの扱いの違い 上下のハーフ・レディングを帳

12月9日（月）に開催されたAffinity User Gruop JAPANミーティング #3 で「ウェブ制作に役立つAffinity Designerの使い方と注意点」という内容でお話しをしてきました。当日お話しした内容に少し情報を追加してこのブログでもご紹介します。 目次 以下はページ内のセクションへのリンクです。 動画版もあります はじめに アジェンダ Affinityツールを好きな理由 フル機能iPad版もある、プロ向け本格ツール Affinity Designerが一番好き！ Affinityツールに向いているプロジェクト こんなふうに使ってます Affinityスイートの抜群の互換性 ウェブ制作に役立つ便利な使い方 複数解像度の画像書き出し機能 違う種類の画像の書き出し 書き出すスライスの追加方法 アセットとシンボル機能 レスポンシブ・デザインに便利な「制約」機能 アートボー

先月末、藤井さん の働く株式会社ザッパラスさん にお邪魔して、レスポンシブWebデザインの基本のキ的なお話しをさせていただきました。 題して「もう、レスポンシブでいいんじゃない？」 いま、改めてレスポンシブWebデザインについて考えるきっかけになれば、という視点で内容をまとめてみました。 4年前に「レスポンシブWebデザイン 制作の実践的ワークフローとテクニック 」という本を執筆したんですけど、そのころからウェブ制作のデフォルトはとりあえずレスポンシブでいいんじゃない？と思っていたのですが、最近、その思いがより強くなっています。職場のウェブサイトをレスポンシブでリニューアルしてから約5年が経ちますが、やっぱり、あの時レスポンシブを選択しておいてよかったとつくづく感じています。おかげで、Googleさんがモバイルインデックスを優先するという昨今のニュース にもあまり翻弄されなくてすんでいます

Flexboxの仕様って勧告に至ってないけど使っていいの？迷ったのでW3Cの仕様策定プロセスを読んでみた この記事の公開時（2016年2月21日）の時点で、Flexboxの仕様のステータスは「W3C Last Call Working Draft 」で、プロセスの第一段階の草案の次のステップでW3Cの承認・推奨を得ていない状態です。このステータスで、これから数年使いたい基盤となるフレームワークなどにFlexboxを使っていいのか？ちょっと迷うところです。 ブラウザサポート は充実してきてますし、Foundation 6 やBootstrap 4（β2 α版） などの主要フレームワークでも採用され始めているし、よっぽどのことがない限り問題はなさそうです。でも、仕様のステータスはちょっと気になります。 そこで、そもそもW3Cの仕様策定プロセス（Development Process）がどんなも

スマホからウェブにアクセスするユーザが増え、ウェブサイトの表示速度の高速化がより重要な制作の課題になっています。1ページもののサイトなら、フロントエンド・エンジニアが一人で実装できるかもしれませんが、ある程度の規模のウェブサイトではワークフローやサイト全体の設計にも関わってきます。また、表示速度の高速化の方法を知らなければ、最適化しやすい、より高度なデザインは実現できないでしょう。エンジニアだけでなく、デザイナーやディレクターがこういった情報を知っていれば、よりスムーズに結果を出せるウェブサイト制作ができるはずです。 ページ表示速度の改善にはいろいろな方法がありますが、この記事では一番効果がありそうなところから攻めていきたいと思います。自分もまだまだ勉強中なので、まずはfilament groupのScottさんの記事 やClearleftのJeremyさんの記事 を参考に、フロントエンド

画像表示のマルチデバイス対応をHTMLとCSSのみで実現できる「レスポンシブ・イメージ」ですが、効果的な使い方をするには、いくつか注意点があります。プロダクション・サイトで使えるようになるまでにはもう少し時間がかかりそうですが、基礎と注意点くらいは今から覚えておいても良さそうです。 Cloud Fourというアメリカの制作会社のブログ で、<picture>要素の使い方について注意を促していて、とても重要な情報だと思ったのでこちらでもシェアします。先日書いたレスポンシブ・イメージとPicturefill 2のまとめとあわせて、近い将来、レスポンシブ・イメージ実装の参考になれば幸いです。 まずは推奨の記述方法から レスポンシブ・イメージ実装の際に推奨されるHTMLの記述方法は以下のとおりです： とりあえず、これだけ覚えておけば、細かいところはこの記事をはてブ しておいて、使う時にもう一度見な

先日このブログのデザインをリニューアルしたときに、メディアクエリの記述が結構手間だったので、記述のしやすさ、メンテナンス性の良さ、また、最終的なCSSファイルの最適化の3つの観点から、便利な書き方と最適化の方法をまとめてみました。 目次 モバイル・ファーストCSSで書く 要素ごとに、Sassを使って記述する Gulpを使ってメディアクエリの整理する まとめ モバイル・ファーストCSSで書く メンテナンス性の良さや重複の少ないよりシンプルなCSSの記述を目指すと、モバイル・ファーストCSSで書くのが良いです。デスクトップ・ファーストCSSで書く場合、小さい画面向けにはスタイルを追加するというより、消していく（または、上書きして帳消しにする）作業が多くなってしまいます。 このブログはモバイルからのアクセスが1割程度なので、今回のデザインのリニューアルでは、

先日、僕の恩師のウェブ制作会社で開催された勉強会で「レスポンシブWebデザインのワークフロー」についてお話させていただいたんですが、その際に「意思決定層との密なコミュニケーションをとり、スムーズに開発を進めていくために、苦労した点や工夫した点」について質問をいただきました。その回答をまとめたので、このブログでも共有したいと思います。今回まとめたものはレスポンシブWebデザインでの制作に特化した内容ではないですが、以下に挙げるようなWebディレクターとしての基礎知識やスキルが、レスポンシブWebデザインのような柔軟な対応を強いられる制作では大切になると感じています。 Question: 意思決定層との密なコミュニケーションをとり、スムーズに開発を進めていくために、苦労した点や工夫した点を教えてください。 Answer: どれもディレクターとして基本的な内容になりますが、僕は以下のようなことを

ピクセル密度とピクセル比の関係 ピクセル密度は、数が多ければ多いほどスクリーン上で鮮明な描画ができるわけですが、上述したピクセル比とは直接関連しないものです（と考えています）。たとえば、Galaxy S IVのようにピクセル密度は441ppi、ピクセル比は2という端末もあれば、HTC Oneのように、ピクセル密度は468ppiだが、ピクセル比は3という端末もあります。 ※両方とも実機で検証したわけではないので、Wikipediaの情報が正しければの話ですが。 ※ピクセル比とは違うものですが、それと似た単位であるdppx (dots per pixel unit)では、CSSで定義された1インチが96pxになるため、1dppx = 96dpiになります。 ピクセル比に似た値「dp」とwindow.devicePixelRatio Androidの密度非依存ピクセル「dp」 Density-i

これはありがたい！と思えるSass/Compassに関するスライドが2つほどSlideshareにアップされていたので、このブログでも紹介させていただきます。去年行われたHTML5 Conference 2012でNHN Japanのマークアップエンジニアの方から発表されたもので、すでにSassを使ってCSS運用を始めている方からの貴重な情報です。 前編、後編とあるので、それぞれに対して自分なりに重要だと思ったこと、また、それらに対する考察をまとめてみました。自分が管理・運営しているウェブサイトのCSS管理も、Sass/Compassを使ってやりたいなぁと思う今日このごろです。時間的な初期投資は必要だけど、長期的に考えたらメリットも多く時間の節約にもなりそうです。 今回の投稿では、まずは前編から。 前編で気になったところのまとめ 「実践Sass 前編 — HTML5 Conference

レスポンシブWebデザインを実装する際、画像の扱いは一つの課題として残っています。現在、PHPを使用した「Adaptive Images」やJavaScriptを使った「Responsive-Images」などが現実的な対応策としてありますが、どちらもApacheの設定を必要とします。レスポンシブWebデザインが広まって標準的な実装方法の一つになろうとしている今、サーバサイド技術に依存しない解決策が早急に求められています。 そんな中、HTMLの仕様策定の一端を担うWHATWG（Web Hypertext Application Technology Working Group – ワットダブルジーと読む）で、新たな仕様が検討されています。 では、どんな議論がされていて、今どんな状況なのか？ なかなか複雑なことになっているようなので、調べてまとめてみました。 ※この記事は、レスポンシブWeb

デザイン要素を固定しないリキッドレイアウトは、未知の端末にも対応するというコンセプトのもとに実装するレスポンシブウェブデザインには必須だと考えています。そのリキッドレイアウトを実装する際に理解しておきたいのが、パーセント値で幅や高さを指定した際に小数点以下になるピクセル値（10.5pxとか9.2pxなど）に対するブラウザの挙動です。 たとえばグリッドシステムを構築する際、計算上はあっているのにブラウザでは思った通りに表示されないといったことが起こります。これは、各ブラウザのサブピクセル（小数点以下のピクセル値）の扱いの挙動差により生まれます。 まずはパーセント指定の基本から まずは前提となるパーセント指定の際の計算の基本のおさらいから。。。 CSSでパーセント値を使って幅や高さ指定をすると、指定した要素を含む親要素をベースにピクセル値が計算されます。 たとえば100pxの親要素の中にある子

いつもためになるツールや手法を紹介しているコリスさんでも紹介されていた「CSS3 PIE」がすごく良い感じだったのでご紹介。 このPIE、Progressive Internet Explorerの略で、Internet Explorer 6、7、8でサポートされていないborder-radiusやbox-shadowなどのCSS3の機能を実現するためのスクリプトです。シンプルかつCSS3の仕様に準拠した指定方法で実装できるところがすごく良い感じです。 FirefoxをはじめSafariやChromeなどのモダンブラウザの最新版ではCSS3のサポートが充実しているので、それを活用しない手はない。が、ターゲットとするユーザ層によってはIEが大きな足かせとなる。 それをシンプルに解決してくれるのが、この「CSS3 PIE」です。 ※僕が担当しているウェブサイトはなぜかIE6が無視できないシェア