Webブラウザは、現代のコンピューティング環境において欠かせない存在であり、最も広く使われているプラットフォームの一つです。本書は、その仕組みを実践的に学ぶための解説書です。実際にWebブラウザを構築する過程をたどりながら、レンダリング、HTMLパーサー、CSS、JavaScript、マルチスレッド対応、セキュリティモデル、アニメーションとコンポジット処理、ブラウザAPI、アクセシビリティなど、モダンなWebブラウザの主要な要素を順を追って解説していきます。 章ごとにコードを動かしながら、ブラウザに機能が積み重なっていく過程を通じて、ソフトウェアを成長させ改善していく経験を自然に体得できます。ブラウザ技術の研究者とChrome開発者による豊富な知見をもとに、Webの進化をたどりながら、手を動かしてブラウザの内部構造を深く理解できる一冊です。 はじめに 第1部 序論 序章i ブラウザとWeb
Intro 4 月末にリリースされる Chrome 136 からは、一部のケースで「閲覧履歴があってもリンクの色が変わらない」状態が発生する。 もしこの挙動に依存して閲覧をしているユーザがいれば、多少不便に感じるかもしれない。 しかし、これは長年問題視されてきた、ユーザのプライバシー保護のための更新だ。 ユーザ側でも、「サイトが壊れたのでは?」と思う人もいるだろうため、前半は技術用語を少なめに解説し、エンジニア向けの解説は後半で行う。 従来の挙動 例えば、Wikipedia では、リンクをクリックして閲覧先を確認すると、閲覧済みのリンクの色が変わる。 これは、ブラウザに保存された閲覧履歴に該当するリンクの色を、訪問済みとして変えるブラウザの機能だ。 多くのリンクがある場合、確認済みかどうかがわかるために、便利に使われることもあるだろう。 (最近では、閲覧済みでもリンクの色を変えないように実
Intro Ladybird は、他のブラウザエンジンをフォークせず、企業との取引に頼らず、寄付だけで作ることを宣言した新しいブラウザエンジンだ。 Ladybird https://ladybird.org/ これがいかに価値のある取り組みなのか、Web を漫然と眺めてきた筆者による N=1 の妄言を書いてみる。 ブラウザエンジンとは ブラウザは、「ブラウザ UI」と「ブラウザエンジン」と、大きく二つの構成要素に分けて考えることができる。 ブラウザエンジンとは、いわゆる Web 標準の技術を片っ端から実装した、ブラウザの土台となるものだ。 ビルドすれば、入力した URL からネットワーク経由でリソースを取得し、パースしてレンダリングして表示できる。そのための IETF RFC や WHATWG HTML や ECMAScript が実装されている、標準技術の結集だ。 その上に、例えばタブを
Safari 16.4 rolled out last week, and for us it's been a nightmare. We make the browser-based game creation app Construct. Early versions of Safari 16.4 broke opening projects, previewing projects, and all existing content published with Construct, all in different ways. I wanted to share our experience so customers, developers, regulators, and Apple themselves can see what we go through with what
How do you take a popular developer platform, free and maybe even open source, and build a strong business around it? Wait a minute, did she just say ‘developer’, ‘open source’ AND ‘business’ in the same sentence? I must warn you – this article is not about web performance insights or web development, but rather […] Largest Contentful Paint (LCP) is a performance metric representing the user exper
はじめに こんにちは。バックエンドエンジニアの小笠原です。 今回は、2022年2月18日から2022年3月4日にかけて発生していたこちらの障害に対し私達開発チームが実施した、session.cookieで定義しているCookieのkey名を変更するという影響範囲の大きい対応について、実施に至るまでの経緯や対応過程についてご紹介したいと思います。 ショップオーナー向けに掲載していたお知らせの内容 背景 全ては iOS14.5から端末識別子の取得に同意が必要になったことから始まった ことの発端は、iOS14.5以降からIDFA（端末ごとに持つ固有識別子）の取得に端末所有者の許可が必要になったことでした。 この変更は、端末所有者側から見ると情報の活用範囲を自身で管理できることでよりプライバシーに配慮されるようになった良い変更と言えるでしょう。 一方で、広告出稿側から見た場合は拒否をしたユーザーの
2022年になりました。矢倉眞隆（@myakura）と申します。昨年に引き続き、新春特別企画のブラウザとウェブ標準を担当させていただきます。 なお、取り上げるトピックの数やインパクトの大きさもあり、CSSについては別記事となりました。あわせて読んでいただければ幸いです。 ChromeとFirefoxがバージョン100に到達 昨年の新春企画でもすこし触れましたが、今年はChromeとFirefoxのバージョンが100になります。 Chrome 100は、今年の3月29日にリリース予定です。もともとはもう少し先だったのですが、Chrome 94からリリースサイクルが4週間に短縮されたため、Chrome 100のリリースが早まりました。 Chromeよりも早く4週間のリリースサイクルに移行していたFirefoxも、5月3日にFirefox 100がリリース予定です。 バージョンが3桁になることで
There's been a lot of discussion recently about how "Safari is the new IE" (1, 2, 3, 4, 5). I don't want to rehash the basics of that, but I have seen some interesting rebuttals, most commonly: Safari is actually protecting the web, by resisting adding unnecessary and experimental features that create security/privacy/bloat problems. That is worth further discussion, because it's widespread, and w
しかし、実際に 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
紙書籍をお届けします（PDFがついてきます） PDFのみ必要な場合は、こちらからPDF単体をご購入ください 紙書籍は通常、ご注文から2～3営業日で発送します 年末年始や大型連休など、1週間から10日程度、配送のお休みをいただく場合があります。詳しくはお知らせをご覧ください ブラウザの視点で学ぶセキュリティ 米内貴志 著 224ページ A5判 ISBN：978-4-908686-10-8 2021年1月5日 第1版第1刷 2022年8月16日 第1版第3刷 発行 正誤情報 サンプルコードなど 現代のWebブラウザには、ユーザーがWebというプラットフォームを安全に利用できるように、さまざまなセキュリティ機構が組み込まれています。 リソース間に境界を設定し、アプリケーションに制限を課す機構（Origin、SOP、CORS、CSPなど） Webブラウザの動作をOSのプロセスレベルで考察することで
Intro Web の https 化が進み、それに伴って https を前提とする API も増えてきた。 そうした API を用いた開発をローカルで行う場合、localhost という特別なホストを用いることもできるが、それだけでは間に合わないケースも少なからずある。 localhost を https にするという方法もあるが、そのように紹介されている方法には、いくつか注意すべき点もある。 この辺りの話を、直近 1 ヶ月で 3 回くらいしたので、筆者が普段使っている方法や注意点についてまとめる。 特に推奨するつもりはない。 Update chrome の --host-rules について追記 localhost での開発の注意点 例として https://example.com にデプロイする予定の ServiceWorker を用いたアプリがあったとする。 開発をローカルで行う場
On the 11th of January 1982 twenty-two computer scientists met to discuss an issue with ‘computer mail’ (now known as email). Attendees included the guy who would create Sun Microsystems, the guy who made Zork, the NTP guy, and the guy who convinced the government to pay for Unix. The problem was simple: there were 455 hosts on the ARPANET and the situation was getting out of control. This issue w
投機的なWebの修復
先日Mozaic.fmでCross Origin Info Leaksについて話しました。 ep63 Cross Origin Info Leaks 雑談編（こちらはプラバシーや新しいEdgeなどセキュリティとは関係ない雑談です） ここではMozaicで話した事をまとめてみたいと思います。 スペクターとはなんだったのか 何が直ったのか 何故ブラウザの問題は残っているのか ブラウザはどの様な対策をとったのか ブラウザの対策は十分だったのか Site Isolationとは Cross-Origin Read Blockingとは Cross-Origin Resource Policyとは Cross-Origin Embedder Policyとは Cross-Origin Opener Policyとは Securer Contextとは スペクターとはなんだったのか スペクターはCPU
ご無沙汰しております。ウェブボウズを立ち上げて 1 年が経ちました。皆さま如何お過ごしでしょうか。私は、この 1 年間ひとつもブログポストできていません。さらには私の坊主頭（スキンヘッド）にちなんでウェブボウズという名前をつけた個人ブログでありましたが、5 年間共にしたこの Hair-less style から心機一転して 2019 年は髪を育んでいく方針を固めましたので、もはやボウズでもなくなってます。変わり続けることだけが普遍であると胸に刻んで今年も強く生きていきたいと考えております。 さて、最近 Signed HTTP Exchanges やら Performance Budget やらさまざまな面白いことに関わらせていただいて忙殺と幸せを噛み締めている中でも、Chrome Dev Summit 2019 でも大きくフィーチャーされました Portals という新しい HTML 要素
Edge Web Technologies and Browser Vendors (Updated on 2016/09/06)AI-enhanced description The document covers a comprehensive range of HTML5 and ECMAScript 2015 features, including elements, syntax, and APIs like Web Workers, Canvas, and WebSockets. It also discusses multimedia content models, forms, and storage mechanisms, along with various CSS properties and enhancements for user interfaces. Fur
Chrome Dev Summitに来ている。 今年のChrome Dev Summitは日ごとにテーマが分かれていて、初日がProgressive Web Apps、2日目がRAILらしい。RAILはGooglerがちまちまと話してるけど、前者についてはまだそんな離されてない気がする。 というわけでセッション聞きながらなんとなく書いてみよう（なのでセッションまとめではないよ）。 アプリに「なっていく」「Web」 Progressive Web Appsは、Alex Russell先生が6月にブログで提唱して、そこからプロモートしているもの。“progressive”を訳すと「漸進的」やら「進行性」とかになるけれど、そのまま訳すより「アプリになっていくWeb」と砕いて解釈するとわかりやすそう。 アプリに「なっていく」とは何かなんだけど、Webアプリが「使ってるうちにネイティブアプリと同じよ
なぜなに篇とWebプラットフォーム篇ではBlinkに至った背景や、Blinkの互換性への取り組みについてだーっと書いた。 今回はBlinkの登場が何にどんな影響を与えるか、だらだら考えてみる。 Chrome すでに色々書いてはいるけれど。 WebKitから離れ、Chrome専用エンジンとなるので、これまでWebKitでは合意を得られなかった機能について抵抗なく入れられるのはGoogleにとってはよいことだろう。Pointer EventsとかIME APIとか。Launch Processのもとでだけど、試験実装は進めやすくなる。 WebKitから離れることでの最大の損失は、WebKitに参加している人のタレントだろう。BlinkチームのQ&Aセッションによると、BlinkとWebKitとの間に「フォーマルな関係」はないとのこと。パッチを自動的にやりとりするような仕組みは用意されないから、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
