iPadにおけるデスクトップクラスのブラウジング

(音楽)

(拍手) おはようございます セッション203へようこそ Introducing Desktop-class Browsing on iPadです 私はチャールズ･イン Safari WebKitチームの ウェンソン･シェイと ベス･デーキンも登壇します

今日は デスクトップクラスの ブラウジングについてご紹介します iPadのWebプラットフォームが 大きく進歩したのです 基調講演のとおり iPadOSのSafariは デスクトップクラスになりました

これは つまり―

Safariでできることが増えたのです 今後 Webで行う多くのことに Safariが使えます

ダウンロードマネージャとして 他のタブやアプリケーションの使用中に ダウンロードや アップロードができます

新しいコントロールで 全画面ズーム表示をしたり 画面を広く使うために ツールバーを隠したりできます ワークフローに合わせた サイトごとの設定もできます

そして デスクトップブラウザに 期待される― キーボードショートカットも装備 これで効率がよくなり 作業に集中できます

何より デスクトップ用Webサイトが 閲覧できます

私たちは長い間 Webブラウザを開発してきました 初代iPhoneの頃は どのサイトも巨大で マウス入力向けでした

iPhoneでは 小画面やマルチタッチに サイトが対応していなくても 閲覧や入力ができるようにしました

iPhone側で 表示を縮小し テキストを大きくしたのです

その後 デベロッパが 新しいWeb APIを使い iPhoneを最大限に生かせるサイトを 作り始めました そして最高の結果が生まれます

レスポンシブデザインを活用し どの画面サイズにも 柔軟に対応するサイトが出てきました そうしたサイトは今 iPadで美しく見えます

しかし サイトに２バージョンあるのも 一般的になりました 大画面用と小画面用の ２バージョンです

iPadのユーザエージェントは モバイルなので Webは小画面表示です そこで 新しいiPadOSでは サイトにMacとして認識させます

ユーザエージェントだけでなく WebKitレベルの深さでの 根本的な変更です これで体験が改善されます 詳しく説明しましょう

デスクトップ用サイトは 大画面で 多くの情報を表示する設計です

こうしたサイトは iPadではズームされ デスクトップと同じようには見えません 従来 WebKitが使うビューポートは 全iPadで同じでした 最小のiPad miniから 最大のiPad Proまで同じです

新しいiPadOSでは ビューポートは iPadの画面サイズと一致します よって 大きなiPadでは サイトが幅広く見えます 小さなiPadでは サイトを縮小し すべてを画面に収め iPhoneのように 文字を大きく 読みやすくします デスクトップと同様に 多くの情報が一度に見えるので 作業がしやすいですね

また マウス入力向けに 設計されたサイトは 新しいiOS 13搭載のiPadでは タッチ入力をマウス入力に応用できます マウスホバーを使う こういうサイトにも対応できるのです

ポインタイベントは WebKitなどでも使えます

皆さんのWebアプリケーションで 新たに生かせるようになった― 新iPadOSのWeb APIや 機能の一部をご紹介しました 詳細は後ほどベスからお話しします

これで 新しいiPadではさらに 強力なブラウジング経験ができます それが新iPadOSの デスクトップクラスブラウジングです

次に… (拍手) 皆さんのアプリケーションや Webサイトで 新機能を存分に活用する方法を 紹介します アプリケーションのデベロッパには デスクトップクラスブラウジングの 活用法を見せます Webデベロッパには サイトの見栄えを iPadでさらによくする方法を伝授します まずアプリケーションです

アプリケーションが Webビューを使う例は主に４つ アプリケーション内で Webに飛ぶリンクがある場合 Web閲覧が アプリケーションの目的の場合 アプリケーションのUIに Web技術が入っている場合 サードパーティサービスで OAuthを使ってユーザ認証する場合です 第１に リンクをたどる場合

リンクをたどりつつ アプリケーション内にとどまるには Safari View Controllerが最適です Safari View Controllerには 自動入力やリーダーなど 秀逸な機能が備わっています もしSafari View Controllerを 使っているなら デスクトップクラスブラウジングが ついてきます 追加作業は不要です

SafariとSafari View Controllerが 自動的にモードを選ぶので 状況に合った 最適なブラウジングができます 説明しましょう

