Webインスペクタの新機能

♪ ♪

こんにちは！Razvanです WebKit Developer Experience チームのエンジニアです 今回は 今年Webインスペクタに 追加された新機能と改善点をご紹介します WebインスペクタはmacOSの Safariの一部であり Webサイトや Webアプリ Web拡張機能または ホーム画面のWebアプリの すべてのリソースとアクティビティを 検査できる強力なツールセットを提供します 昨年から追加された新機能や 改善点を紹介できて嬉しいです 新しいタイポグラフィ検査ツールや ユーザーの環境設定を再現する方法や イベントリスナーやスクロールコンテナを 持つ要素用の新しいバッジ ブレークポイントの強化による JavaScriptのデバッグ体験の 向上などが挙げられます Webインスペクタを使用したことがない場合 まず有効にする必要があります Safariの環境設定ウインドウを開き 詳細タブに切り替えます Web開発者向けの機能を表示する 設定が下部にあります チェックボックスを クリックして有効にします メニューバーに 「開発」メニューが追加されました Webインスペクタはメニューの 「Webインスペクタを表示」から開くか 任意のWebページでショートカットキー Option+Command+I を使って開けます

今年はデバイス上でWebコンテンツを ペアリングして検査する合理化された方法や シミュレータでWebページを すばやく開く方法 刷新された レスポンシブ・デザイン・モードなど Safariの開発者向けの全機能に 多くの改善を加えました 今年のWWDCセッション 「Rediscover Safari developer features」で 詳細をご覧ください Webインスペクタが有効になったので まずはタイポグラフィ検査用の 新しいツールを見てみましょう Webデベロッパーは カスタムフォントを使用して 読みやすく目立つ書体で 美しいコンテンツを作成します しかし Web上でタイポグラフィを正しく 表現することは必ずしも容易ではありません まず 適切なフォントファイルを 読み込む必要があります ブラウザがサポートするフォーマットで 適切な機能を備えていなければなりません そして その文字が表現しようとする― 言語の文字に適したグリフが 含まれている必要があります そして フォントの画面表示方法を左右する― CSSプロパティが多数あります そして そのほとんどは カスケードを通じて継承可能であり 実際に使用されたのは どのフォントフェイスなのか 混乱を招くこともあります あるいは「なぜこれは太字なのか？」 「このスタイルは本当にイタリック体か？」

Webインスペクタはタイポグラフィ 検査ツールのホストとして役立ちます 「要素」タブの詳細サイドバーの フォントパネルにあります

これは 選択された要素で使用されている フォントのプロパティと機能― 例えば使用されている 主要フォントの名前を表示します これを参照すれば期待したフォントが 本当に使われているかすぐに確認できます ただし 主要フォントを識別するだけで あることに留意してください 選択したノードについて 主要フォントがグリフを 持たない文字を含む場合 それらの文字に対しては 予備フォントが用いられます 次に フォントパネルには フォントサイズ スタイル ウェイト 引き延ばすなどの基本的な フォントプロパティの概要が表示されます

また サポートされているフォント機能の プロパティとその使用値を示す― セクションもあります これらはフォントが サポートしているものに応じて 合字 小文字の代わりにスモールキャップ 特殊な数字スタイルなど 書体の特殊な側面を切り替えます 今年の新機能として フォントパネルに合成太字や 斜体の警告が表示されるようになりました 合成スタイルとは何か？ イタリック体を例にとってみましょう

イタリック体は 通常の縦書きの フォントファイルとは別に 独自のフォントファイルで 提供されることがほとんどです 適切なイタリック体のスタイルがない場合 WebKitはそのための 人工的な表現を生成します これは 通常の正立フォントスタイルに対し アルゴリズムを実行して 個々のグリフを歪めて 斜体のスタイルを生成するものです これは合成斜体と呼ばれます

