高速ブラウジングを実現するGoogleの「AMP」、日本でも検索結果にAMP対応記事が表示されるように 
なんでもかんでもpicture要素を使えばいいわけじゃない！レスポンシブ・イメージ実装の際の注意点
画像表示のマルチデバイス対応をHTMLとCSSのみで実現できる「レスポンシブ・イメージ」ですが、効果的な使い方をするには、いくつか注意点があります。プロダクション・サイトで使えるようになるまでにはもう少し時間がかかりそうですが、基礎と注意点くらいは今から覚えておいても良さそうです。 Cloud Fourというアメリカの制作会社のブログ で、<picture>要素の使い方について注意を促していて、とても重要な情報だと思ったのでこちらでもシェアします。先日書いたレスポンシブ・イメージとPicturefill 2のまとめとあわせて、近い将来、レスポンシブ・イメージ実装の参考になれば幸いです。 まずは推奨の記述方法から レスポンシブ・イメージ実装の際に推奨されるHTMLの記述方法は以下のとおりです： とりあえず、これだけ覚えておけば、細かいところはこの記事をはてブ しておいて、使う時にもう一度見な
srcsetとsizes
パート1：メディア・クエリのどこがまずいのか？ そう、もし君がウェブサイトを作っている時代が1993年2月23日から2010年5月25日の間だったら、画像の扱いなんてチョロかったね！ それはこんなふうに単純だった。 幅の固定されたレイアウトをにらみつける 画像がきっかり何ピクセルかを測る――その画像はあらゆるユーザーの画面で変わらないスペースを占めることになる Photoshopのエンジンをかける 画像をさっき測ったとおりのサイズで「ウェブ用に保存」する それを<img>タグでマークアップする グラスにビールを注ぎ（または新鮮なグリンピースの缶を開け）、仕事がうまくいったことを祝う ときおり聡明なる預言者が荒野から現れては、この手法に潜む問題について深遠な真実を説くこともあった。それでもこのやり方は、20年もの間、ウェブ・デザイナーを生業とするものたちに受け入れられてきた。 しかし、時代は
picture要素の関連仕様って今どうなってるんだっけ？を調べたメモ
<picture> どうなった 勤め先がモバイルに注力していたこともあり、レスポンシブもへったくれもない世界を生きてきた。そのせいで、その類の情報にかなり疎くなっていたので、現状を軽く調査してみた次第。 HTMLでの画像リソース読み込み分岐の必要性 CSS には Media Queries があるので、Viewport の width であったりデバイスのピクセル密度であったりを条件にして background プロパティの指定をすれば対応できる。 反面、<img> 要素と src 属性にはそのような仕組みがないため、Media Queries で可能な条件で同じようにやろうと思うと、JavaScript で DOMContentLoaded のあとに"頑張って"操作するか、バックエンドで UserAgent に応じて"賢く"返す仕組みを用意しなければならない。 WebP のような画像形式
The case for an embeddable Gecko – ChrisLord.net
Strap yourself in, this is a long post. It should be easy to skim, but the history may be interesting to some. I would like to make the point that, for a web rendering engine, being embeddable is a huge opportunity, how Gecko not being easily embeddable has meant we’ve missed several opportunities over the last few years, and how it would still be advantageous to make Gecko embeddable. What? Embed
Ask HN: How to handle 50GB of transaction data each day? (200GB during peak) | Hacker News
Recently I switched jobs and joined some old employers and friends on a new endeavour, an advertisement platform. So far things have been very good, so good in fact that we're quickly growing out of our current infrastructure. Last christmas everything went crazy and the, then only developer, rewrote a bunch of things to make it scale better.Currently we write away every single transaction to txt
ZeroDB white paper
ZeroDB is an end-to-end encrypted database that enables clients to operate on (search, sort, query, and share) encrypted data without exposing encryption keys or cleartext data to the database server. The familiar client-server architecture is unchanged, but query logic and encryption keys are pushed client-side. Since the server has no insight into the nature of the data, the risk of data being e
OpenID Connectはそんなに大変かね？ - OAuth.jp
OAuth 2.0 + OpenID Connect のフルスクラッチ実装者が知見を語る – Qiita ってのになんかフォローアップしろよ的なのが来たので。 ざっと読んだ感想としては、「OpenID Connect の OPTIONAL な機能全部実装したら、そら大変ですね」という感じ。（Authlete に関しては、OpenAM みたいな感じで使われる、OpenAM よりはるかに簡単に使える代わりに有料の何かなんだろうな、というイメージです） OAuth は必要なのか？ Basic 認証は死んだ。 ユーザー単位での API のアクセスコントロールがしたいです。 っていう前提で話すると、OAuth 以外まともな選択肢が無いんじゃないでしょうか。 OAuth の各種 Extension (RFC 6749 & 6750 以外にいろいろある) に関しては、適宜必要なのを実装すればいいんだけど
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub Visualizer