peketaminのブックマーク - はてなブックマーク

なぜブラウザエンジンは 1 つではダメなのか? または Ladybird への期待 | blog.jxck.io

Intro Ladybird は、他のブラウザエンジンをフォークせず、企業との取引に頼らず、寄付だけで作ることを宣言した新しいブラウザエンジンだ。 Ladybird https://ladybird.org/ これがいかに価値のある取り組みなのか、 Web を漫然と眺めてきた筆者による N=1 の妄言を書いてみる。ブラウザエンジンとはブラウザは、﹁ブラウザ UI﹂と﹁ブラウザエンジン﹂と、大きく二つの構成要素に分けて考えることができる。ブラウザエンジンとは、いわゆる Web 標準の技術を片っ端から実装した、ブラウザの土台となるものだ。ビルドすれば、入力した URL からネットワーク経由でリソースを取得し、パースしてレンダリングして表示できる。そのためのIETF RFC や WHATWG HTML や ECMAScript が実装されている、標準技術の結集だ。その上に、例えばタブ

peketamin 2024/07/06

リンク

令和時代の API 実装のベースプラクティスと CSRF 対策 | blog.jxck.io

Intro CSRF という古の攻撃がある。この攻撃を﹁古(いにしえ)﹂のものにすることができたプラットフォームの進化の背景を、﹁Cookie が SameSite Lax by Default になったからだ﹂という解説を見ることがある。確かに、現実的にそれによって攻撃の成立は難しくなり、救われているサービスもある。しかし、それはプラットフォームが用意した対策の本質から言うと、解釈が少しずれていると言えるだろう。今回は、﹁CSRF がどうして成立していたのか﹂を振り返ることで、本当にプラットフォームに足りていなかったものと、それを補っていった経緯、本当にすべき対策は何であるかを解説していく。結果として見えてくるのは、今サービスを実装する上での﹁ベース﹂(not ベスト)となるプラクティスだと筆者は考えている。 CSRF 成立の条件例えば、攻撃者が用意した attack.examp

peketamin 2024/04/26

リンク

RFC の URL はどのドメインで貼るのが良いか | blog.jxck.io

Intro IETF の RFC は、いくつかの場所で同じものが公開されている。どの URL が最適なのか、という話。結論は www.rfc-editor.org だ。 RFC Hosting Site例えば RFC 9110 - HTTP Semantics で言うと、以下の4つがある。 https://tools.ietf.org/html/rfc9110 https://datatracker.ietf.org/doc/html/rfc9110 https://www.rfc-editor.org/rfc/rfc9110.html https://httpwg.org/specs/rfc9110.html まずは、これらの違いを簡単に解説する。 tools.ietf.org IETF がホストする RFC は、 tools.ietf.org だった。 RFC 2616: H

peketamin 2024/03/28

リンク

Chromium にコントリビュートするための周辺知識 | blog.jxck.io

Intro Chromium にコントリビュートするためには、ソースコードを理解する以外にも、もろもろ必要な周辺知識がある。ドキュメントはかなり整備されている方ではあるが、そのドキュメントにたどり着くのが難しい場合もある。レビュアーなどが親切に教えてくれるものをローカルにメモしているが、それも散らばってきたため、ここにまとめることにする。まずは初期状態で公開するが、どんどん更新していき、長くなっても分割しないで追記を繰り返そうと考えている。関連サイト始めて取り組もうとすると、まずどこを見ればわからないところから始まる。似たようないくつかのサイトがあり、使い分けがされているからだ。 code search https://source.chromium.org/chromium/chromium/src コードをインタラクティブに検索するためのサイト Workspace 風の U

peketamin 2024/03/26

リンク

Apple によるブラウザエンジン規制の緩和 | blog.jxck.io

Intro 以前から騒がれていた Apple によるサイドローディング周りの緩和について、正式な情報公開があった。 Apple announces changes to iOS, Safari, and the App Store in the European Union - Apple https://www.apple.com/newsroom/2024/01/apple-announces-changes-to-ios-safari-and-the-app-store-in-the-european-union/ ストアやペイメントの緩和もあるが、ここでは WebKit に関する部分だけを抜粋し、どのような条件があるのかをまとめておく。筆者が公開情報を読んで解釈したものなので、内容は保証しない。前提 iOS/iPadOSに入れられるブラウザには、 WebKit を用いる必要が

peketamin 2024/01/29

リンク

なぜ HTML の form は PUT / DELETE をサポートしないのか? | blog.jxck.io