フォントデザイナーはイタリック体の スタイルを作る際に多くの注意を払います これらは直立書体の斜体バージョンではなく 特定の美的感覚を伝えるため 特別にデザインされた 草書体であることがほとんどです 同様のことが合成太字でも起こり グリフのストロークは人工的に太くされます すべてのフォントが対応しているわけでは ないことに留意してください 現在は合成太字または斜体が使用された場合 Webインスペクタに警告が表示されます フォントパネルの 基本プロパティセクションで 合成されたウェイトまたは スタイルの隣に表示されます この警告は期待されたフォントファイルが ロードされなかったことを示す ヒントになります しかし あなたが要求した正確な値に フォントファイルが 対応していないだけの場合もあります そこで役立つのが可変フォントです 可変フォントとは何でしょう？ 簡単に言えば フォントの太さ 幅 傾きなど フォントの複数のスタイルバリエーションを 生成するために 必要なすべての情報を 1つのファイルに含められる フォントフォーマットです

また サポートされている― 各スタイルについて 静的なフォントファイルのわずか数個の 個別の値と比較して 可変フォントはスペクトルの値を提供します これにより コンテンツに適したスタイルを より柔軟に選択できます 可変フォントはさらに有能です フォントデザイナーは ストロークの太さやグリフのカーブ 文字の幅など フォントのほとんどすべての側面を 設定可能にすることができます その可能性は実に広大です 設定可能な可変フォントのすべての側面は バリエーション軸として表現されます 利用可能なものを把握するには フォントのマニュアルを読むか この情報を明らかにする 特別なツールを使う必要があります

ここでWebインスペクタが役立ちます 可変フォントを使用している 要素を検査すると フォントパネルにサポートされている バリエーション軸のリストが表示されます それぞれについて 4文字の識別子である軸タグや オプションの軸ラベル サポートされる最小値と最大値 あるいは現在の値 またはCSSで 指定されていない場合は デフォルト値が表示されます

今年はバリエーション軸の値を編集し その結果を検査ページで ライブで見ることができる― インタラクティブな コントロールを追加しました これによりフォントスタイルを 適切に微調整できます お見せしましょう これは私が旅行写真のブログ用に 作成しているWebページです フォトギャラリーや ラベルによるナビゲーションなど 思い通りのレイアウトができましたが タイトルの見た目については まだ自信がありません 右クリックで見出し要素を調べてみます

フォントパネルでこれは 可変フォントを使用しているとわかります

私は使用可能なバリエーション軸の コントロールを持っており 自由に操作できるため そのことがわかります 例えば ウェイト軸のスライダーを ドラッグすることができます これはページ上で確認できる表示タイトルの フォントの太さを変更するものです

対応するCSSフォントの ウェイトプロバティが スタイルパネルにどのように 書き込まれているか注目してください 静的フォントは100刻みで 数種類のフォントフェイスを 持つにすぎません しかし 可変フォントを使えば 変動軸の範囲内で 任意の値を選ぶことができます 幅のバリエーション軸も試して 広くなったときや狭くなったときの 見え方を確認してみましょう

また 軸の値入力フィールドへの 入力も可能ですし ArrowUpまたは ArrowDownキーを押したまま 値を正確な増分で変更することもできます

私はこの少し狭くなった バージョンが好きです もう少し太くしながらも この幅を保ちたいと思います この可変フォントには フォントのグレードを変更するための カスタムバリエーション軸も 用意されています このためにスライダーをドラッグすると ウェイト軸を変えたときのように 位置がずれることなく 個々の文字がその場で太くなっています

いい感じですね これらの変更をプロジェクトに戻すには スタイルパネルまたは変更パネルから 新しいCSSプロパティをコピーします

タイポグラフィを検査する方法や 可変フォントを使用して フォントスタイルを 微調整する方法を見てきました Webインスペクタの 別の新機能に移りましょう ユーザーの好みをエミュレートできるので 作成するコンテンツがユーザーのニーズに 適応しているかどうか確認できます すべてのApple製品には ニーズや好みに合わせて デバイスを設定できる 様々な設定が用意されています 例えば macOSのアクセシビリティ設定では 内蔵のスクリーンリーダーやVoiceOver ディスプレイ環境設定では 動きの低減 カラーコントラストの増加― カラーフィルタなどが調整できます デバイスで行う最も一般的な行為の一つは Webの閲覧です よって すべての人が快適に利用できる― WebサイトやWebアプリを 構築することは理にかなっています そのためには ほかの人が ユーザー設定をするときと 同様にWebを体験する必要が ある場合もあります