iPadは ネットブラウジングに 最適なデバイスです Webを手に持つような感覚です iPadの使い方は 目的によって様々でしょう

デスクトップ用サイトは iPad miniでは小さすぎて モバイル用サイトの方が 読みやすいかもしれません

デスクトップ用サイトを 狭いSplit Viewや Slide Overで見る場合も同様です

このように ウィンドウが狭い場合は モバイル用サイトがいいでしょう SafariとSafari View Controllerなら 自動で最適なモードを選んでくれます

Safari View Controllerが 全部 勝手にやってくれます 第２に アプリケーションが Webブラウザの場合です まずアプリケーションを iOS 13 SDKで構築し デスクトップクラスの ブラウジングを有効にします そしてユーザエージェントの設定を 確認します customUserAgentプロパティを 使っていますか？ 代わりに WKWebViewの― applicationNameForUserAgent プロパティを勧めます アプリケーション名を入れれば WebKitが残りを埋めてくれます

WKWebViewも 新しい WKWebpagePreferences APIで 優先するブラウジングモードを 設定します モードは３つ Safariに従う推奨と モバイル そしてデスクトップです 一般的にはSafariに従う 推奨モードを勧めます

ユーザに切り替えを 許容するケースもあるでしょう モバイルか デスクトップか サイトごとに決めるかです

その場合 WebKitに新しく導入した WKNavigationDelegate APIで ナビゲーション時に 好きなモードを指定できます

後ほど ウェンソンが 新APIのデモをします

第３に Web技術が― アプリケーションのコンテンツやUIの 一部として使われている場合です

WKWebViewを使っているなら iOS 13 SDKでアプリケーションを構築し デスクトップクラスブラウジングを 有効にします そしてWKWebViewの動作テストをします

通常はそれで終了です まれに ビューポートの サイズ設定を外し 優先モードをモバイルにすべき場合も

全般的に 大半の作業は WKWebViewがします

そして第４に…

サードパーティサービスで OAuthを使ってユーザ認証する場合です その場合 ASWebAuthenticationSessionを 使うのが最善でしょう 新iPadOSでは ASWebAuthenticationSessionで フォームシートを表示できます これで アプリケーション内で 認証インターフェイスを出せます これにより ASWebAuthenticationSessionが モバイルコンテンツモードで サイトを読み込みます Safari View Controller同様 このAPIを使えばお任せです

まとめると Safari View Controllerと ASWebAuthenticationSessionが 面倒な作業をしてくれます WKWebViewを使っている場合も 必要なツールがそろっています ではウェンソンに デモをしてもらいましょう ウェンソン？ (拍手)

ありがとう　チャールズ 私はふだん Webブラウザを作っています 息抜きをしたい時は さらにWebブラウザを作ります 今日 紹介するのは Shinyというブラウザで―

WKWebViewベースのブラウザです Googleドキュメントに アクセスした画面がこちら 友人とGoogleドキュメントで 共同作業をする際に 自分のブラウザを使いたいのです しかし 見てのとおり アプリケーションを入れろと言われます デスクトップ用サイトを要求すれば 全機能が使えるはずです 先ほどチャールズが言ったように iOS 13を搭載したiPad Proなら WKWebViewがデフォルトで デスクトップ用サイトを要求します よって私のブラウザを iOS 13 SDKでリコンパイルすれば デスクトップ用サイトが出るはずです 画面をXcodeに切り替えます Command+Rで実行 これでリコンパイルが済み― デスクトップ用サイトが 見られるはずです

残念ながら まだモバイル用なので デバッグしましょう 客観的に考えてみます Googleドキュメントは ブラウザがモバイルだと判断する際 user-agent文字列を 使っているのでしょう そこでWebインスペクタを使って user-agent文字列を表示し 現状を把握することにします ではまず Safariを立ち上げて 開発メニューに行き Shinyブラウザのページを指定

コンソールタブに切り替えて navigator.userAgentと入力し Enterキーを押します ズームインしましょう ここに注目すべき記述が まずiPadという文字が入っています デスクトップクラスではありません “Version/1.0 ShinyBrowser/1.0”とも 不可解ですね これはどこから？ 解明したいので この記述をコピーし Xcodeで検索します 検索フィールドにペースト