Intro 10 年ほど前に同じことを調べたことがある。なぜ html の form は PUT / DELETE をサポートしないのか? - Block Rockin' Codes https://jxck.hatena blog.com/entry/why-form-dosent-support-put-delete 当時は全くの素人で、素人なりに調査はしたが、ほとんどが推測の域を出ない結論だった。この問題についてあらためて記す。仕様策定の経緯表題の通り、 <form> の method には GET と POST しかサポートされていない。 HTTP には他にも PUT や DELETE といったメソッドもあるのに、なぜサポートされていないのかという疑問から始まった。仕様が決定した経緯は、以下に残っている。 Status: Rejected Change Descriptio

peketamin 2023/11/28

リンク

ブラウザでリロードしながらキャッシュの挙動を確認してる全ての開発者へ | blog.jxck.io

Intro こういうタイトルを付けるのはあまり好きではないが、あえてこのようにした。「ブラウザでキャッシュがヒットしない」以下は、 Web における Caching の FAQ だ。サーバで Cache-Control を付与したのにキャッシュがヒットしないサーバで ETag を付与したのに If-None-Match が送られないサーバで Last-Modified-Since を付与したのに If-Modified-Since が送られない先日も、筆者が書いた MDN の Cache セクションで「記述が間違っているのでは?」と同様の質問を受けた。 Issue about the Age response header and the term "Reload" · Issue #29294 · mdn/content https://github.com/mdn/cont

peketamin 2023/11/06

リンク

Cookie2 とは何か | blog.jxck.io

Intro タイトルを見て﹁Cookie の新しい仕様か、キャッチアップしよう﹂と思って開いたのなら、以降を読む必要はない。 Cookie History 2000 年に発行された Cookie の仕様である RFC 2965 では、仕様中に Set-Cookie2/Cookie2 (以下 Cookie2) という2つのヘッダが定義されている。しかし 2011 年に改定された現行の RFC 6265 ではそれらヘッダは deprecate されており、実際の Web でこれらのヘッダが交換される場面を、少なくとも筆者は見たことがない。存在すら知らない開発者も多いだろう。筆者はずっと、この仕様がどのように出てきて、どうして消えていったのかが気になっていた。 Web 上にも情報が少なく、﹁歴史上の理由で﹂とか分かったようなことを言ってる人がたまにいるくらいだ。四半世紀前のことなので経緯を

peketamin 2023/08/20

広義のネットワークはみんながプロトコルに基づいて使ったり作ったりしないとワークしないんだなあと改めて思った。/"結果「_理想的で誰も使わない仕様_」ができてしまった"

リンク

Cookie Store API による document.cookie の改善 | blog.jxck.io

Intro JS から Cookie を操作する document.cookie の改善を目的とした Cookie Store API についてまとめる。 document.cookie document.cookie は、ブラウザの API における代表的な技術的負債の一つと言える。 HTML Standard https://html.spec.whatwg.org/multipage/dom.html#dom-document-cookie 基本的な使い方は以下だ。 document.cookie = "a=b" console.log(document.cookie) // a=b まず、この API の問題を振り返る。同期 API 最も深刻なのは、 I/O を伴いながら、同期 API として定義されているところだ。この API は古くから実装されているため、I/O は非同期

peketamin 2023/06/18

リンク

技術書籍をシンタックスハイライトする話 | blog.jxck.io

Intro ﹁連載するけど、代わりにコードはハイライトさせてほしい﹂それが Web+DB Press 編集長に俺が出した条件だった。技術書籍のシンタックスハイライトエンジニアは普段から、エディタ上でも、リポジトリ上でも、ブログ上でも、何かしらハイライトされたコードを見ている。そんなエンジニアに向けて書かれた技術書籍でありながら、書籍のコードがハイライトされているのはみたことがない。﹁技術書籍がシンタックスハイライトされてないのは、出版社の怠慢だ﹂と、割と本気で思っていた。そして、今でも思っている。特にページを跨ぐような長いサンプルコードを、単色で印刷されても、正直読む気になれない。白黒だからしょうがないと思われているかもしれないが、白黒だとしても、文字の太さ、濃淡、フォントの微妙な使いわけなどで、かなり見やすくすることができる。今はやっていないが、このブログでも、印刷用の

peketamin 2023/05/04

あとで読む

リンク

OpenAI API を用いた文書校正(誤字脱字検出) | blog.jxck.io