あなたのWebサイトを 例えば 動きを抑えた設定でテストするには macOSのアクセシビリティ設定で 設定することができます しかし SafariとあなたのWebサイト だけでなく システム全体に影響を与えます テストするページだけに 設定する場合が多いです

そのため ユーザーが選ぶ設定を エミュレートする― 新しいツールを Webインスペクタに導入しました 要素タブの新しいアイコンをクリックして ユーザー設定の 上書きポップオーバーを表示します ここには Webインスペクタを 開いている間 検査されるページのユーザー設定を 上書きするためのトグルがあります これらの設定は Webページのスタイルと動作を 適応させるために使用できる CSSメディア機能に対応しています 例えば 配色の優先順位は CSSのprefers-color-scheme メディア機能に対応します 使い方はこうです 要素のスタイルを設定することができます 次に prefers-color-scheme メディア機能を使って 暗い配色が好まれるかどうかを確認して スタイルを更新します User Preference Overrides ポップオーバーでページの適応を確認します Appearanceセクションで 配色設定をDarkに上書きします アイコンの色が変わり オーバーライドが 適用されていることを示します ダークカラースキームのスタイルは オーバーライドが アクティブで Webインスペクタが 開いているときに適用されます この配色コントロールは 以前は独立したボタンでした ポップオーバーの環境設定オーバーライドの 他のコントロールと一緒になりました

次に 動きを抑えた優先順位の 上書き方法をお見せします 次のセクションでは 動きの多いアニメーションを表示します こうした動きに敏感な方は 動画の次の3分間は 飛ばした方がいいかもしれません 私のページに戻ります 写真をクリックして 拡大したときに流れるアニメーションは ちょっとやりすぎかもしれません

特にZ軸上で起こるような 素早く急激な動きのあるアニメーションでは 混乱してしまう人もいるでしょう 吐き気や頭痛などの 不快感を引き起こすこともあります これは間違いなく 歓迎すべき体験ではありません WebサイトやWebアプリが ユーザーの好みに適応するよう 自分のデバイスで動きを抑える設定を することができます 私たちWebデベロッパはそれを尊重すべきです そこでprefers-reduced-motionの CSSメディア機能が役に立ちます アニメーションが単なる装飾であれば 取り除いても構いません しかしアニメーションはインターフェイスの 意味を伝える際に有効でもあります これを取り除くと 使い勝手に影響が出る可能性があります ゆっくりとした より繊細なフェードアニメーションは 変化を伝え 人々のニーズを 満足させる際に有効かもしれません この変更を私のWebページで 試してみましょう まず 写真を検査し Webインスペクタの「要素」タブで 図の要素を選択します

これでスタイルパネルに一致する すべてのCSSルールが表示されます ここが動きの多いアニメーションを 設定するCSSプロパティです 今 みなさんのために動いています 次に このCSSルールの ソースコードの場所をクリックして スタイルシートで定義されている場所に ジャンプします

これでソースパネルが開き 変更したいアニメーションを持つ CSSルールのすぐ隣に表示されます 先ほど用意したこのコードの ブロックのコメントを外しておきます これはprefers-reduced-motionの CSSメディア機能が保護しています ここでは 写真をズームさせるのでなく フェードさせるアニメーションに変更し アニメーションの時間も長くして 急な変化を避けています

ページ上の画像をもう一度クリックして 見え方を確認しましょう

ああ！　まだ同じ アニメーションが動いています prefers-reduced-motion メディア機能によって保護された― 新しいアニメーションを 私が定義したことで発生しました しかし このページでは この環境設定のデフォルトの システム値が尊重されます それを調整しましょう 「要素」タブに戻ります ここで ユーザー設定の 上書きポップオーバーを開きます

アクセシビリティセクションで ポップアップメニューを開き ユーザー設定の 「Reduce motion」を上書きします