なるほど 分かりました user-agent文字列を オーバーライドしている― customUserAgentプロパティが ありました 過去にネットからコピペして 忘れていたようです 当時はこの解決策も有用でしたが 先ほどチャールズに 別の策を聞きましたね WKWebViewコンフィギュレーションの プロパティに アプリケーション名を使うのです その方法に変更してみましょう まず customUserAgentのコードを削除し webViewの所に行きます どうするかというと…

WKWebView コンフィギュレーションを作り applicationNameForUserAgentを設定 “Version/1.0 ShinyBrowser/1.0”です そして このコンフィギュレーションで webViewを作るのです わずかな調整でした アプリケーションをリコンパイルし 結果を見ましょう

ご覧のとおり Googleドキュメントが表示されたので 友人との共同作業ができます 簡単でしたね もう一歩 踏み込みましょう 以前から要望があったのが デスクトップ用とモバイル用の 表示を切り替える機能です iOS 13の新しいAPIでは これが実装しやすくなりました お見せしましょう まず 右上角のボタンに 注目してください “お気に入りに追加”“シェア”の オプションがあります ここに３つ目のオプションを加えます コンテンツモードを 変えるオプションです モバイル用サイトか デスクトップ用サイトを選べます Xcode画面に切り替え 実装しましょう 下に行くと― UIAlertActionsの一覧を示した ヘルパー関数があります 現在あるのは“お気に入りに追加”と “シェア”の２つです ここに３つ目のアクションを足します その前に 新しいヘルパー関数を作ります これでUIAlertActionが作れるので 上に追記します

これでアクションが作れます currentContentModeという インスタンス変数にご注目を ここで 現在のコンテンツモードが デスクトップかを確認しています 例えばデスクトップなら 文字列は “モバイル用サイトを表示”ですね

これで大丈夫ですが 問題は currentContentModeを どう判定するかです 少し下に行くと― ここにWKNavigationDelegateを 実装しています didCommit navigationメソッドです ここでiOS 13の新しいAPIを使うのです iOS 13では WKNavigationには effectiveContentModeという 新しいプロパティがあります モバイルとデスクトップの２択なので 今回の用途に最適です “currentContentMode = navigation.effectiveContentMode”で ナビゲーションにコミット これで読み込み中のコンテンツの モードが判別できて 正しい文字列が出るはずです ところで このアクションハンドラに 改めて注目を ホスト名に対し どちらのモードを優先するか 指定する方法が必要です そこで ホスト名のディクショナリに コンテンツモードを保存します ユーザがタップしたモードを 保存するのです では 実装しましょう 単にホスト名を取得し “モバイル”か“デスクトップ”と ディクショナリに入れるだけです そしてビューをリロードさせます このcontentModeToRequestForHost ディクショナリは 別の所でも使います 下の WKNavigationDelegateに 新しいメソッドを足します decidePolicyFor navigationActionを 実装するのです 見慣れたバージョンに 似ていると思いますが iOS 13ではウェブページの選択が 引数として入っています “preferences:”の所です ここで“preferences. preferredContentMode = ”とし 参照したディクショナリと 同じモードにします このcontentModeToRequestForHost ディクショナリは 少し前にアクションハンドラで 追加したのと同じです そして最後に― この新しい選択で decisionHandlerを呼び出します これで大丈夫 アプリケーションをリコンパイルし 確認しましょう

Googleドキュメントでなく 画像ギャラリーで確認します Shiny Picsというサイトの デスクトップ版です Extrasメニューを使い モバイル用サイトを要求します

これがShiny Picsの モバイル用サイトです いかにもモバイル版ですよね iPad Proでなく携帯電話向けに ページが最適化されています iPad ProでShiny Picsを見るなら デスクトップ版にしたいです そこで“デスクトップ用サイトに 切り替え”を選び デスクトップ版に戻します まとめると まずブラウザを デスクトップ版の読み込みに対応させ 新しいAPIを使い モードを切り替える機能を実装しました ここまでは アプリケーションデベロッパ向けの話で Webデベロッパ向けの話もあります そちらは ベスから 話してもらいましょう (拍手) ウェンソン すばらしい話をありがとう

さて Webデベロッパにとっての 変化とは？ レスポンシブサイトなら ほとんど変わりませんが サイトを維持し 改善できる 新しいツールも導入しました iPad向けWeb開発に役立つ 留意点も紹介します 現状が レスポンシブサイトや デスクトップの大画面向けサイトなら iPadの体験を向上させられます