Intro OpenAI の API を用いて、長年の課題だった文書校正を VSCode 上で実現するプラグインを修作したところ、思った以上の成果だった。文章校正と誤字脱字検出執筆を補助するツールは多々開発されているが、基本は形態素解析を用いた品詞分析の延長で行うものが多かった。よくある﹁助詞の連続﹂、﹁漢字の開き閉じ﹂、﹁一文の長さ﹂などは、ある程度の精度で検出可能ではあるが、結局執筆時に一番検出して欲しいのは﹁誤字脱字﹂だ。文体をどんなに揃えたところで、誤字脱字があるとやはりクオリティが低く感じるし、そこさえ抑えられていれば、他のスタイル統一は訓練である程度なんとかなる。英語のスペルチェックはかなり進んでいるが、日本語においてはそこまで革新的なものが見当たらない。あらゆるツールを試したが、結局満足のいく精度が出る誤字脱字検出は﹁Word の校正機能﹂しかなかった。そこで筆者

peketamin 2023/03/24

_FAV_

リンク

誇りを被った仕様の針に意図を通す | blog.jxck.io

Intro Interop 2022 の目覚ましい成果の一つとして :has() の存在がある。これまでの CSS の限界を突破する、革新的な仕様であり、多くの開発者が期待を寄せる機能の一つだろう。こうした仕様策定の裏には、必ずと言って良いほど互換性の問題がつきまとい、時にそれはそこまでの作業の蓄積を無に帰すレベルで影響を与える場合がある。一方それらは Web 開発者が使う時点では解決されており、基本的に気にされることはない。だからといって、気にする必要がないわけではない。ということを象徴する事件が、今回も裏で起こっていた。 jQuery と :has() :has() は、従来の CSS Selector の常識を変え、子の状態を元に親をクエリすることが可能となった。親から子を見る場合と比べて探索範囲が爆発的に増えるため、非常に実装が難しいとされていた。 Igalia の詳細な調

peketamin 2023/03/02

あとで読む

リンク

次世代 CSS 仕様が与えるコンポーネント時代の Web への影響 | blog.jxck.io

Intro SPA の隆盛で進化したフロントエンドライブラリによって生み出された「コンポーネント」という資産は、それを View 層の最小単位として扱うエコシステムにその重心をずらした。近年の Web 開発は、虫食いのテンプレートエンジンにデータをはめ込む方式から、デザインシステムにカタログされたコンポーネント群に、 API から取得したステートを流し込み、それらを「いつ、どこで、どう」レンダリングするかという課題への最適解を、各位が模索するフェーズとなっている。コンポーネントを敷き詰めるコンテナ側の設計は、 Flexbox および Grid の登場によるレイアウトの進化が手助けしたところも多いにある。しかし、「ページ」を前提に設計された CSS は、「コンポーネント」を前提にした設計に移行するうえで、ミッシングピースが多かった。現在、提案/実装が進んでいる CSS の新機能群には、

peketamin 2023/01/08

リンク

XMLHttpRequest とはなんだったのか | blog.jxck.io

Intro FetchAPI の実装が広まり、IEもリタイアを迎えたことで、今後忘れ去られていくことになるだろう XMLHttpRequest について。どのように始まり、どのように広まり、どのように使われなくなっていくのか。その間に残した多大な功績を残す。 XMLHttpRequest の始まりこの名前は非常に長いため、通常 XHR と略される。この API は、現在の Web API のように W3C/WHATWG による標準化を経て策定された API ではない。 Microsoft によるいわゆる独自実装の API として始まり、後追いで標準化される。したがって、 Web API の中でもかなり異質な命名である XHR が、 XmlHttpRequest でも XMLHTTPRequest でもなく XMLHttpRequest である理由も、 Microsoft の命

peketamin 2022/10/02

自分も似たようなこと思った。

リンク

HTTP 関連 RFC が大量に出た話と 3 行まとめ | blog.jxck.io

Intro 2022/06/06 ~ 9 あたりに、長きに渡って策定作業が行われていた HTTP 関連の RFC が大量に公開された。 RFC 9110: HTTP Semantics RFC 9111: HTTP Caching RFC 9112: HTTP/1.1 RFC 9113: HTTP/2 RFC 9114: HTTP/3 RFC 9163: Expect-CT Extension for HTTP RFC 9204: QPACK: Field Compression for HTTP/3 RFC 9205: Building Protocols with HTTP RFC 9209: The Proxy-Status HTTP Response Header Field RFC 9211: The Cache-Status HTTP Response Header Field

peketamin 2022/06/16

リンク

Navigation API による「JS での画面遷移」と SPA の改善 | blog.jxck.io