私のシステムのデフォルト値から変更し Onに設定します

私のページの写真を もう一度クリックしてみましょう

見てください 写真がゆっくりと消えていきます もう混乱するような動きはしません 動きが少ない方がいい人にとっては この方がいいですね これらの変更を忘れずに プロジェクトに反映させます User Preference Overrides ポップオーバーの最後の項目― 「Increase contrast」はprefers- contrastCSSメディア機能に対応します 理想的なのは 誰にとっても 色のコントラストが高いコンテンツを 構築することです しかし デザインシステムに 制約がある場合は このメディア機能で コントラストを強めた方がいい人向けに スタイルを適応させましょう それから 検査されたページのスタイルが それに応じて適応しているか確認します 「Increase contrast」を Onに上書きします これらの機能を活用し より多くの方々に楽しんでいただける― コンテンツを構築していただければ幸いです 次に Webインスペクタの「要素」タブに 新しく追加された要素バッジを説明します 「要素」タブの ノードツリービューでは CSS FlexまたはCSS Gridコンテナとして 機能する要素の横にバッジが表示されます 要素バッジは 特に関心のあるノードを一目で識別する― 素早い方法を提供します この場合 CSS GridまたはFlexレイアウト コンテキストを作成するノードが該当します グリッドバッジと フレックス要素バッジをクリックして そのノードの専用ページオーバーレイを 切り替えることができます バッジのハイライトカラーは ページオーバーレイのカラーと一致します CSSグリッドとフレックスボックスの ページオーバーレイは レイアウトを 決定するラインやギャップと利用可能な スペースを明らかにするガイドを表示します ページオーバーレイを使用した CSS GridとFlexboxレイアウトの デバッグ方法については 過去のセッションをご覧ください CSSレイアウトの問題で最も デバッグが厄介なもののひとつに コンテナ内のコンテンツが 利用可能な幅に収まらないために 水平方向にスクロールしてしまうような 不要なスクロールがあります この種の問題は スクロールバーが デフォルトで表示されていない場合 長い間発見されないまま 潜んでいる可能性があります 不要なスクロールを識別しやすくするため スクロールコンテナの横に表示される― 新しい要素バッジを追加しました これは要素のコンテンツが その境界をオーバーフローし スクロールバーが適用されたときに ノードツリーで 素早く視覚的なヒントを提供します 不要なスクロールのよくある例と その修正方法を見てみましょう 私のページに戻ると フォトギャラリーの 上部にあるこれらのラベルは 利用可能な水平スペースをすべて使って 美しくレイアウトされているように見えます しかし スワイプしようとすると このコンテナの中に 短い横スクロールがあることに気づきます これは私が望んでいないことです そして最後のラベルはわずかに切れています ウインドウのサイズを変更すると さらに悪化します 「要素」タブのノードツリーで ラベルのコンテナの横に 「スクロール」バッジがあると気づきました この要素をクリックすると スタイルパネルに一致する CSSルールが表示されます このFlexboxコンテナは正常に見えます フレックスアイテムや ラベルそのものはどうでしょう？

この最小幅プロパティの 正確すぎる値は奇妙ですね 私が何をしたいかをブラウザに伝え ブラウザに計算させるのではなく ブラウザに何をすべきか正確に 伝えようとしたからだと思います

これを修正するために この最小幅の宣言をコメントアウトします 今 各ラベルは必要なだけの スペースを取っています でも 使われていないスペースが たくさん残っています 解決するために 値1のフレックスプロパティを追加します