私が紹介する新機能は６つ ポインタイベントなどは 完全にデベロッパ向けの話ですが 高速スクロールなどは エンドユーザにも関係があります 第１はポインタイベントです デスクトップコンテンツを iPadに読み込む最大の問題は マウスとタッチの入力を 一致させることです 小画面版はタッチのみ 大画面版は マウスにしか応答しないように 書かれたサイトもあります そこで マウスイベントだけを 使うサイトでも マウスのないiPadで 動作させる方法を考えました タップで WebKitが MOUSEDOWNやMOUSEUPを送るのです クリックイベントにも 対応する仕組みです マウスホバーイベントにも対応しますが この点は後ほど

マウスの動きはiPadにありません 画面上で指を動かせば スクロールしてしまいます タッチでMOUSEMOVEイベントを 送るようにしたら 問題は むしろ増えました スクロールとの競合もあり 諦めたのです 今回 MOUSEMOVEが必要な場合の 解決策が出来ました それがポインタイベントです ポインタイベントを追加したのは iOS 13とmacOS CatalinaのWebKitです ユーザ入力とサイトの間に 抽象化レイヤを挟めるWeb標準で マウス タッチ Pencilからの入力で 同じAPIが使えます

採用しやすいコードです 現状 デスクトップでマウスイベントを サポートするのがこういうコードなら ポインタイベントのコードは イベント名が違う他はそっくりです もっと具体的に使い方を説明しましょう 動作確認に使うのは フィーチャーディテクションです ポインタイベントがない 古いクライアントのため マウスイベントリスナも残します PointerEventオブジェクトは マウスイベントを引き継ぐので updateInteraction関数を 変える必要がありません ただし マウスやPencilの入力に限った 追加的な引数を使いたいなら別です 本当にこれだけで ポインタイベントが使えるのです

ポインタイベントは マウスやタッチと共存しますが 同じユーザアクションに割り当てる イベントタイプを混ぜる場合はご注意を 見てのとおりelse節がないので 両イベントが登録され ポインタが動くたび 関数が２度 呼び出されます 混乱の元ですね

マウスとタッチが使えるデバイスで 入力を区別したい場合も ポインタイベントで識別できるので 全３タイプを登録する必要はありません スクロールのようなデフォルトの動作を キャンセルしたい人は Macでは マウスイベントに使う preventDefaultを使うでしょう

iOSでは preventDefaultでも 全動作はロックされないので touch-action CSSプロパティも 使ってください touch-actionは秀逸です JavaScriptを書くより楽で preventDefaultより きめ細かな判断ができます ここではnone値で 全ブラウザ動作をブロックしていますが 例えばスクロールだけ止め ズームは可能にすることもできます touch-actionは宣言型なので さらに効率的な ユーザインタラクションも可能です touch-actionと ポインタイベントを使えば パフォーマンスが 向上するかもしれません

互換性マウスイベントでも デスクトップ用サイトは使えますが その場しのぎなので iOSでは ポインタイベントで解決すべきです 採用しやすく マウスイベントや タッチイベントと同じことができ インタラクションへの応答が 確実に早まります マウスとタッチの入力を 一致させるための最高の解決策です

第２の機能です 互換性のため WebKitは ホバーイベントも送ります ホバーは厄介です タッチパネルのハードが サポートしないからです iOS 13ではマウスホバーの 検知方法を変え ホバー動作に依存する デスクトップ用サイトに対応しました

ホバーに応答する要素を １度タップすればホバーが行われ そのホバーの結果 ページに変更が起こればそこで停止

クリックしたければ ２度目のタップをします

iOS 13ではWebKitが 検知できる変更が増えました メニューのような重要な内容の表示に ホバーを使うデスクトップ用サイトにも 対応できるようになったのは 大きな機能強化です

今のところ成果は上々 しかし ブラウザエンジンが 設計意図を解釈するため 模索的で 完璧でない時も そこで ホバーを使う際の 留意点を挙げます

まず WebKitが見過ごす可能性を考え 重要なコンテンツには 別のアクセスも確保してください アクセシビリティの観点からも重要です この点は 後ほどウェンソンのデモで

