なんでもかんでもpicture要素を使えばいいわけじゃない！レスポンシブ・イメージ実装の際の注意点
画像表示のマルチデバイス対応をHTMLとCSSのみで実現できる「レスポンシブ・イメージ」ですが、効果的な使い方をするには、いくつか注意点があります。プロダクション・サイトで使えるようになるまでにはもう少し時間がかかりそうですが、基礎と注意点くらいは今から覚えておいても良さそうです。 Cloud Fourというアメリカの制作会社のブログ で、<picture>要素の使い方について注意を促していて、とても重要な情報だと思ったのでこちらでもシェアします。先日書いたレスポンシブ・イメージとPicturefill 2のまとめとあわせて、近い将来、レスポンシブ・イメージ実装の参考になれば幸いです。 まずは推奨の記述方法から レスポンシブ・イメージ実装の際に推奨されるHTMLの記述方法は以下のとおりです： とりあえず、これだけ覚えておけば、細かいところはこの記事をはてブ しておいて、使う時にもう一度見な
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は最新の機能を搭載した最新版へのアップ
SassとGulpを使った便利なメディアクエリの記述方法とアウトプットの最適化
先日このブログのデザインをリニューアルしたときに、メディアクエリの記述が結構手間だったので、記述のしやすさ、メンテナンス性の良さ、また、最終的なCSSファイルの最適化の3つの観点から、便利な書き方と最適化の方法をまとめてみました。 目次 モバイル・ファーストCSSで書く 要素ごとに、Sassを使って記述する Gulpを使ってメディアクエリの整理する まとめ モバイル・ファーストCSSで書く メンテナンス性の良さや重複の少ないよりシンプルなCSSの記述を目指すと、モバイル・ファーストCSSで書くのが良いです。デスクトップ・ファーストCSSで書く場合、小さい画面向けにはスタイルを追加するというより、消していく（または、上書きして帳消しにする）作業が多くなってしまいます。 このブログはモバイルからのアクセスが1割程度なので、今回のデザインのリニューアルでは、
まったくの勘違い！Appleはトップページで自動送りカルーセルをやめてませんでした
iPad Air 2とiMac with Retina 5K displayが発表されましたね。 世間のみなさんが、なにが発表されるかワクワクしているころ、僕は発表後のAppleウェブサイトが気になってドキドキしておりました。 というのも、先日「Appleがトップページで自動送りカルーセルをやめた理由」という記事を書いていたからです。 新製品発表後のApple.comトップページ まずは、訂正とお詫びから 先日の記事ではAppleがトップページで自動送りカルーセルをやめた理由を以下のように書いていたのですが、まったくの勘違いだったようです。「あくまで推測の域は脱しない」と書いてはいるものの、先日の記事により誤解を生じさせてしまう可能性があるため、この場を借りて訂正とお詫びをさせていただきます。 あくまで推測の域を脱しないですが、A/Bテストを実施して、ある数値以下の結果だったら差し替え用の
デザイナーやディレクターも知っておきたい、ページ表示速度の高速化の基本
スマホからウェブにアクセスするユーザが増え、ウェブサイトの表示速度の高速化がより重要な制作の課題になっています。1ページもののサイトなら、フロントエンド・エンジニアが一人で実装できるかもしれませんが、ある程度の規模のウェブサイトではワークフローやサイト全体の設計にも関わってきます。また、表示速度の高速化の方法を知らなければ、最適化しやすい、より高度なデザインは実現できないでしょう。エンジニアだけでなく、デザイナーやディレクターがこういった情報を知っていれば、よりスムーズに結果を出せるウェブサイト制作ができるはずです。 ページ表示速度の改善にはいろいろな方法がありますが、この記事では一番効果がありそうなところから攻めていきたいと思います。自分もまだまだ勉強中なので、まずはfilament groupのScottさんの記事 やClearleftのJeremyさんの記事 を参考に、フロントエンド
Retina対応にSVGは本当に使えるのか？
高解像度スクリーンに対応できるのは嬉しいですが、普通の解像度しか持たない端末にも大きなファイルをダウンロードさせなければならないのは、3G回線などの遅い回線での表示パフォーマンスを考慮すると、SVGが適していないケースもありそうです。ただ、サーバ上でGZIP圧縮した場合、平均30%ほどサイズを削減できることを考慮すると、数十KBの差がある場合を除いて、表示パフォーマンスと表示クオリティのバランスもとれてくる気がしています。 ちなみに、Illustratorで「圧縮」を選択してsvgzとして保存すると2,395Bになりました。これならPNG8のファイルサイズにだいぶ近くて良い感じですね。Apacheの設定にSVGZが記述されていれば圧縮版を使えるので、このサイズだったら現実的な気がしてきました。ただ、サーバの設定がうまくいかないのか、Illustratorでの書き出しが悪いのか、SVGZを表
Sass/Compassの社内運用に関するありがたいスライドから学んだことのまとめ
これはありがたい！と思えるSass/Compassに関するスライドが2つほどSlideshareにアップされていたので、このブログでも紹介させていただきます。去年行われたHTML5 Conference 2012でNHN Japanのマークアップエンジニアの方から発表されたもので、すでにSassを使ってCSS運用を始めている方からの貴重な情報です。 前編、後編とあるので、それぞれに対して自分なりに重要だと思ったこと、また、それらに対する考察をまとめてみました。自分が管理・運営しているウェブサイトのCSS管理も、Sass/Compassを使ってやりたいなぁと思う今日このごろです。時間的な初期投資は必要だけど、長期的に考えたらメリットも多く時間の節約にもなりそうです。 今回の投稿では、まずは前編から。 前編で気になったところのまとめ 「実践Sass 前編 — HTML5 Conference
レスポンシブWebデザインのサイトに「デスクトップ表示」ボタンが必要な2つの理由
レスポンシブWebデザイン（RWD）で作ったウェブサイトを運営しはじめてから気になっていたことが一つあります。それは、RWDで作られたウェブサイトでもデスクトップ版のレイアウトが見られるようにする機能が必要かという疑問です。僕が書いた本でもp.176のコラム「レスポンシブWebサイトでも『PCサイト』ボタンが必要？」で触れた内容ですが、先日のBruce Lawson氏のブログ記事を読んでいて、再び気になったので自分の考えをまとめてみました。 モバイル版ブラウザの「デスクトップ表示」機能 たとえばDolphinやChromeといったモバイル向けブラウザにはデスクトップ版を表示するための機能が用意されています（FirefoxやMobile Operaにもついてるそうです）。わざわざこういうった機能が装備されているということは、これがユーザに求められる機能だからだと思います。（以下はiPhone
レスポンシブなデザインにするなら知っておきたい。各ブラウザの小数点以下のピクセル値の扱い
デザイン要素を固定しないリキッドレイアウトは、未知の端末にも対応するというコンセプトのもとに実装するレスポンシブウェブデザインには必須だと考えています。そのリキッドレイアウトを実装する際に理解しておきたいのが、パーセント値で幅や高さを指定した際に小数点以下になるピクセル値（10.5pxとか9.2pxなど）に対するブラウザの挙動です。 たとえばグリッドシステムを構築する際、計算上はあっているのにブラウザでは思った通りに表示されないといったことが起こります。これは、各ブラウザのサブピクセル（小数点以下のピクセル値）の扱いの挙動差により生まれます。 まずはパーセント指定の基本から まずは前提となるパーセント指定の際の計算の基本のおさらいから。。。 CSSでパーセント値を使って幅や高さ指定をすると、指定した要素を含む親要素をベースにピクセル値が計算されます。 たとえば100pxの親要素の中にある子
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
