【2020年夏】imgタグにはwidthとheight属性を書くのがいいらしい
そうなんです。 2020年夏、ページの読み込み中にレイアウトがシフトしないように、img要素にはwidthとheight属性を記述するのがいいらしいんです。 <img src="link/to/image.jpg" width="300" height="400" alt="画像の説明"> その昔、これが普通の時代もあったんですけどね。レスポンシブな時代にはwidthとheight属性を書かないのが一般的（？）になっていました。また、widthとheight属性が記述してあってもCSSでwidth: 100%; height: auto;が指定されているとレイアウトシフトが発生してしまっていました。 参考： img要素のサイズ属性の記述の有無についてのTwitterのアンケート なんでいまさら？ なぜなら、2019年の後半にブラウザにレイアウトシフトを回避するための新たな機能が実装されたか
75歳の父にも親切なウェブサイトやUX
先日、今年75歳になる父親のiPhoneの機種変更を手伝ってきました。iPhone 5からiPhone 8 Plusへの大幅アップグレードでしたw まず新宿のビックロに行って機種変更をして、それから新しいiPhoneに設定を移行したり、モバイルSuicaに新しく登録してみたり。半日かけていろいろやりました。 その間、父親がiPhoneを操作するのを興味津々でずっと眺めていました。ユーザテストをする感じで結果的にいろいろなことを学ばせてもらいました。それが目的だったわけじゃないんですけどね。でも、そんな父親の「ユーザテスト」を目の当たりにして、歳をとった親にも親切なウェブサイトやUXの設計をしなくてはと改めて思わされました。 「文字ちっちゃ！」とか「なにそれ、なんでそうなる？」とか「ん？いまなんのリンクをクリックした？え？そのリンクテキストでそのリンク先じゃ絶対迷う！」みたいなことを父親と一
レスポンシブWebデザインは臨機応変に使うのが良い
「レスポンシブWebデザイン」が題に入る本を書いてはいますが、レスポンシブWebデザイン（RWD）という手法を選択しなければならない、絶対にRWDでなければならないという理由はないと考えています。なぜなら、プロジェクトごとに向き不向きはありますし、そもそも発注側の企業文化や制作会社との相性、信頼関係の深度などによっては、RWDという制作の手法が向いていない可能性もあります。 そう考えると、なんでもかんでも安易にRWDで良いかというと、そうでもないように思います。長期的な視野で考えるとRWDのような手法が良いと考えていますが、だからといって現段階でそれが唯一の方法だとは考えていません。ゼロか百かの選択肢だけじゃなく、必要な場合は、ちょっとレスポンシブという臨機応変な対応もありですし、プロジェクトによっては個別スマホサイトを作ったほうが良いケースもあるかもしれません。 では、ウェブサイトの制作
印刷したら崩れてた！？印刷用CSSのスタイル確認と修正に便利なChrome DevToolsのエミュレータ機能
いつでも、どこでもネットにアクセスできる昨今、ウェブページを印刷する機会は減っているかもしれません。でも、いざ印刷したらレイアウトやスタイルが崩れていて使えないものになっていたらユーザに申し訳ないですよね。紙の無駄使いになってエコじゃないですし。 ということで、今回は自分メモ的にプリントCSSの確認ツールのご紹介です。 Chrome DevToolsのメディアタイプのエミュレーション機能 以前は印刷プレビューで印刷用CSSを確認していましたが、なにせ効率が悪いので他の方法を探してみました。なんと、Chrome DevToolsにエミュレータ機能がついてたんですね。さすがです。 以下の手順で、そのエミュレーション機能にアクセスできます。 Chrome DevToolsを開く（⌘ + ⌥ + I） スマホ（device mode）アイコンをクリック drawerアイコンをクリックする （Emu
デザイナーやディレクターも知っておきたい、ページ表示速度の高速化の基本
スマホからウェブにアクセスするユーザが増え、ウェブサイトの表示速度の高速化がより重要な制作の課題になっています。1ページもののサイトなら、フロントエンド・エンジニアが一人で実装できるかもしれませんが、ある程度の規模のウェブサイトではワークフローやサイト全体の設計にも関わってきます。また、表示速度の高速化の方法を知らなければ、最適化しやすい、より高度なデザインは実現できないでしょう。エンジニアだけでなく、デザイナーやディレクターがこういった情報を知っていれば、よりスムーズに結果を出せるウェブサイト制作ができるはずです。 ページ表示速度の改善にはいろいろな方法がありますが、この記事では一番効果がありそうなところから攻めていきたいと思います。自分もまだまだ勉強中なので、まずはfilament groupのScottさんの記事 やClearleftのJeremyさんの記事 を参考に、フロントエンド
WordPressでレスポンシブ・イメージの自動化を可能に。RICG公認プラグインが公開
追記： 2016.01.29 WordPress 4.4からレスポンシブ・イメージがCoreに実装されました。詳しくは以下をご覧ください： WordPress 4.4以降でのレスポンシブ・イメージ・プラグインはどうなるの？ WordPress 4.4からデフォルトで実装されたレスポンシブイメージってどうなのよ？ レスポンシブ・イメージの仕様策定や普及に努めているRICG（Responsive Images Community Group） が公認したレスポンシブ・イメージのWordPressのプラグイン が公開されましたね。このプラグインを使うとWordPressでのレスポンシブ・イメージの解像度対応の自動化が可能になります。RICG公認のプラグインが出たことでプラグインの開発や普及が加速すると嬉しいですね。 そもそもレスポンシブ・イメージってなによ？という方は、こちらあたりをお読みくださ
なんでもかんでもpicture要素を使えばいいわけじゃない！レスポンシブ・イメージ実装の際の注意点
画像表示のマルチデバイス対応をHTMLとCSSのみで実現できる「レスポンシブ・イメージ」ですが、効果的な使い方をするには、いくつか注意点があります。プロダクション・サイトで使えるようになるまでにはもう少し時間がかかりそうですが、基礎と注意点くらいは今から覚えておいても良さそうです。 Cloud Fourというアメリカの制作会社のブログ で、<picture>要素の使い方について注意を促していて、とても重要な情報だと思ったのでこちらでもシェアします。先日書いたレスポンシブ・イメージとPicturefill 2のまとめとあわせて、近い将来、レスポンシブ・イメージ実装の参考になれば幸いです。 まずは推奨の記述方法から レスポンシブ・イメージ実装の際に推奨されるHTMLの記述方法は以下のとおりです： とりあえず、これだけ覚えておけば、細かいところはこの記事をはてブ しておいて、使う時にもう一度見な
Appleがトップページで自動送りカルーセルをやめた理由
残念ながらページ全体のキャプチャをとっていなかったので下までお見せできませんが、ページのメイン要素となるカルーセルの下にはフッターしかありませんでした。ほんとですw そして、おぉ、さすがApple。 ここでも思い切った選択をしたな〜と思っていたわけです。 ところが！ 数日後にもう一度トップページを見てみたら、あの懐かしの4つのボックスが戻っているではないですか！？ 実は、このレイアウト（巨大ヒーローイメージと4つのフィーチャーボックス）が、何年も続いたAppleの鉄板レイアウトだったわけですが、先日のリニューアルでこのフィーチャーボックスがなくなっていて「ついに、あれもお亡くなりになられたか」と、密かに悲しんでおりました。 その後のこの華麗なカムバックです。 かなり興奮してしまいました。 しかも、スタイルも細かいスペースや背景の扱いがよりシンプルなものに更新されています。 iPadでみると
HTML5やCSS3のブラウザサポート状況を簡単に調べられる「Can I use…」のGoogleアナリティクス連携が便利
HTML5やCSS3のブラウザサポート状況を簡単に調べられる「Can I use…」のGoogleアナリティクス連携が便利 HTML5やCSS3のブラウザサポート状況が確認できるcaniuse.comのベータ版が2014年6月に公開され、デザインが刷新されました。 このベータ版のデザインの良さにも驚きましたが、なにより驚いたのはGoogleアナリティクスとの連携機能でした。ベータ版の「Settings」から設定を行うと、Googleアナリティクスのデータを読み込むことができ、自分のサイトに訪れるユーザが使うブラウザで、ある特定のHTML5やCSS3の機能が、どのくらいサポートされているかがわかります。世の中便利になりましたね〜。 実は現行版でも同じ機能が使えるのですが、残念ながらぜんぜん気づきませんでした。 ※ちなみに、このベータ版は数週間テストを行いフィードバックを得てから、本番サイトに
マルチデバイス時代の制作手法の選び方
遅ればせながら、あけましておめでとうございます。 昨年10月後半から職場での環境が大きく変わったこともあり、ブログは放置状態で、ソーシャルメディアでの投稿すらあまりできませんでした（言いわけ）。 2014年も1月も後半に差し掛かってしまいましたが、今年もRriverを、どうぞよろしくお願いします。役に立つ情報を掲載することを目標に、今年も1年頑張ります。 2012年5月に「レスポンシブWebデザインのウェブサイトを半年運営してみて思ったこと」という記事を書いてから、はやくも1年半以上が過ぎ、RWDの本を出してから約1年もの年月が過ぎました。2014年のはじめということもありますし、これから何回かに分けて、これからのレスポンシブWebデザインについて考察をまとめていきたいと思います。 今回は、以下の2つについて： 「レスポンシブWebデザイン」はどうなる？ 制作手法を選択する際の判断基準とは
コードエディター「Brackets」のレスポンシブモードが最強！（リリースされるかわからないけど…）
Adobe社が開発・メンテしているオープンソースのコードエディター「Brackets」向けの「Responsive Design Tool」が、YouTubeのデモを見る限り、かなり良い感じなのでご紹介ます。Adobe Edge Reflowがデザイナー向けのWYSIWYGツールだとすれば、Bracketsのレスポンシブ・デザイン・ツールは開発者がより効率的にコードを編集するためのツールを目指して作ったそうです。デモを見ただけでも、これを使えばレスポンシブなサイトのコーディングが数倍効率化されるのが想像できます。Designing in the Browserがコードエディター上できてしまうのはすごく理想的です。 このツールの開発者でありAdobeのDeveloper EvangelistでもあるBrimelowさんは、「まだバグも多く終わっていないところが沢山あるので、どうなるかわからな
マルチデバイス時代に知っておきたい、ウェブ・コンテンツに対する2つのアプローチ
前回の投稿「レスポンシブ・デザインとアダプティブ・デザインの定義を整理してみた」に対して、「覚え書き@kazuhi.to」で「続・レスポンシブWebデザインとかアダプティブWebデザインとか」として、再度レスポンシブとアダプティブについての木達さんの解釈をまとめています。記事中でおっしゃっている通り、僕とは見解が違うところもありますが、特に図解の部分はウェブ制作に関わる人には必見だと思ったので、こちらでも共有させていただきます。マルチデバイス時代のウェブ制作において考慮すべき技術的な制作手法の分類がすっきり整理されています。 ※上図は「続・レスポンシブWebデザインとかアダプティブWebデザインとか」の2013/6/23の時点のものを内容を変更せずに、そのまま掲載させていただいています。（木達さん、ありがとうございます！） 「レスポンシブ」や「アダプティブ」という言葉の扱いはとりあえずわき
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
