Intro 従来の History API を改善する Navigation API の仕様策定と実装が進んでいる。 これは、 History API の使いにくかった部分を補うだけではなく、「JS で画面遷移をする」という現状のミッシングピースに取り組み、 SPA が抱える多くの問題だけでなく MPA すら改善する可能性がある。 この API の目的と仕様を解説しつつ、実装のメモを残す。 画面遷移と SPA の軌跡 Web は HTML の取得と描画を繰り返す、画面遷移(Navigation)を前提としたアーキテクチャ(のちに SPA からの逆算で MPA と呼ばれる)が基本であり、ブラウザなどの実装もそれに最適化されている。 一方「アプリケーション」の設計手法をそのまま Web に持ち込んだ SPA は、この Navigation によってもたらされる UX の低下を防ぐ部分がある一方
今年もChrome開発者の集まりChrome Dev Summit 2019 (CDS) がサンフランシスコで開催されました。 今回、私が Chrome Customer Advisory Board (CAB) に選出していただいたこともあり、CDSに初めて参加しました。 これは、CDS終了後のCAB meetingで頂いたChrome Dinosaurフィギュアです。ちなみにゲームはできません。 タイトルの「なぜChromeはURLを殺そうとするのか？」は、2日目Chrome Leadsのパネルセッションで司会のGooglerが、Chrome UX担当のProduct Managerに対して一番最初に投げかけた問いです。 PMは直ちに「そんなことはしない」と即答しました。しかしChromeは、URLの表示領域からHTTPSの緑色表示の廃止・EV表示場所の移動・wwwサブドメイン表示の削
1996年にcurlプロジェクトの先駆けとなるhttpgetを始めたとき、私は初めてURLパーサを書きました。当時はまだ、ユニバーサルアドレスは URL : Uniform Resource Locators と呼ばれていました。その仕様は1994年にIETFによって発行されたものでした。この”URL”という用語からインスピレーションを得てツールとプロジェクトに命名したのが curl でした。 URLという用語は後に事実上、 URI : Uniform Resource Identifiers (2005年発行)に変わりましたが、「オンラインでリソースを指定する文字列のための構文と、そのリソースを得るためのプロトコル」という、基本的な点は変わりませんでした。curlでは、この構文仕様RFC 3986の定義に従う”URL”を許容するとうたっていますが、それは厳密には正しくありません。その理由
同一ページ内をスクロールしているだけなのに、ブラウザのアドレスバーに表示されている URL が変わるサイトを見かけることが増えてきました。調べてみると HTML5 の History API を使えばそういった挙動を実現できるようで、非同期通信を利用しているサイトなどで適切に利用すれば便利な機能です。 ただ、ページ内をスクロールしているだけなのにいつの間にか URL が変わるという挙動は、時に困った事態に遭遇します。 昨日「Webアプリで音楽を楽しく学べる「Chrome Music Lab」 – ITmedia ニュース」という記事内からリンクされている「Chrome Music Lab」というサイトを見つけました。実際に Chrome Music Lab のトップページを下にスクロールしたり上にスクロールしたりすると、セクションに合わせて URL が切り替わっているのが分かると思います。
Theme 第 20 回のテーマは Browser です。 今回は @takoratta さんをお迎えして、ブラウザは今どうなっているのか、そして、その進化は Web の進化とどう関わっているのかにつて議論しました。 Show Note 及川さんとブラウザの関わり JUNET NCSA Mosaic Netscape DHTML ActiveX なぜ新しくブラウザが必要だったのか? living on the web IE Toolbar V8 成せたこと成せなかったこと Hosted App と Packaged App Chrome Web Store Gears ブラウザはここ数年でどう変わったか? PhoneGap Cordova Electron Extensible Web ブラウザの肥大化問題 TPAC 2015 IETF 94 Chrome Dev Summit Chrom
はじめに こんにちは、Go界のエビスビールです。今日、法政大学外壕校舎で開催された次世代Webカンファレンスに聴衆として参加してきました。 次世代 Web カンファレンス - connpass 以下自分のメモです。 server_perf (10:00-11:00) #405 メモ パフォーマンスの勘所としてクライアント側の変化があると思う @mirakui: スマホのWebとアプリの比率があがってる @xcir: デスクトップからのリクエストは減って、スマホのネイティブアプリでの処理が増えている。APIアクセスが主。 @cubicdaiya: Webからのリクエストが1割もなくて、ほぼネイティブクライアントからのリクエスト。15000qps。 APIリクエストが主になったことによりJSONのやり取りだけの単純なものになったが、リクエスト数は増えた。 高速化しにくい部分をどうパフォーマンス
JavaScriptで動的にリンクを生成する際に、DOM-based XSSを防ぐためにリンク先がhttpあるいはhttpsに限定されていることを確認したい場合がある。典型的には以下のようなコードとなる。 var div, elm; // 変数 url は攻撃者がコントロール可能な文字列 if( url.match( /^https?:\/\// ) ){ div = document.getElementById( "info" ); elm = document.createElement( "a" ); elm.setAttribute( "href", url ); elm.appendChild( document.createTextNode( url ) ); div.appendChild( elm ); } この場合、変数urlに「http://example.jp」や「
Googleが昨年12月から一部のユーザーを対象に、WebページのURLがアドレスバーに表示されないGoogle Chromeのテストを行っているそうだ(CNETの記事、 HotHardwareの記事、 本家/.)。 テスト中のバージョンではOmnibox(アドレス/検索ボックス)の隣に「origin chip」と呼ばれるUI要素が追加されており、ここには表示しているWebページのドメイン名のみが表示される。Omniboxにはこれまで通り語句を入力して検索したり、URLを入力してWebページを表示させたりすることが可能となっているが、実際のURLは表示されない。URLをOmnibox内に表示させるには、origin chipをクリックするか、CTRL+L/Command+Lキーを押す必要がある。実際に使用しているドメイン名が明確になることでセキュリティ上の問題が起こりにくくなるという見方も
「僕らが大好きだったWebはなくなるのかもしれない」において、「Webページ／Webサイトから構成される従来型のWebはなくなるのではないか」と述べました。 ここで、極端な想定として「Webブラウザが消滅してしまった」としましょう。これは、あくまで想定であって、未来予測をしているわけではありません。 汎用のブラウザに代わるのは、個別の機能を持ったアプリ群です。これらのアプリ（の多く）は、通信のインフラとしてインターネットを利用するので、インターネットはやはり必須で重要な存在です。 ブラウザがなければ、Webページから構成されるWebサイトは意味を持ちません。Webサイトはアプリのリモートバックエンドに置き換えられ、Webページはアプリの状態に取って代わられます。 アプリとそのリモートバックエンドは通信をするのでプロトコルが必要です。そのプロトコルは、HTTP（の発展形）がやはり主流でしょう
最近、GmailやGoogle Calenderにアクセスすると以下のようなダイアログが表示されることに気づいた方も多くいらっしゃるのではないでしょうか。 「Gmailでメールリンクをすべて開くようにしますか？」というこの問いに「はい」と答えると、以降、「mailto:」 で始まるリンクをクリックするとGmailが立ち上がるようになります。 この「mailto:」とGmailの紐付けは、Google Chromeであれば「環境設定→高度な設定→コンテンツの設定→ハンドラを管理」というメニューを開くと確認・管理することができます。一度紐付けたアプリを削除したり、他のアプリに変更することもできます。 こんな面白い仕掛け、どうやって実現しているのでしょう？ それは、HTML5から利用可能になったnavigator.registerProtocolHandler() を使うとこういうことができます
ロケーション・ハック (location hack) とは汎用ユーザー・スクリプトを開発する上で（残念ながら）ほぼ必須となる方法のことである。紹介元の記事は英語だが、対応する日本語はなさそうなので、そのままカタカナにした。 ユーザー・スクリプトの通常の役割は DOM ツリーをいじることだが、場合によってはページ側で動いている JavaScript の動きを変更したい場合がある。変数の値を書き換えたり、ページ側で定義されている関数を呼んだりする場合だ。 残念ながら、これらは簡単にはできない。セキュリティ対策のため、サンドボックス (sandbox) と呼ばれる専用の環境でユーザー・スクリプトが実行され、コンテンツ・スコープ (content scope) で実行されているページ側のデータにアクセスできないようになっているからだ。 このあたりの実装はブラウザによって異なるので、主要ブラウザでテ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く