また 一般的なインタラクションで ２度のタップを強要しないこと WebKitがホバー中に変更を検知しても クリックするには ユーザは ２度目のタップをする必要があります 皆さんが作るページで ユーザがホバーして見る要素は その後 クリックに進む可能性が 高そうな内容ですか？ それなら設計を変え ホバーで見せる要素を減らし ２度のタップを避けることも検討を

また ホバーは機敏にしましょう ホバーでタイマーを動かす場合 WebKitはその発動を待ちます ページに コンテンツが 遅れて追加される場合に備えるためです 最悪の場合 何らかの理由で タイマーが起動し 何も起きなければ WebKitは 自動的にクリックを実行します しかし その間 通常より数百ミリ秒待つので ユーザは タップの反応が 遅いと感じます

iOSのマウスホバー検知は かつてなく向上しました しかし マウスホバーは 戦略的な用途にとどめ ホバーなしで動く サイト作りを提案します

ハードウェアアクセラレーションでの スクロールが第３の機能です このたび メインフレーム以外でも iOSのWebKitでの対応を開始しました つまりサブフレームや オーバーフロースクロール域でも 早くてスムーズなスクロールが 実現したのです (拍手) そう サブフレームもです iOSの旧バージョンでは WebKitは サブフレームをフルサイズにしました よって個別にスクロールできず コードで定義した以上のサイズに なったりもしました 今後はiPadでも フレームが 指定されたサイズになり デスクトップブラウザと同様に スクロールできます

非常に要望の多かった機能です WebKitがデフォルトで これをサポートしなかったため 人気のある対処方法が２つ生まれました １つ目は CSSプロパティ -webkit-overflow-scrolling: touch これを加えれば 高速スクロールが可能になりました デフォルトにしなかったのは CSSの重ね合わせコンテキストが作られ ページ要素のレイヤに影響するからです ２つ目は タッチイベントで 高速スクロールをまねるような JavaScriptライブラリを 構築する方法でした 今後はいずれも不要です WebKit-overflow-scrolling: touchは iPadでは無処理になりました

ハードウェアアクセラレーションによる スクロールの影響を確認してください この機能の欠如を補う手法を 使っていたなら 今後は恐らく不要です

第４は ビューポートと テキストサイズの自動調整機能です

これを新たに開発したのは ページを画面に収め 文字を読みやすくするためです iPad向けに構築されていないサイトも 画面に収めて表示するのです 設計上の意図でない限り 水平スクロールを必要とせず 大半の人が 手動でズームしなくても 読めるテキストサイズにするのです

これは自動であるべきです iPadより広い幅で 表示を固定している デスクトップ用サイトもあるからです

このような幅広サイトの多くが ビューポートのmetaタグに応答するよう 誤って宣言していました なぜ誤りなのか説明します

本来 ビューポートのmetaタグは 小画面のデスクトップパソコンで 起こる問題に対処するものです iPadにも使えますかね？ このビューポート値は そのサイトの設計に応答性があると ブラウザエンジンに約束するものです つまりウィンドウサイズの変化に応じて リフローをします 旧バージョンのiOSでは この約束事を額面どおりに捉えました metaタグで 幅がデバイス幅と等しく 初期ズーム倍率が１のサイトでは 自動的にビューポート調整を しなかったのです

その結果 デスクトップ用サイトは iPadで見にくい状態でした 収まるはずが はみ出るのです そこで新iPadOSでは metaタグが応答性を約束していても レイアウト幅がデバイス幅より広ければ WebKitが無視するようにしました 総合的に この方がいいのです 水平スクロールがあるのに 誤って小さく表示されるなら 簡単に直せます ビューポートのmetaタグに shrink-to-fit=noを加えるだけです これはiOS 9から導入した値です Split ViewやSlide Overで 同様の問題が起きたためです 今後は Split ViewやSlide Over デスクトップ用サイトでも shrink-to-fit=noで 自動的な縮小を防げます

実は今 このページでは ボックスが縮小されましたが ヘッダのテキストは拡大されました ページの縮小に合わせて テキストサイズを自動調整し 読みやすさを保つためです

ビューポートとテキストのサイズを 制御したいなら レスポンシブデザインを採用するのが 最善です それで ウィンドウの大きさに コンテンツを適応させてください レスポンシブデザインについて ここで講義するのはやめますが ネットに好例があります

