Web のセマンティクスにおける Push と Pull | blog.jxck.io
Intro 筆者は、 Web のセマンティクスに対する実装の方針として、大きく Push 型の実装 と Pull 型の実装 があると考えている。 もっと言えば、それは実装方法という具体的な話よりも、開発者のセマンティクスに対する態度を表現することができる。 この話は「Push よりも Pull が良い」などと簡単に切り分けられる話ではない。 「自分は今 Push で実装しているのか、 Pull で実装しているのか」この観点を意識するかしないかによって、セマンティクスに対する視野が広くなり、その応用として、たとえば今自分が行っている実装が、将来の Web においてどのような互換性の問題を生じるかなどを想像できるようになるだろう。最近問題になる Ossification を、こうした視点の欠如の結果とみることもできる。 (本エントリでの Ossification は、一般に言われている Pro
IE11 サポート終了の歴史 | blog.jxck.io
Intro IE11 が役目を終えていく流れを記録として残す。特に MS からのアナウンスや、それに準じた各サービスの反応、特に IE サポート終了アナウンスをまとめることで、 IE11 というブラウザがどのように終了していったのかのを記録することを目的とする。 もともとは Google Docs にまとめていたものである。 日付はアナウンスの公開日 サポート終了日ではない サポート終了日も書いておけばよかったけど今からやり直す気力はない、、 赤字 は MS 関連もしくはサポート終了の影響が大きそうなアナウンス Windows における IE11 自体のサポート終了については以下を参照 https://www.atmarkit.co.jp/ait/articles/1503/11/news134.html できればある程度の結論が出るまでこのエントリを更新していきたい 追加リクエスト 本エ
Scroll To Text Fragment と :~:text | blog.jxck.io
Intro ページ内の特定の位置へのスクロールは、 URL フラグメントと HTML の ID 属性を用いて行われていた。 しかし、 ID を持たない要素へのスクロールというユースケースをカバーするために、フラグメントの拡張仕様が提案されている。 Chrome がフラグ付きで実装しているため、この仕様の特徴について解説する。 id 属性とフラグメント 従来の仕様では、 HTML 内にある ID 属性を URL フラグメントに付与することで、その要素まで自動でスクロールするという仕様になっていた。 https://html.spec.whatwg.org/multipage/browsing-the-web.html#try-to-scroll-to-the-fragment https://html.spec.whatwg.org/multipage/browsing-the-web.ht
牧歌的 Cookie の終焉 | blog.jxck.io
Intro Cookie は、ブラウザに一度保存すれば、次からその値を自動的に送ってくるという、非常に都合の良い仕様から始まった。 State Less が基本だった Web にセッションの概念をもたらし、今ではこれが無ければ実現できないユースケースの方が多い。 冷静に考えればふざけてるとして思えないヘッダ名からもわかるように、当初はこのヘッダがこんなに重宝され、 Web のあり方を変えるかもしれないくらい重要な議論を巻き起こすことになるとは、最初の実装者も思ってなかっただろう。 そんな Cookie が今どう使われ、 3rd Party Cookie (3rdPC) の何が問題になっているのかを踏まえ、これからどうなっていくのかについて考える。 Cookie のユースケース Web にある API の中でも Cookie はいくつかの点で特異な挙動をする 一度保存すれば、次から自動で送る
Stale-While-Revalidate ヘッダによるブラウザキャッシュの非同期更新 | blog.jxck.io
Intro システムにおいてキャッシュの設計は永遠の課題であり、 Web のパフォーマンスにおいても非常に重要である。 Web では、 HTTP ヘッダを用いてブラウザやプロキシにキャッシュの制御を指定する。 Stale-While-Revalidate ヘッダは、このキャッシュ制御に選択肢を追加する新しい仕様である。 このヘッダの概要と、本サイトへの適用を解説する。 Web におけるキャッシュ キャッシュの種類 まず、ブラウザが持つ従来のキャッシュの機構について整理する。 そもそも、キャッシュを行う意義は大きく二つある。 リソースの取得を高速化する サーバへの負荷を減らす これまでは HTTP ヘッダを用いて、キャッシュを管理させる方法を用いてきた。 Web における、キャッシュの指定には大きく二つの方式がある。 ブラウザはリクエストを発行せず、保持するキャッシュを使用する(Cache-
リンクのへの rel=noopener 付与による Tabnabbing 対策 | blog.jxck.io
なお IE は(security zone setting をいじらない限り)この問題が発生しないようだ。 引用元: blankshield demo | Reverse tabnabber phishing tabnabbing 上記の挙動を、フィッシング詐欺に利用できることが既に指摘されている。 この手法は Tabnabbing と呼ばれている。 Tabnabbing: A New Type of Phishing Attack Aza on Design Target="_blank" - the most underestimated vulnerability ever この攻撃方法を解説する。 攻撃の概要 https://cgm.example.com (左上) というサービスがあるとし、これは SNS やチームコラボレーション系サービスを想定する。 攻撃者は、このサービスの不
AMP HTML 対応 | blog.jxck.io
Intro Google が推奨する仕様である AMP HTML に、このブログを対応した。 言いたいことは色々あるが、とりあえず非常に難しかったため、その対応方法や感想などを残す。 Update 以下の記事が出たので、古かったフォーマットのアップデートと JSON-LD によるメタデータの提供 に対応した。 Google モバイル検索が Accelerated Mobile Pages に対応しました AMP 対応 2016.02 版 Accelerated Mobile Pages ACCELERATED MOBILE PAGES PROJECT タイトルは識別しやすいよう AMP HTML としたが、実際には AMP という仕様(方針)があり、 HTML 以外にも手を入れている。 AMP は、特にモバイル向けに 静的コンテンツ を最適化し、表示を高速化することを目的としている。 実際
Blog を移転しました | blog.jxck.io
Image 画像は <picture> タグを用いて表現する。 必ず .webp も提供する必要がある。 webp の推奨は以下 $ cwebp -q 40 img.png -o img.webp Video markdown 上は画像と同じ記法で、拡張子が mp4 の場合は <video> で展開する。 必ず .mp4、.webm 両方を提供する必要がある。 QuickTime で screen record を取り gif 的に表示するなら推奨は以下。 # メタデータを消し、 frame rate を 24 にし、Audio を消す $ ffmpeg -i video.mov -map_metadata -1 -r 24 -an video.webm $ ffmpeg -i video.mov -map_metadata -1 -r 24 -an video.mp4 サンプルコード イ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