Intro 従来の History API を改善する Navigation API の仕様策定と実装が進んでいる。これは、 History API の使いにくかった部分を補うだけではなく、﹁JSで画面遷移をする﹂という現状のミッシングピースに取り組み、 SPA が抱える多くの問題だけでなく MPA すら改善する可能性がある。この API の目的と仕様を解説しつつ、実装のメモを残す。画面遷移と SPA の軌跡 Web は HTML の取得と描画を繰り返す、画面遷移(Navigation)を前提としたアーキテクチャ(のちに SPA からの逆算で MPA と呼ばれる)が基本であり、ブラウザなどの実装もそれに最適化されている。一方﹁アプリケーション﹂の設計手法をそのまま Web に持ち込んだ SPA は、この Navigation によってもたらされる UXの低下を防ぐ部分がある一方

peketamin 2022/04/22

リンク

Web のセマンティクスにおける Push と Pull | blog.jxck.io

Intro 筆者は、 Web のセマンティクスに対する実装の方針として、大きく Push 型の実装と Pull 型の実装があると考えている。もっと言えば、それは実装方法という具体的な話よりも、開発者のセマンティクスに対する態度を表現することができる。この話は「Push よりも Pull が良い」などと簡単に切り分けられる話ではない。「自分は今 Push で実装しているのか、 Pull で実装しているのか」この観点を意識するかしないかによって、セマンティクスに対する視野が広くなり、その応用として、たとえば今自分が行っている実装が、将来の Web においてどのような互換性の問題を生じるかなどを想像できるようになるだろう。最近問題になる Ossification を、こうした視点の欠如の結果とみることもできる。 (本エントリでの Ossification は、一般に言われている Pro

peketamin 2021/12/08

リンク

Private Relay と IP Blindness による Fingerprint 対策 | blog.jxck.io

Intro iOS15 がリリースされたため、 Private Relay のベータを試すことができた。このようなサービスが提供されるようになった背景を踏まえ、挙動を簡単に確認しつつ、解説する。背景そもそも、なぜこのようなサービスが出てきたのかを理解するには、現在のインターネットが抱える問題の背景を理解する必要がある。特に Web において問題になっている﹁トラッキング﹂を防ぐために、法的な規制や業界団体の自主規制による対策は長いこと行われてきたが、それでも看過できないインシデントなどが目立ったために、 Apple の ITPを皮切りに 3rd Party Cookie の制限が始まった。ここで重要なのは、﹁本来防ぎたいのは 3rd party Cookie という技術ではなく Tracking というユースケースだ﹂という点だ。この前提が伝わっていない場合、トラッキングのユ

peketamin 2021/09/23

リンク

Cross Origin iframe からの alert/confirm/prompt 呼び出しの無効化 | blog.jxck.io

しかし、実際に M92 がリリースされてからは、この機能が壊れたことによる影響が多数報告されていたため、実装者が想定していた以上に影響はあったといえるだろう。他のブラウザの反応実際にロールアウトしたのが Chrome/Edge であったため、いつものように﹁また Google が勝手にやっている﹂と思う人もいるようだが、実際には他のブラウザも Positive を表明している。 Firefox: https://github.com/whatwg/html/issues/5407#issuecomment-606417807 Safari: https://github.com/whatwg/html/issues/5407#issuecomment-760574422 また、この合意が取れているため、既に仕様にもマージされている。 Add early return to JS dia

peketamin 2021/08/03

リンク

本サイトの AMP 提供の停止とここまでの振り返り | blog.jxck.io

Intro 前回の記事で、奇遇にも本サイトの AMP 対応を落とすことになった。しかし、そうでなくても AMP をどこかでやめることは考えていたため、きっかけの一つが SXG 対応になったのは、順当な流れだと筆者は感じている。これは AMP がなぜ始まり、なぜトーンダウンしつつあるのか、そしてこれからどうなっていくのか、という流れをまとめるいい機会でもある。その過程で生み出され、本サイトでも検証を続けてきた Performance Timing API, Core Web Vitals, Signed HTTP Exchange 、そして今構想されている Bento AMP などを踏まえ、一連の流れを覚えている範囲で記録としてまとめておく。ソースは筆者の主観であり、眺めてきた体感を mozaic.fm の Monthly Web などで話してきたものがベースなので、信頼性や正確性は期

peketamin 2021/06/27

リンク

はてなブックマーク

タグ

ブックマーク / blog.jxck.io (51)

お知らせ

今週のはてなブックマーク数ランキング（2024年7月第3週）

今週のはてなブックマーク数ランキング（2024年7月第2週）

はてなブックマーク透明性レポート（2024年 2月-2024年4月）

公式Twitter

キーボードショートカット一覧

はてなブックマーク

公式Twitter

はてなのサービス