ウェブデザインにおけるline-heightについて
ウェブデザインにおけるline-heightってけっこう曲者で、CSSを理解してデザインしないと「空き」の設計が破綻したりコーディングで苦労することになります。FigmaやAdobe XD、Affinity Designerなどのグラフィックアプリでline heightの扱いが異なるので、使うツールの挙動を理解するのも大切です。 ということで、今回はCSSのline-heightについてまとめてみます。 実は調べれば調べるほど奥が深いCSSのline-heightの世界ですが、まずは基礎からまとめていこうと思います。 目次 以下はページ内のセクションへのリンクです。 CSSのline-heightでは文字の上下にスペースができる ウェブで使われるハーフ・レディングとは 印刷とウェブにおけるレディングの違い デザインツールでのline heightの扱いの違い 上下のハーフ・レディングを帳
SVG背景画像でwidthとheight属性が100%だとIE11で中央寄せになってしまうバグ
先日、予想外のところでIE11のバグ（現象？）に出くわしたのでメモしておきます。 svgタグのwidthとheight属性に100%が指定されたSVGをCSSで背景画像に指定すると、IE11だけ配置の指定を無視して中央寄せになってしまうバグです。このバグは背景を指定する領域のアスペクト比がSVGのそれと異なる場合に表面化します（アスペクト比が同じ場合、バグに気づきません）。 ※SVG伝道師の松田さんが「一概にバグではないと思う」とツィート されていたので参考までに仕様へのリンクを記事の最後に追記しておきました。 バグが発生する条件とデモ 実際の表示はデモページでご覧ください。IE11で見ると一番最初の三日月だけ、中央寄せになってしまっています。 デモはこちら このバグはSVGとCSSで以下のサンプルコードのような指定をすると発生します。 SVG 下の画像のようにサイズが132 x 160p
Webアクセシビリティの「はじめの一歩」をスクリーンリーダーの使い方を覚えることにしてはどうだろう？
突然ですが、スクリーンリーダーって使ったことありますか？ ちょっと疑問に思ったので、Twitterでウェブ制作に関わる方々（デザイナー、エンジニア、ディレクターなど）に「iOSやAndroidの読み上げ機能って使えますか？」という質問をしてみた ら、実に87%の方が「使えない（試したことはある）（13%）」「試したことない（74%）」ということでした。 ウェブ制作に関わる方々（デザイナー、エンジニア、ディレクターなど）に質問です！？ iOSやAndroidの読み上げ機能って使えますか？ — ryo watanabe | 渡辺竜 (@rriver) May 7, 2018 ※アンケートにご協力いただいた方々、本当にありがとうございました！ 100件の回答なので、これを「ウェブ制作者全般」と見るのは微妙ですけど、このアンケートの回答を見る限りではウェブ制作に関わる方々でもスクリーンリーダーはあ
FirefoxのCSS Gridインスペクターが便利！
CSS Gridのデバグに便利なFirefoxのCSS Gridインスペクターをご紹介します。Firefox 56から搭載 されているこのインスペクターを使うと以下のグリッド関連の情報が表示できます。CSS GridするならFirefoxがいいですね。 グリッドをオーバーレイ表示 線番号を表示 領域名を表示 グリッド線を無限に延伸 各グリッドの詳細を表示 開発ツールを表示する まずはメニューの「ツール > ウェブ開発 > 開発ツールを表示」から開発ツールを表示します。 グリッドをオーバーレイ表示 グリッドの親要素を選択すると、「ルール」タブのCSSのところに小さくグリッド・アイコンが表示されます。このアイコンをクリックするとグリッドのオーバーレイが表示されます。 FirefoxのCSS Gridインスペクターの機能はこれだけだと思っていたんですが、他にもありました！ 「レイアウト」タブ 開
CSS Gridとアクセシビリティについて気になっていたこと
前回の記事でCSS Gridは「魔法の杖」だと書きましたけど、1つ気になっていたことがあります。 それは、HTMLソースの順番（ソースオーダー）と視覚的な順番（ビジュアルオーダー）にまつわるアクセシビリティについてです。FlexboxでもそうなんですがCSS Gridを使うとCSSで表示順を変更することができます。そうするとHTMLソースにあるコンテンツの順番とブラウザで表示される順番が異なる場合が出てくるわけですね。 「でも、それってアクセシビリティ的にはどうなんだろう？」というのが気になっていました。 マルチデバイス対応のレイアウトを考える際、CSSで表示順を変えられるのはものすごく便利で、まさにここがCSS Gridの「魔法の杖」的な要素の一つでもあるわけです。でも、技術的にできるからといって考えなしにやっていいかというと、そんなことはないですよね。 調べてみたところ、CSS Gri
CSS Gridでレイアウトやフレームワークの考え方・作り方が変わる
最近、ようやくCSS Gridを学びはじめてるんですけど、学ぶ課程で「CSS Gridが”普及”するとBootstrap や Foundtion のようなフレームワークの作り方も変わるんだろうなぁ」と考えています。 どう変わるのかというと、まずは： 基本的にレイアウトはCSS Grid（必要に応じてflexbox）でやるようになる コンポーネントはいままでのフレームワークと基本的には同じだけど、CSS Gridに入れ込みやすい設計に変わる もう少し詳しく書くと： Bootstrapなどで採用されているグリッド・システムが必要なくなる 少なくともrowとcol-4、col-md-6のような書き方はなくなる 独自のグリッド・システムで作っていたレイアウトはCSS Gridでやるようになる つまり、HTMLにクラスを記述してHTMLでレイアウトを組むのではなくCSSでレイアウトするようになる（あ
レスポンシブに対応できてCSSでデザインを柔軟に変更できるスライダー「Slider Pro」がなかなかいい
ウェブ制作をしてるとスライダーやカルーセルってなにかと必要になるので、レスポンシブやタッチ操作などに対応できて、CSSで柔軟にデザインをカスタマイズできるスライダーのプラグインをいつも探しています。 過去に試したものでいくつかいいのはあるんですけど「帯に短し襷に長し」的なところが必ずあって、すべての要望を満たしてくれるやつには出会えていませんでした。自分でゼロから作るのもあれですし。利用できるものは利用したい。 で、やっと「これなら！」というやつに出会いました。 Slider ProというjQueryのプラグインです。なかなか良さそうです。 ただ、使ってみてハマったところがいくつかあったので書き残しておきたいと思います。 「jQuery オワコン 」がうたわれる昨今ではありますが、今後、Slider Proを使ってスライダーやカルーセルを実装する方の参考になれば幸いです。 Slider P
もう、レスポンシブでいいんじゃない？
先月末、藤井さん の働く株式会社ザッパラスさん にお邪魔して、レスポンシブWebデザインの基本のキ的なお話しをさせていただきました。 題して「もう、レスポンシブでいいんじゃない？」 いま、改めてレスポンシブWebデザインについて考えるきっかけになれば、という視点で内容をまとめてみました。 4年前に「レスポンシブWebデザイン 制作の実践的ワークフローとテクニック 」という本を執筆したんですけど、そのころからウェブ制作のデフォルトはとりあえずレスポンシブでいいんじゃない？と思っていたのですが、最近、その思いがより強くなっています。職場のウェブサイトをレスポンシブでリニューアルしてから約5年が経ちますが、やっぱり、あの時レスポンシブを選択しておいてよかったとつくづく感じています。おかげで、Googleさんがモバイルインデックスを優先するという昨今のニュース にもあまり翻弄されなくてすんでいます
面倒なレスポンシブイメージの画像作成を自動化してくれる神ツールとブレイクポイントの考え方
レスポンシブイメージ、使ってますか？ ウェブサイトの表示パフォーマンスの最適化をする際に、一番手っ取り早いのが画像の最適化です。そこで、イメージオプティム とかMac Automatorとpngquantなどのツールを駆使して一生懸命に画像自体を最適化したりレスポンシブイメージを使って画像を出し分けたりするわけですけども、特にレスポンシブイメージは手動でやるのは正直言ってかなり面倒です。 そ・こ・で！ 本日ご紹介したいのが「Responsive Image Breakpoints Generator 」です。このツールを使えばレスポンシブイメージの複数画像の作成やHTMLの記述を自動化できて、しかも！アートディレクションまで自動化できるんです。 ということで、今回はレスポンシブイメージについての簡単なおさらいと、画像作成の基本的な考え方、それから自動化について書いてみます。 では、行ってみ
Appleウェブサイトのレスポンシブなナビゲーションが「うまい！」と思う4つの理由
こんにちは。Appleも好きだけどAppleウェブサイトも大好きなRriverの渡辺です。 最近レスポンシブなナビゲーションについて考えていて良いアイディアを探しているんですが、結局Appleのウェブサイトにたどり着きました。Appleのウェブサイトは良く出来ていると思うところがたくさんあって、ナビゲーションも良く考えて作られているんですね。 ということで、今回はAppleウェブサイトのナビゲーションの検証を通して、マルチデバイス時代のレスポンシブなナビゲーションについて考えてみたいと思います。より良いナビゲーション構築の参考になれば幸いです！ 目次 マルチデバイス時代のナビゲーション 理由1： 3段階の「ナビゲーション」で確実にユーザを誘導している 理由2： 見せられるときは、しっかり見せている 理由3： コンテンツ内の「さらに詳しい」コンテンツの見せ方が絶妙 理由4： その時必要なナビ
Node.jsとnpmをアップデートする方法
いつも忘れてしまうので書き留めておきます。macOS Monterey（12.4）で確認をして内容を更新しました。この記事で紹介しているツール「n」もv8.2.0になりました！ Node.jsのアップデート n という便利なバージョン管理ツールがあるので、これを使ってバージョンを確認してアップデートします。nの詳しい使い方はこちらの記事 あたりをご参照いただくと良いと思います。n を使う際の注意点もしっかり説明されています。 nのインストール $ npm install -g n Node.jsのバージョンの確認 1行目の「–stable」でStable（推奨版）のバージョン、2行目の「–latest」で最新版のバージョンが確認できます。 $ n --stable $ n --latest Latestのインストール $ n latest latestは最新の機能を搭載した最新版へのアップ
PostCSSってなに？導入前に知っておきたいことを箇条書きでまとめてみた
PostCSS って最近ちらほら目にするようになったけどいったいなに？と思っている方いませんか？僕はその一人です。なんとなくこんなもんかな？といった感じで曖昧にしか理解していなかったので「とりあえずこれだけ知っておけばいい」という情報を簡単にまとめてみました。 はじめに PostCSSをノートPCに例えると… SassをVAIOのようなメーカーが作ってパッケージしたノートPCに例えると、PostCSSはマザーボードからプロセッサーからケースまで、すべて自分で選んで組み立てる自作PCです。 かなり良さそう 結論から言ってしまうと、かなり良さそうなので早速使い始めて損はないと思います。大きな導入リスクやデメリットは思いあたらないし、すでにビルドツールを使っていれば導入コストも少なくすみます。少なくとも試してみる価値は十二分にありそうです。もちろん、開発体制や環境、プロジェクトの性質によるんでし
デザイナーやディレクターも知っておきたい、ページ表示速度の高速化の基本
スマホからウェブにアクセスするユーザが増え、ウェブサイトの表示速度の高速化がより重要な制作の課題になっています。1ページもののサイトなら、フロントエンド・エンジニアが一人で実装できるかもしれませんが、ある程度の規模のウェブサイトではワークフローやサイト全体の設計にも関わってきます。また、表示速度の高速化の方法を知らなければ、最適化しやすい、より高度なデザインは実現できないでしょう。エンジニアだけでなく、デザイナーやディレクターがこういった情報を知っていれば、よりスムーズに結果を出せるウェブサイト制作ができるはずです。 ページ表示速度の改善にはいろいろな方法がありますが、この記事では一番効果がありそうなところから攻めていきたいと思います。自分もまだまだ勉強中なので、まずはfilament groupのScottさんの記事 やClearleftのJeremyさんの記事 を参考に、フロントエンド
レスポンシブな時代に必要なWebディレクターの7つの心得
先日、僕の恩師のウェブ制作会社で開催された勉強会で「レスポンシブWebデザインのワークフロー」についてお話させていただいたんですが、その際に「意思決定層との密なコミュニケーションをとり、スムーズに開発を進めていくために、苦労した点や工夫した点」について質問をいただきました。その回答をまとめたので、このブログでも共有したいと思います。今回まとめたものはレスポンシブWebデザインでの制作に特化した内容ではないですが、以下に挙げるようなWebディレクターとしての基礎知識やスキルが、レスポンシブWebデザインのような柔軟な対応を強いられる制作では大切になると感じています。 Question: 意思決定層との密なコミュニケーションをとり、スムーズに開発を進めていくために、苦労した点や工夫した点を教えてください。 Answer: どれもディレクターとして基本的な内容になりますが、僕は以下のようなことを
レスポンシブWebデザインは臨機応変に使うのが良い
「レスポンシブWebデザイン」が題に入る本を書いてはいますが、レスポンシブWebデザイン（RWD）という手法を選択しなければならない、絶対にRWDでなければならないという理由はないと考えています。なぜなら、プロジェクトごとに向き不向きはありますし、そもそも発注側の企業文化や制作会社との相性、信頼関係の深度などによっては、RWDという制作の手法が向いていない可能性もあります。 そう考えると、なんでもかんでも安易にRWDで良いかというと、そうでもないように思います。長期的な視野で考えるとRWDのような手法が良いと考えていますが、だからといって現段階でそれが唯一の方法だとは考えていません。ゼロか百かの選択肢だけじゃなく、必要な場合は、ちょっとレスポンシブという臨機応変な対応もありですし、プロジェクトによっては個別スマホサイトを作ったほうが良いケースもあるかもしれません。 では、ウェブサイトの制作
いまさら聞けないRetina対応のための「ピクセル」の話
ピクセル密度とピクセル比の関係 ピクセル密度は、数が多ければ多いほどスクリーン上で鮮明な描画ができるわけですが、上述したピクセル比とは直接関連しないものです（と考えています）。たとえば、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
次世代HTMLの新仕様「レスポンシブ・イメージ（仮）」についてまとめてみた
レスポンシブWebデザインを実装する際、画像の扱いは一つの課題として残っています。現在、PHPを使用した「Adaptive Images」やJavaScriptを使った「Responsive-Images」などが現実的な対応策としてありますが、どちらもApacheの設定を必要とします。レスポンシブWebデザインが広まって標準的な実装方法の一つになろうとしている今、サーバサイド技術に依存しない解決策が早急に求められています。 そんな中、HTMLの仕様策定の一端を担うWHATWG（Web Hypertext Application Technology Working Group – ワットダブルジーと読む）で、新たな仕様が検討されています。 では、どんな議論がされていて、今どんな状況なのか？ なかなか複雑なことになっているようなので、調べてまとめてみました。 ※この記事は、レスポンシブWeb
レスポンシブWebデザインのウェブサイトを半年運営してみて思ったこと
昨年2011年10月に仕事で運営に携わっている大学ウェブサイトでレスポンシブWebデザイン (しかもフル可変グリッドレイアウト) を導入して、はや半年。約6ヶ月間、レスポンシブWebデザイン（RWD）で制作したウェブサイトを運営してみて思ったことをまとめてみました。これからレスポンシブWebデザインを導入したいと考えている方の参考になれば幸いです。 プロジェクトの概要 大学のウェブサイトをリニューアルするにあたり、さまざまな状況や制限などを考慮、また、今後3〜5年を見据えて、レスポンシブWebデザインを取り入れた制作を行いました。大学公式ブログでもリニューアルについて紹介しているので、ぜひそちらもご覧ください。そこで書いたように、以下のような思いもあり、このリニューアルを行いました： 今回、新しい試みを行った背景には、このウェブサイトが「大学のウェブサイト」であることが大きな要因の一つとし
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Rriver