お盆だし「スマホ全盛時代のウェブのこれから」について考えてみた ー 能動的な検索が必要とされる限りウェブは死なない
ここ最近、海外でも日本でも「ウェブの将来は明るくない」という話題をちらほら目にするので、1990年代後半からウェブ制作をずっとやっている自分としては「ウェブ制作という仕事に未来はないのかぁ。そうなのかぁ。。。」と、少し憂鬱な気持ちになっています。 別にそれらの話を鵜呑みにして同意しているわけではないんですけどね。 ということで、これを機に頭の中でモヤモヤしていることを、一度整理して書き留めておこうと思います。こういう未来予想的な内容は10年後に読み返してみたら面白そうですしね。 10年後の自分： 「全然ちがってたっ！恥。。。」みたいな感じでw ウェブは「もう、ダメ。。。」なのか？ 「ウェブはもうあッか〜ん」というプレッシャーを感じているのは僕だけですかね？ 僕が感じている風潮を、大雑把に、ちょっと大げさにまとめてみると以下のような感じです： ついにスマホ全盛期が到来！これからは、モバイルフ
なんでもかんでもpicture要素を使えばいいわけじゃない！レスポンシブ・イメージ実装の際の注意点
画像表示のマルチデバイス対応をHTMLとCSSのみで実現できる「レスポンシブ・イメージ」ですが、効果的な使い方をするには、いくつか注意点があります。プロダクション・サイトで使えるようになるまでにはもう少し時間がかかりそうですが、基礎と注意点くらいは今から覚えておいても良さそうです。 Cloud Fourというアメリカの制作会社のブログ で、<picture>要素の使い方について注意を促していて、とても重要な情報だと思ったのでこちらでもシェアします。先日書いたレスポンシブ・イメージとPicturefill 2のまとめとあわせて、近い将来、レスポンシブ・イメージ実装の参考になれば幸いです。 まずは推奨の記述方法から レスポンシブ・イメージ実装の際に推奨されるHTMLの記述方法は以下のとおりです： とりあえず、これだけ覚えておけば、細かいところはこの記事をはてブ しておいて、使う時にもう一度見な
Appleがトップページで自動送りカルーセルをやめた理由
残念ながらページ全体のキャプチャをとっていなかったので下までお見せできませんが、ページのメイン要素となるカルーセルの下にはフッターしかありませんでした。ほんとですw そして、おぉ、さすがApple。 ここでも思い切った選択をしたな〜と思っていたわけです。 ところが！ 数日後にもう一度トップページを見てみたら、あの懐かしの4つのボックスが戻っているではないですか！？ 実は、このレイアウト（巨大ヒーローイメージと4つのフィーチャーボックス）が、何年も続いたAppleの鉄板レイアウトだったわけですが、先日のリニューアルでこのフィーチャーボックスがなくなっていて「ついに、あれもお亡くなりになられたか」と、密かに悲しんでおりました。 その後のこの華麗なカムバックです。 かなり興奮してしまいました。 しかも、スタイルも細かいスペースや背景の扱いがよりシンプルなものに更新されています。 iPadでみると
マルチデバイス向けの制作に必須！シンクロナイズド・ブラウザ・テストを実現する3 + 1つのツール
CSSやHTMLを編集すると、アクセスしている複数の端末が同期されて自動的にリロードされる「Synchronized Browser Testing」というツールがあります。このブログのデザイン変更作業をした際に、マルチデバイス対応のサイト制作にはこういったツールが必須だなぁと実感したので、試したツールと設定の注意点などをまとめてみました。 用途と設定の難易度で、それぞれ向いているツールは異なると思いますが、僕のいまのところの最強コンビは、BrowserSync + Gulpとngrokの組み合わせだと思っています。 紹介するツール一覧 CodeKit Ghostlab BrowserSync ngrok 最後に機能比較一覧も作ってみました。 Codekit（29ドル） https://incident57.com/codekit/ Sass、Less、Coff
レスポンシブ・イメージがもうすぐネイティブ実装！いまから使える？ポリフィル「Picturefill 2.x」を検証
レスポンシブ・イメージがもうすぐネイティブ実装！いまから使える？ポリフィル「Picturefill 2.x」を検証 レスポンシブ・デザインの画像の扱いの課題を解決するのが「レスポンシブ・イメージ」です。この「レスポンシブ・イメージ」には紆余曲折あったわけですが、熱心な開発者の方々のおかげでようやく仕様がまとまり、ブラウザでのネイティブ実装も進んでいます。 結論から言うと、ブラウザのネイティブ実装はまだこれからですし、ポリフィルのPicturefill 2.xには大きな欠陥があり、プロダクションサイトでの使用は待ったほうが良いと思います。しかし、多くの開発者が多大な時間を費やして実現しようとしているレスポンシブ・イメージです。この存在が日本でもより多くの人に広まればと思い、いまの状況をまとめてみました。 目次 レスポンシブ・イメージのいま レスポンシブ・イメージで解決できる3つの課題 Pic
いまさら聞けない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
レスポンシブなデザインにするなら知っておきたい。各ブラウザの小数点以下のピクセル値の扱い
デザイン要素を固定しないリキッドレイアウトは、未知の端末にも対応するというコンセプトのもとに実装するレスポンシブウェブデザインには必須だと考えています。そのリキッドレイアウトを実装する際に理解しておきたいのが、パーセント値で幅や高さを指定した際に小数点以下になるピクセル値（10.5pxとか9.2pxなど）に対するブラウザの挙動です。 たとえばグリッドシステムを構築する際、計算上はあっているのにブラウザでは思った通りに表示されないといったことが起こります。これは、各ブラウザのサブピクセル（小数点以下のピクセル値）の扱いの挙動差により生まれます。 まずはパーセント指定の基本から まずは前提となるパーセント指定の際の計算の基本のおさらいから。。。 CSSでパーセント値を使って幅や高さ指定をすると、指定した要素を含む親要素をベースにピクセル値が計算されます。 たとえば100pxの親要素の中にある子
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