まとめると ビューポートと テキストサイズの自動調整が WebKitに新しく備わりました 制御したければレスポンシブデザインを 採用してください 水平スクロールを想定したサイトは ビューポートmetaタグで対応できます

第５はビジュアルビューポートAPIです まず ビジュアルビューポートと レイアウトビューポートの違いについて 今話した ビューポートの 自動サイズ変更やmetaタグは 画面とウィンドウのサイズで レイアウトビューポートを定義します 例えばSplit Viewでも ウィンドウサイズは変わります レスポンシブデザインのサイトなら メディアクエリを使ったり リサイズイベントやJavaScriptを 監視したりして反応します メディアクエリの最大と最小は レイアウトビューポート変更で評価され リサイズイベントも同じ時に発動します ユーザがデバイスを回せば レイアウトビューポートが再び変わり いずれかの技術で コンテンツが反応します しかしキーボードは？ オーバーレイなので レイアウトビューポートは変わらず メディアクエリとリサイズイベントは 反応しません ユーザが名前フィールドを タップすると― キーボードが起動し 画面の見え方が変わります ビジュアルビューポートは これを定義するのです レイアウトビューポートは 通常のウィンドウサイズで ビジュアルビューポートは 今 見えるこの部分です このビジュアルビューポートの変化に 対応したいとの要望がありました 例えばこのサンプルでは 寄付ボタンが隠れましたが サイトとしては 画面に出たままがいいでしょう iOS 13では― W3C標準ビジュアルビューポートAPIで この問題に対処できるようになりました

このAPIで ビジュアルビューポートの リサイズを監視できます このイベントは キーボードの出没で発動します Safariでは スマート検索フィールドが スクロール中にたたまれても発動します

これで寄付ボタンが表示され続けます

ビジュアルビューポートAPIは 大画面iPadを生かせる絶好のツールです

第６はストリーミングです プレミアムコンテンツとして 動画を提供しているなら HTTP Live StreamingすなわちHLSが ベストなのはご存じですね

HLSはiPhone iPad Macで使えます デベロッパの仕事を代わりにしてくれる 簡単な解決策なのです CDNでスムーズに動作し AirPlayともそのまま連携します しかしMedia Source Extensions すなわちMSEを使うユーザもいます MSEは ユーザに流されるデータを ビデオ配信側に 明示的に制御させるAPIです 例えば 帯域幅の差異に応じて 手動で画質の高低を変えられます MSEを使う既存コンテンツがあるなら 朗報です MSEが初めて iPadOSで デスクトップ用サイト対応になりました デスクトップ用サイトで MSEを使う既存エンジンがあるなら iPadでも機能します MSEエンジンを実装する JavaScriptライブラリを使っていても うまくいきます

HLSとMSEが選べるようになり iPadのSafariで見るストリーミングは 最強になりました

以上の新機能により コンテンツがiPadで輝きます コンテンツを最高に見せるための 留意点をもう少し

留意点を聞くと 冷静になれると思います 私たちのプラットフォームは 日々 進歩し続けています

重要なのはパラレル デスクトップ モバイルの各サイトでなく レスポンシブサイトを１つ 構築することです 意外と難しいでしょうが― 皆さんは レスポンシブデザインを 使うべきだと私たちは考えます ユーザエージェントを探るより フィーチャーディテクションの活用を ユーザエージェントで iPadを 特定したがるデベロッパがいました しかし新しいiPadでは それができません フィーチャーディテクションを使えば デバイスを知る必要はないのです iPadはカメレオンです コンテンツモードを切り替える 新APIにより サイトは デスクトップ用にも モバイル用でも表示され得ます Split Viewで どちらのモードで 表示されるとも限りません コンテンツがiPadで閲覧されるか否かは 無用な情報なのです ユーザエージェントに関する混乱は iPadにとどまらず 今やMacにも UIKitを使った アプリケーションが入っています

よく考えてください Apple Watch iPhone iPadと 画面サイズはバラバラです 複数のコンテンツモードや 多様なコンフィギュレーションがあり UIKit AppKitによるアプリケーションが MacでWebコンテンツを表示します サイトのコンフィギュレーションを デバイスによって変えていたら サイトは 限定的で脆弱で すぐ時代遅れになります フィーチャーディテクションを使えば 自動で最適化されます 今回 レスポンシブデザインが最適だと 公言することにしました 今後のWWDCでは― その認識が浸透するまで これから毎年 言い続けます レスポンシブデザインに適応する サーバ配信のコンテンツは どのデバイスでも美しく見えます デバイスの多様化は 今後も進むでしょう