これにより 未使用のスペースが 各ラベルに分配され コンテナがいっぱいになります また ノードツリーのコンテナの横に 「Scroll」バッジが 表示されなくなったことで 不要な水平スクロールもなくなりました 次に 新しいイベントバッジについて お話しします JavaScriptのイベントリスナーが アタッチされている要素の 横に表示されます これは ポインタやUIイベントのような 組み込みイベントと コード内でディスパッチするカスタム JavaScriptイベントの両方で機能します ノードツリーでEventバッジが 横にある要素を探し バッジをクリックすると その要素にアタッチされている― すべてのイベントリスナーの ポップオーバーが表示されます ここでは 各イベントリスナーの概要を 知ることができます イベントの種類や イベントを処理する JavaScript関数の名前 そしてその関数が定義されている ソースコードの場所です イベントリスナーの様々な設定 オプションには DOMツリーを通して バブルを発生させるかどうか あるいは一度だけ実行したら 自動的に削除されるかどうかなどがあります さらに イベントリスナーを 無効にするオプションもあるので イベントリスナーを実行せずに コードをデバッグすることもできます あるいは 段階的にデバッグしたい場合は イベントブレークポイントも設定可能です これにより 次にハンドラが呼び出された際 JavaScriptの実行が一時停止されます この機会に ブレークポイントを 使ったデバッグ体験の 改善についてお話ししましょう JavaScriptをデバッグする際 console.log()ステートメントを コードに追加することに 慣れているかもしれません 一方 ブレークポイントは ソースを変更することなく JavaScript を一時停止して ステップを実行する強力なデバッグ方法です

ブレークポイントを使ったことがない場合の 一番簡単な方法は ソースタブの溝にあるスクリプトファイルの 行番号をクリックすることです これで スクリプトのその行にJavaScriptの ブレークポイントが設定されます 次にその行が実行されようとすると Webインスペクタは代わりに JavaScript の実行を一時停止します 一時停止中は コールスタックを観察したり スコープ内のオブジェクトや 変数の状態を調べたり コンソールを使って それらに変更を加えることも可能です

JavaScriptの実行を再開することも 上部のステップコントロールで コードを 式ごとにステップ実行することもできます ブレークポイントを右クリックし Edit Breakpointを選択すると ブレークポイントを設定することができます ここでは ブレークポイントが ヒットしたときの制御やアクション実行など 多くのオプション設定が可能です

いくつか見てみましょう ブレークポイントに条件を設定することで ヒットするタイミングを制御できます これはブレークポイントが 設定されているのと同じスコープで JavaScriptとして評価されます 条件がtrueであれば ブレークポイントがヒットします ブレークポイントをスキップする方が 簡単な場合もあります 例えば ループの中で 最初の数回の繰り返しで 停止することに 必要がない場合などがあげられます ここでは ブレークポイントを 無視する回数を設定できます ブレークポイントがヒットしたときに JavaScriptの一部を 評価するようなアクションを 実行することもできます これはブレークポイントが設定されたのと 同じスコープで実行されます 続行する前にスクリプトの状態を 変更するために使用できます また JavaScript が一時停止した時点の 変数やオブジェクトの状態に アクセスできる式を使用して コンソールにメッセージを記録できます コードにconsole.log()ステートメントを 追加するのと 似ていますが ソースを修正する必要はありません 変数やオブジェクトを コンソールに記録する代わりに Probe Expressionアクションを 使うこともできます これにより ソースタブの 詳細サイドバーパネルで 指定した式の状態を調べることができます もちろん これらのアクションは 非常に便利ですが 実際にブレークポイントで止まって 手動で再開することなく 実行したい場合もあるでしょう そのような場合は 式の評価後に 自動的に続行するオプションを使用します 同オプションはLog messagesアクションを console.log()ステートメントのように 動作させます　ログは記録されても 一時停止はしません 同様に ブレークポイントの位置で JavaScriptを評価し それがすでにソースコードの中に あるかのように続行することができます ほかにも設定できるブレークポイントは 多数存在します ブレークポイントセクションの 「Plus」ボタンをクリックすると 設定可能なすべての ブレークポイントのリストが表示されます 例えば fetch() や XMLHTTPRequestのようなメソッドで ネットワークリクエストが 行われようとしたときにトリガーされる URLブレークポイントや イベントバッジで見た「クリック」 の ようなイベントブレークポイントや マイクロタスク アニメーションフレーム タイムアウト ほかにもインターバルが処理されたときに トリガーされるブレークポイント そして今年の新機能として 関数が呼び出される前に 一時停止するシンボリック ブレークポイントが追加されました シンボリックブレークポイントは JavaScript組み込み関数の 呼び出しをデバッグしたり 同じ名前の複数の関数で 一時停止したりするのに便利です シンボリックブレークポイントを追加する際 具体的でも一般的でも構いません 大文字と小文字の区別を含め て関数名と正確に一致させるか パターンに一致する複数の関数で ブレークしたい場合 または完全な関数名を よく覚えていない場合は 正規表現を使用します コード内の問題のデバッグにシンボリック ブレークポイントがどう役立つのでしょう 私のページの各写真には共有ボタンがあり 友人とリンクを共有できます しかし 彼らが取得したURLが 写真のページを指定していないという バグ報告を受けました 調査してみましょう この作業してからしばらく経つので どのように構築したかよく覚えていません デバッグする方法は複数ありますが シンボリックブレークポイントを試してみます ソースタブに切り替えて 新しいシンボリックブレークポイントを 追加するオプションをクリックします