大変でしょうが ぜひご対応ください

iPadでのブラウジングが デスクトップクラスになったと言っても これは現在の話なので プラグインは除外です iOSでは 今後も プラグインを採用しません Flashは Macでさえ デフォルトではオフですし Safariでのサポートは 2020年に打ち切ります 皆さんは 古い動画やゲームや レストランのメニューなどを 標準的なWeb技術に移行しましたか？ 今こそFlashと決別する時です

iPadのSafariは デスクトップクラスです しかしiPadはモバイル機器なので 公共の場を含め 外での使用を想定しています よってWebKitは 音声の自動再生を防ぎます 自動再生を前提としている デスクトップ用サイトもありますが 避けた方が賢明です 標準メディアAPIの再生機能に 約束ごとがあるので 問題があれば そこで分かります 再生が拒否されたら そこを拾ってください しかし サイトを設計する際には あらゆるデバイスを使う全ユーザが 音声の要否を選べるようにすべきです

インタラクションを要するフローでは 物理的な入力デバイスを想定せず ポインタイベントを使って設計すること マウスホバーは 修飾的で補助的な コンテンツの表示に限ること

最後に 内蔵APIを使うことです 一般的な話なので 具体例で説明します 多くのデスクトップ用サイトが テキスト選択や入力のカスタマイズに マウスイベントを使っています しかしSelection Changeイベントや Inputイベントこそ その目的に合ったツールです 基本操作に内蔵APIを活用すれば リバースエンジニアリングをするよりも あらゆるプラットフォームで 動作が向上します

大変ですね 今の話を消化できるよう 再びウェンソンを呼んで 今 紹介した新機能と留意点の デモをしてもらいます ウェンソン？ (拍手)

ありがとう　ベス

私は Webブラウザを作っていない時は 余暇も仕事も関係なく Webアプリケーションを作っています 最近作っているShiny Sketchという アプリケーションをご紹介しましょう

まだ デスクトップブラウザでしか テストしていないので iPadでの動作を見るのは面白そうです まず Macでざっと見ましょう 見ながら iPadでの 使い心地をよくするために 修正が必要になりそうな点を挙げます macOSでは こう見えます このサイトのレイアウトは ４列固定なので ウィンドウを小さくすると 水平スクロールが出ます これが まず１つ 次に“編集”と“削除”を出すには それぞれの絵の上で マウスホバーが必要です これらのコントロールは アプリケーションの不可欠な部分です 最後に 絵の１つに 落書きをしてみましょう

今の線はトラックパッドで描きました しかし現状 この実装に使ったコードは マウスイベントしか監視しません iPadとの互換性を得るには これも修正が必要です 今の画面はMacでした では iPadで見てみましょう

Safariで開きますね

ランドスケープモードでは ４列のレイアウトがきれいに見えます では ポートレートモードでは どう見えるでしょうか？

まだ４列のレイアウトです

レスポンシブサイトにすれば この縮小は避けられますね では いったんMacに戻ります どうすれば水平スクロールが 起動するのか ブラウザで確認します まず ウィンドウのサイズを変え 水平スクロールを表示させます 次に開発メニューへ

“要素選択を開始”に行って―

各要素のサイズを見ます 例えば この“編集”ボタンは 72×48ピクセルに指定されています

幅が広くなっている要素を 順番に探していきましょう Shiny Sketchページのタイトル部分は 760ピクセルです このウィンドウ幅を定規で測ると― 約760ピクセルなので同じですね カーソルを下げながら確認を進めます 予想どおり ギャラリー部分が 1300ピクセルもありました これが水平スクロールを 起動させるのでしょう もう少し調べたいので クリックしてWebインスペクタを開き ギャラリーの情報を見ます スタイルのサイドバーを見ると 幅が1300ピクセルに指定されていました なぜでしょう？ これを書いた時の私は 巨大なディスプレイで サイトがきれいに見えるようにしたいと 思っていたのです 幅1300ピクセル以下で表示することは 想定しなかったわけです コードを書いた時はそう考えましたが 改善が必要です では 画面を切り替え ここを修正しましょう サイトをレスポンシブにします ところで この Webアプリケーションのファイルは HTML CSS JavaScriptの３つだけです ではHTMLファイルに ビューポートのmetaタグを追加します