私の側で実行されるコードが何であれ 最終的にはシステムのポップオーバーを 表示する navigator.share() ブラウザAPIを呼び出す必要があります share()関数が呼び出される前に ブレークポイントを設定しましょう シンボリックブレークポイントを 設定するためにクリックします そして 自分のページの 写真の共有ボタンをクリックしてみます Webインスペクタはnavigator.share()が 呼び出される前に一時停止しています このメソッドに渡された データオブジェクトにカーソルを合わせます オブジェクトの内容が確認できます 共有されるURLキーの値が 確かに間違っているようです どこから生じたのでしょうか？ ソースタブのCall Stackセクションで この時点にいたるまでに呼び出された 関数のチェーンが確認できます クリックイベントハンドラが 前に呼び出されたようです コールスタックでエントリーを選択し その関数に移動してみます ここでは sharePhoto()関数に渡される データオブジェクトをビルドする コードが確認できます このコードのコメントを見ると 実装するつもりが 忘れてしまったようです 今すぐ修正しましょう クリックしてこの行に ブレークポイントを設定します 右クリックして「イベント ブレークポイントを編集」を選択します

条件の設定は必要ありませんが JavaScriptのアクションを 実行するように設定します 式フィールド内で share関数に渡される前に urlプロパティを修正するため データオブジェクトを修正します

このブレークポイントを ここで止める必要はないので 式を評価した後に自動的に続行する オプションをクリックします 次に JavaScriptの実行を 再開するボタンをクリックします 共有ボタンをクリックすると 先ほど設定した シンボリック ブレークポイントに再び到達します でも 今回は取得したデータオブジェクトが 正しいURLの値を持っています もう一つのブレークポイントの JavaScriptアクションが値を変更し 一時停止せずにこの関数に送りました 私が行った変更が確かに 問題を解決していることが確認できました これはブレークポイントによって可能になる 素晴らしいデバッグワークフローの 一例に過ぎません ほかにもたくさん例があるので ぜひ あなたのプロジェクトで お試しください このセッションでは 新しいタイポグラフィ検査ツールから ユーザー設定の上書きや 新しい要素バッジの使用 ブレークポイントの改善まで 多くのことを取り上げました 今年の Webインスペクタには このセッションで 紹介しきれなかった― 新機能や改善点がほかにもたくさんあります Webインスペクタでできることは まだまだたくさんあります これらの機能やそのほかの 多くの機能についてもっと知りたい場合は webkit.orgで詳細なブログ記事や ドキュメントをご覧ください みなさんからのご意見もお待ちしています 問題が発生した場合や Webインスペクタの 改善に向けたアイデアがある場合は WebKitのインスペクタ用の バグトラッカーに問題を報告してください Safari Technology Previewも ぜひダウンロードしてください このプレビューは数週間ごとにリリースされ WebKitの最新のツールやテクノロジー バグの修正や改善が含まれており Safariの次のバージョンに 反映される前にリリースされます 今年のSafariのデベロッパ向けの 新機能についてさらに知りたい方は 「Rediscover Safari developer features」と 「What's new in CSS」をご覧ください ご視聴ありがとうございました