重要な構成要素は２つ “width=device-width”と “initial-scale=1.0”です これでページがデバイス幅に応答すると ブラウザに伝えます 次に 実際に全デバイス幅に 応答させるため CSSファイルを開きます “幅1300ピクセル”と 指定した所を検索します ありました ギャラリーの中に “width: 1300px”とあります これを“max-width”に変えましょう すると ウィンドウ幅が 1300ピクセル未満の時は ギャラリー内の絵がリフローするのです リフローできるのは “display: inline-block”と 設定したからです これでいいですね

この修正で どう変わるか見ましょう

ポートレートモードでは３列に ランドスケープモードにすると―

４列です ランドスケープモードの幅なら ４列でも入るからです 絵が縮小されなくなって よかったです 次は描画について話します iPadにはマウスがありません しかしポインタイベントと touch-action CSSプロパティで 操作できます CSSファイルを開きます

.drawable-canvasに “touch-action: none”を追加します 名前のとおり 描画の時に 指でドラッグする要素です 指でドラッグする際に スクロールさせないことも重要です だからtouch-actionが大事なのです 次にJavaScriptファイルを開いて mousemoveがどこにあるか探します

ここで マウスイベントを 監視するコードを書いています Macでの描画用です これを手直しします

まず 調べるのは―

ポインタイベントが サポートされるか否かです 可なら ポインタイベントリスナを登録 否なら 今使っている マウスイベントに頼ります これで動かしてみて どう変わるか見ましょう

犬のソーナに帽子をかぶらせます

下手ですが 描画はできるようになりました

最後にもう１つ小さな点を iPadはマウスホバー対応になりました しかし直感的に編集と削除に タップが２度必要だと分かりません まず絵を１度タップして コントロールを表示して ２度目のタップで選ぶのです つまりiPadでのインタラクションでは タップが２度必要です

これを１回で済むようにしましょう 削除ボタンは常に表示させて １度のタップで 編集モードに入れるようにします それでは―

まず HTMLファイルに行き 記述を書き加えます

ボタンを追加するのです static-controlクラスに した点にご注目を これが重要になります というのも 次にCSSファイルで メディアクエリを足すからです

ホバーがサポートされているか メディアクエリを使って確認します サポートされていれば 今追加した 静的なボタンは不要なので static-controlを “display: none”とすれば隠れます

最後にJavaScriptファイルも修正します mouseenterを検索 マウスが絵の上で動いたら ホバーコントロールを 見せたり隠したりするコードです ホバーのサポートがなければ不要です ここにロジックを追加します CSSファイルで ホバーの有無確認に 使ったメディアクエリを使います ホバーがサポートされていなければ clickイベントリスナを絵に追加し 編集モードを開始させます また この早期returnで 不要なイベントリスナの追加を避けます かなり変えましたね 動作を確認しましょう

まず削除ボタンが 常に見えているのに気付きます また 絵をタップすれば すぐに編集を始められます どちらも１度のタップで済みます

デスクトップ用アプリケーションが 簡単な変更でiPad対応になりました 皆さんも同様のことができると思います では 全体のまとめを チャールズが行います ラボで会いましょう (拍手)

いいWebアプリケーションでしたね

iPadは大きな進歩を遂げて新しくなり デスクトップ用サイトも 使いやすくなりました デベロッパの皆さんも 新機能を生かし アプリケーションやWebサイトを さらにきれいに見せてください

Webデベロッパは 今日紹介した技術で レスポンシブサイトを構築してください

アプリケーションデベロッパは Safari View Controllerと ASWebAuthenticationSessionに 面倒な作業を任せてください

WKWebViewを使うなら動作確認を

バグの報告やフィードバックを お待ちしています

認証やWebプラットフォームの 機能については セッション504もぜひご覧ください タイトルはWhat's New in Authentication, Safari, and WebKit 今日のセッションに関連するラボも ２回予定されていますので 質問があれば ぜひお越しください それでは 楽しいWWDCを (拍手)