CSSの新機能

♪ ♪

こんにちは 私Jen Simmonsは AppleのSafariおよびWebKitの エバンジェリストです 今年はWebKitにとって 素晴らしい年でした 今年 すでににSafariの複数のリリースで 140以上の新しいWebテクノロジーを 出荷しており この秋にはさらに数十の新しい Webテクノロジーをリリースする予定です すべてをカバーすることは不可能なので CSSに焦点を当てることに決めました 本セッションでは CSSの最も面白い 新機能をいくつかを紹介します レイアウトに関するまったく新しい可能性 今日の素晴らしいディスプレイを フル活用する全世代のカラーツール 新しい擬似クラスによる 厄介な問題を解決する生産的な方法 タイポグラフィを次のレベルに引き上げる CSSなどが含まれます すでに配布されたもの Safari 17で配布される予定のもの そして私たちが将来に向けて 取り組んでいるものを紹介します 今すぐ未来を見るにはSafari Technology Previewをダウンロードしてください そこにMasonry Layoutがあります これは何年もの間 Web上で 人気のあるレイアウトパターンです 異なるサイズのコンテンツを詰め込む際に 最適な方法です コンテンツの順序が1列目から始まり ビューポートの下に流れ落ち 2列目の一番上に戻り その下に流れ落ち 3列目へ といった具合で問題なければ CSS Multicolumnを使って この形のレイアウトを実現できます これがみなさんのプロジェクトで使えるなら 素晴らしいことです CSS Multicolumnは何十年も前から ブラウザに搭載されているレイアウトの 仕組みですが 多くの場合 これは機能しません 代わりにデザイナーはコンテンツが ページ全体に流れるように 各項目をできるだけ上に近いカラムに 配置することを望みます これはユーザーがスクロールするにつれて より多くのコンテンツが下部に 読み込まれる場合 特に必要となります よってWebサイトはこれを実現するために JavaScriptを使う必要がありました しかし JavaScriptはCSSよりも レイアウトが遅く 壊れやすいのです コーディングも難しいです レイアウトは本当に CSSに属するものなのです CSS Gridの一部として Masonryを作成する提案は 数年前に開始され Firefoxで実験的に実装されました 私たちはこの考えに信念を持っており Web上で実現することを望んでいます 現在は Safari Technology Previewに デフォルトで組み込まれているので そこで試してみて ご意見をお聞かせいただき 前進させるお手伝いをお願いします ここに例があります この典型的なMasonryレイアウトは ほとんどCSSを使わずに作りました display: gridでレイアウトを開始し grid-template-columnsで 余白が空くと自動的にカラムが増える フレキシブルなカラムを用意しました そして grid-template-rows: masonryは たった1行のコードで アイテムを行方向に Masonryパターンにまとめます これをCSS Gridの一部にすることで 非常に大きな柔軟性が得られます 1つの次元でMasonryを定義し もう1つの次元ではGridの力を使って 何でもできます 例えば カラムをfr単位で 異なるサイズにしたり 最初のカラムを固定幅にし 真ん中はfr単位でフレキシブルに 3番目はminmax値で フレキシブルにすることができます MasonryとGridを組み合わせることで 一般的なJavaScriptライブラリより はるかに強力なメカニズムになります これはまだすべてが進行中です CSS Working Groupでは ブラウザメーカーなどが集まり 完全なアクセシビリティを 確保するための作業も含め 進むべき道について合意するために さらなる議論が必要です 準備が整い次第 Safariで Masonryを配布するのが楽しみです 現在 ブラウザで配布可能なものは？ マージントリムです 新しいmargin-trimプロパティは コンテナに対して押し上げられた要素から 余白を簡単に取り除けます 説明しましょう 見出しと3つの段落があるとします これらの要素にはすべて上下に マージンがあり それらの間に余白があり グループ全体の上下に余白があります また コンテナであるcardクラスの article要素にも パディングが適用されています 見出しの上のマージンと コンテナの上のパディングを足して ボックスの上端とテキストの最初の行の間に どれだけの余白があるかを決定します 下も同様です 最後の段落の下のマージンは コンテナの下部のパディングに 追加されるため おそらく意図したよりも多くの空白が 追加されます その代わりに行いたいのは 上下にパディングを入れ 余白を作らないことです こうすることでボックスの周囲に 均一な余白が生まれます 必要なのはコンテナからはみ出す 余白をなくす方法です おそらく見出しの上マージンと 最後の段落の下マージンを 手動で取り除くことで 最善を期待しながら 処理しようと試みたことがあるでしょう しかし 予期せぬコンテンツが現れます 別のインスタンスがh3で始まっていて 誰もそのコードを書いていなかったり 誰かがh2を真ん中に貼り付けていて 上部のマージンが欠けているかもしれません マージントリムは より良い解決策を提供します 代わりに コンテナに margin-trim: blockを 適用することで 正確に望むものを求めることができます Safari 16.4では margin-trimのサポートが追加されました margin-trim: inline でインライン方向の マージンのトリミングもできます それがマージントリムです 単に 一般的なニーズを より堅牢な方法で解決するものです 2017年3月のCSS Gridの登場以来 レイアウト用のCSSは この6年間で本当に成熟しました 今日のレイアウトは10年前に比べて 抜本的に改善されています Webデザイナーやデベロッパには あまり気づかれていませんが もう1つの急進的な飛躍がありました 色の飛躍です 世界は色に満ちています ダイナミックレンジに彩度 あらゆるニュアンスと可能性があります この図が 人間の目が見ることのできる すべての色を表していると 想像してみてください これらの色のサブセットを囲む線は Webのデフォルト色域であるsRGBで 表現できるものを示しています 90年代に使っていたものよりは 確かに良いのですが sRGBの限界を超えて更に多くの 視覚的スペクトルを 伝えることができれば素晴らしいことです P3カラーはまさにそれを実現します Appleは7年以上前に 私たちのハードウェアと ソフトウェアで 広色域Display P3のサポートを開始し まず2015年後半にiMac 次にiPad そしてiPhone 7からは iPhoneに対応しました P3の色域はsRGBよりも 50％多くの色を表示することができます 現代のデバイスのディスプレイは見事です これらはすべて より明るい色とより深い 彩度を持つ広色域P3をサポートしています Webデザインがその利点を最大限に 活用できるようになって久しいですね ユーザーのハードウェアと ソフトウェアができることに応じて 条件付きでCSSを 指定する方法が必要な場合 色域サポートをテストするための CSSのメディアクエリがあります 私たちは2016年に Safari 10.0で 色域メディアクエリの サポートを出荷しました 色を選ぶとなると もちろん方法は多数あります 名前付きの色や16進数値 赤 緑 青で考えるRGB関数などです 色相 彩度 明度を表すHSLや 色相 白色度 黒色度を表す HWBもあります これらの色のモデリング方法はすべて 同じ結果を作成することができます これらのモデルはすべて sRGBの色域に制限されています これらのカラーモデルを使用した場合 P3にしか存在しない色を 表現することは不可能です そのため CSSでは 新たに4つのモデルが定義されました LCH OKLCH LAB そしてOKLABです これらのモデルは ディスプレイP3や 将来Webに登場するかもしれない ほかの色域を含む あらゆる色域の色を表現することができます それぞれ3つの値で定義されています 4つとも「L 」は明度を表します LCHとOKLCHは彩度の値も取ります あるいはその色がどの程度強いかや 色相 つまりその色が色スペクトルの どの位置にあるかを表す値も取ります LABとOKLABはA軸― 緑から赤までの軸のどこにその色があるか およびB軸― 青から黄色までの軸のどこにその色があるか これに従って値を宣言します LCH OKLCH LAB OKLABで色を作るには それぞれ新しい関数を使います ブラウザがP3のサポートを追加した場合 これらの関数はsRGB内の色だけでなく P3にのみ存在する色を 表現することができます Safari 15.0と15.4で これらの関数をサポートしました Chrome Edge Firefoxは Interop 2023プロジェクトのおかげで 今年サポートを追加する予定です color()関数で色を定義し 使用する色域を指定することもできます color関数はスラッシュの後に 赤 緑 青の値と アルファの値を取ります しかし 例えば緑100％の どの色を作成するかは 色域によって異なります CSSでP3カラーを 作成できるようになったのは 6年以上前のSafari 10.1からです このような色域とカラーモデルの出現に伴い CSS Working Groupはそのパワーを利用する 追加ツールを定義しました それらのWeb標準は今年ようやく これらのツールの出荷に 十分なほど成熟しました CSSで別の色を参照しながら 色を定義したいと思ったことはありませんか プリプロセッサで似たようなことは 以前から可能でした そして今回 相対カラーシンタックスで それが可能になりました 色を定義する多くの方法と同じように カラー関数の1つから始めます これにより新しい色を作成する際に どのカラーモデルを使用して 数学的計算を行うかを決定します 次に どの既存の色から 始めたいかを指定します そして 関数から チャンネルを取り出して操作します 最初の例では RとGとBのチャンネルはそのままで / 0.7はこの色の不透明度を 70%にするようブラウザに指示します ILABの2番目の例ではLを2で割るよう ブラウザに指示しました これは明度を半分にして色を暗くするもので AチャンネルとBチャンネルは残します そして3つ目の例では OKLCHで LとHチャンネルだけを残し 彩度であるCを3分の1にカットして 色から強度を抜きます 相対カラーシンタックスを使うと 色のパレット全体を素早く定義できるので デザインシステムを作る際に便利です

新しいカラーモデルでは グラデーションの定義方法も改善しています ここでは白から青に向かう 単純な線形グラデーションを示します 何年もの間 この種のグラデーションは 常にsRGB色空間を使って 計算されていました Safari 16.2からは グラデーションをsRGBで計算することを 望む場合 明示的に 指定ができるようになりました あるいは色空間を変更することもできます sRGB-linearはsRGBに似ていますが より直線的な方法で 色間の遷移を滑らかにします しかし どちらも紫の色調で遷移することに お気づきかもしれません OKLABに切り替えると 中間で計算される色が はるかに青みが強くなり おそらくその方が好ましいのでしょう LCHも同じではありませんが 似たような結果になります OKLCHはイエロー グリーン ティールのスペクトルを推移します LABはより紫に近くなります これらの結果が気に入れば HSLやHWBを使うこともできます それは本当にプロジェクトと私たちが望む デザイン効果によるところとなります どれが正しいとか間違いである あるいはベストということではありません 場合によるのです グラデーションを定義する 新しいオプションは多数あります カラースペースの切り替えは 大きなインパクトがあります これは色の変化をアニメーション化する 場合にも当てはまります 色空間はその間に起こることの 補間に影響します 色を混ぜても同じ影響があります そう CSSで色を混ぜることが できるようになったのです Safari 16.2から カラーミックス機能が追加されました 混ぜる色を2つ指定し どの色空間を使うかを指定すると ブラウザがそれらを混ぜ合わせます この紫がかった青はグラデーションの 真ん中にある色だとわかるかもしれません 代わりにグラデーションで 使用するために見てきた他の色空間の どれかに切り替えることができます これらはすべて異なる結果を生み出します デフォルトでは カラーミックスは1つの色の50%と もう1つの色の50%から 新しい色を作ります しかし 80/20や30/70など 好きな比率に変更することができます また 2つの数値の合計が 100％未満になるように設定すれば 半透明の色になります ここでは白を30％ 青を30％に設定し 結果の色の不透明度を60％にしています currentcolorキーワードを使えば 現在のテキストカラーに 好きな色を混ぜることもできます この例では 濃い緑のリンクカラーに 40％の白を混ぜて ホバーカラーに使う薄い緑を作っています ここには多くの可能性があります P3の色域や新しいカラーモデルと機能 グラデーションやアニメーションの カラースペースを変更する機能 既存の色のチャンネルを変更したり ミキシングで色を定義する 新しい方法など ebのデザインで色を活用する上で ここには多くの可能性があります 最後に P3カラーのサポートについて 知っておくべきことがあります ブラウザがP3カラーを使用するCSSや JavaScriptの特定の機能を サポートするだけでなく ユーザーのオペレーティングシステムや ディスプレイもサポートする必要があります さらにブラウザはWebページの各特定の部分 DOMの異なるセクションで P3でのレンダリングを サポートする必要があります それが普遍的に機能すると仮定する前に 各ブラウザの詳細をチェックしましょう SafariのP3についての 最新情報をお伝えします 私たちは7年前のSafari 10.0で P3の画像をサポートしました Safari 10.1ではWebページの 大部分でP3を全面的にサポートしました Safari 15.2ではCanvas要素内での サポートを追加しました そしてSafari 16.4では drawingBufferColorSpaceによって WebGL Canvasでの P3のサポートを追加しました デベロッパツールとして Safari 13.1ではWeb Inspectorに カラーピッカーを搭載しました これによりP3でのみ利用可能な色を 簡単に見つけることや 色を異なる カラーモデルに変換することができます また Safari 15.2ではWebインスペクタの グラフィックタブをP3に対応させました まだもう少しやるべきことがあります まず WebGL Canvas内の サポートを拡張し unpackColorSpaceの使用を含めること そして SVGフィルタへの P3のサポートの追加が未完了です というのも Web標準については まだ議論が続いているためです 今のところ SVGフィルタを適用すると どのブラウザでも色が sRGBにフラット化されます Web上の色彩を見直すには 実に面白い時期です 特に これらの機能の多くが ついに全ブラウザで利用可能になるためです CSSの進歩はデザインの 可能性を変えるだけでなく それらのデザインを コーディングすることも容易にします

user-valid擬似クラスと :user-invalid擬似クラスは ユーザーがフィールドに 正しく入力したかどうかに応じて フォームをスタイルする方法を提供します 何年もの間 :valid と :invalid 擬似クラスは 本当に役に立つように思えました ユーザーが間違えた際フォームフィールドが 警告を出すようにスタイルしたいとします そこで 無効な入力を選択するために :invalid擬似クラスを使用してみます has input:invalidで ラベルをターゲットにします そして、:before擬似要素で「x」を挿入し 色だけに依存しないようにします 結果を見てみましょう 誰かが入力し始めると ああ これは良くないですね ユーザーが入力を始めるとすぐに まだ有効なメールアドレスではないので ブラウザはそれを無効とマークします invalidはユーザーが正しく入力する チャンスさえないうちに 間違った入力をマークしてしまうので デベロッパはこの代わりに JavaScriptを使ってきました user-validとuser-invalidは この問題を解決します これらはより複雑なアルゴリズムを使って フォームフィールドがいつ有効あるいは 無効かを判断します 私たちはこれを Safari 16.5で出荷しました これで改善された結果を 確認することができます 正しく入力されていれば 赤い警告は表示されません また 誰かがフィールドに 正しく入力しなかった場合 赤い警告はフィールドを離れたあとで 修正するよう警告したいときに表示されます ご覧のように :user-invalidは: has()と組み合わせると 特に強力です

実際 今年は:has()をさらに多くの 擬似クラスで使えるようにすることで :has()の威力を高めました has(:lang())は 特定の言語の有無に応じて ページ上のあらゆるものを スタイルすることを可能にします また メディア擬似クラスの :has()サポートは オーディオや動画の再生状態に応じた 条件付きスタイリングを提供します dir擬似クラスは言語の方向性を サポートする際のギャップを埋めます タイプセットされる言語によって テキストは左から右へ あるいは右から左へ流れます これはしばしばLTRやRTLと略されます 最近では CSSに 論理的なプロパティが増えて 左右ではなく テキストフローの開始と終了を 参照できるようになりました 例えば margin-leftやmargin-rightの 代わりに margin-inline-startや margin-inline-endを使えば どの言語にも対応するCSSを 簡単に書くことができます しかし デザインのすべてを 論理プロパティで処理することはできません そこで 新しい 方向擬似クラスが役に立ちます ここでは テキストの方向によって 変形させたいアイコンがあります ヘッダーの方向がLTRのときは SVGを一方に回転させ ヘッダーの方向がRTLのときは もう一方に回転させます これは過去に複数言語の方向性を サポートするために 使われていたものより はるかに単純な手法です user-validとinvalid :has()への追加 :dir擬似クラスはすべてロバストで 簡潔なコードを書きやすくしています また今年は タイポグラフィの細部を完璧なまでに 洗練させることが可能な機能が いくつか追加されました まず 新しいline-heightの 単位を見てみましょう CSSには長さを定義するために使用できる さまざまな種類の単位があります svhやlvhのようにビューポートの サイズに対する相対的なものであったり cqbやcqiのようにコンテナのサイズに 対する相対的なものもあります そのほかの単位はタイポグラフィの サイズに対する相対的なものです 1exはフォントの x-heightに等しくなります chは1文字で フォントの0文字の インラインサイズに等しくなります 1つのicは 日中韓スクリプトにおける表意文字の インラインサイズで 横書きモードでは幅 縦書きモードでは高さになります これらの単位はしばらく前から ブラウザでサポートされています さて タイポグラフィのサイズに相対的な 新しい単位もあります 行の高さを表すlh単位と ルートの行の高さを表すrlh単位です これらの単位を使えば レイアウト内のあらゆるものを 行間のスペースにつなげることができます 例えば ルートHTML要素で line-heightを1.4に設定しました 次にセクション要素であるこの白いカードに 2rlhのパディングを設定します そして ブロック方向の見出しと 段落のマージンを1rlhに設定します これでテキストの行間には余白ではなく テキストがあるのと同じだけの 余白ができます これでタイポグラフィでいうところの 縦のリズムができました 行の高さの単位は垂直方向のリズムを 乱すような状況を防ぐことはできませんが Webに信じられないほど シンプルなツールをもたらし この長年にわたるタイポグラフィの伝統を 解きほぐすことに大きく近づけてくれます これにより活字と 活字の周りの空白との間に 親密なつながりを作り出すことができます Web上のデジタルタイポグラフィを 伝統的な組版の 高い水準まで磨き上げるには 多くの課題があります そのひとつがフォントのサイジングです Webデザイナーなら フォントファミリーやフォントサイズを 慎重に選んでいることでしょう しかし みまさんが望むフォントが ダウンロードできなかったり ユーザーのオペレーティングシステムで 利用できなかったりするかもしれません よって ブラウザにフォールバックプランを 提供するために font-familyで フォントのスタックを宣言するのが ベストプラクティスなのです 最初に見つかったフォントが使用されます 同様にフォントの大きさも Webデベロッパが コントロールできるものではありません 左がSF Hello 右がBaskervilleです 両者はまったく同じサイズに タイプセットされていますが SF Helloの方が行の枠内に より多くのスペースを埋めているため はるかに大きく見えます x-heightも大きいですね この違いはフォントファイルを作成する際の 選択によって生じます ここではある記事を font-size: 1.4remでタイプセットし その記事の中にあるすべてのコードに シンプルなフォントスタックを 定義している例を示しています コードが段落テキストよりも 小さく見えるのがわかります Fを比較すると特に顕著です コードが等幅に戻ると 段落テキストよりも大きく見えます コードのfont-sizeを記事の font-sizeの120%に調整することで Courierが使われているときの サイズを均等にすることができますが ブラウザがモノスペースに戻ると コードは段落テキストよりも さらに大きくなってしまいます 「この2つのフォントが同じサイズに 見えるようにしてください」と ブラウザに伝え ブラウザが そのやり方を見つける方法が必要です それがまさにfont-size-adjustです フォントの大きさを調整して 視覚的な一貫性を作ります 私はCSSを1行追加しました font-size-adjust: 0.47 そして今 私のタイプセットされたコードは スタック内の両方のフォントであっても 段落テキストと視覚的に一貫しています なぜ0.47なのか？ この数字の意味は何でしょう？ Webで使うような欧文フォントには フォントのサイズと x-heightの比率があります その比率は少し恣意的ですが 通常は50%前後です 記事要素にfont-size-adjust: 0.47を適用することで 実際にはブラウザに対して記事内の 全フォントのリサイズを指示しています つまり 段落のフォントやコードのフォント どのスタックから 使用されるフォントであっても それぞれのx-heightは指定された フォントサイズの47％になるようにします 0.47を選んだのはIowan Old Styleが フォントサイズ調整を適用していないときと 同じ見え方になるようにするためです 私たちはSafari 16.4で font-size-adjustの これらの基本的な機能をサポートしました Safari 17では より高度な機能のサポートを追加しています すべてのフォントをメインフォントと 一致させるために0.47のような マジックナンバーを探し出す必要が なくなれば良いと思いませんか？ from-font値によってブラウザに すべてを把握させることができます またSafari 17では サイズの一貫性を作成する際に どのメトリックを使用するかを指定できる 2値構文のサポートを追加しました デフォルトではex-heightですが 代わりにcap-heightやch-width ほかにもic-widthや ic-heightが使用可能です Safari 17ではsize-adjust ディスクリプタのサポートも追加しました これは@font-faceルールでフォントを セットアップするときに 同様の調整を可能にするものです それがfont-size-adjustです これはfont-sizeだけでは 簡単に調整できないものを もう少し調整可能にします しかし 新しい行の高さの単位と 活字の視覚的なサイズを 調整する機能を使っても 行ボックスのサイズに 奇妙なムラができることがあります 私たちはこの問題への いくつかの解決策に取り組んでいます テキストボックスのトリムもそのひとつです ある意味では テキストボックスのトリムは マージンのトリムに似ています どちらも不要な余白を 取り除くことができますが この場合はテキストボックス上です Web上で何かを縦に並べる際に 苦労したことがありますか？ この名前は縦方向中央揃えではありません 真ん中に線を引くと わかりやすいかもしれません 文字が中央より下にあります Web上ではよくあることです なぜでしょう？ 実は テキストボックスは縦に センタリングされているのです しかし グリフはこのボックスの 下の方にあります フォントに予約された余分な余白が 文字の上下にあります 上下の余分な余白の量は同じではありません なぜならフォントは下部に対して 上部と同じ量の余白を必しないからです それが垂直方向の中央揃えを狂わせています この余分な余白は非常に重要です アクセント記号 母音記号 その他多くのために予約されています しかし Web上のタイポグラフィ レイアウトを狂わせる可能性があります text-box-trimはすべての グリフを表示したまま レイアウトの目的のためにこの余分な余白を 取り除く方法を与えてくれます これは垂直方向のセンタリングに 役立つだけではありません これはキャップの高さの上部の フォントのために確保された― 余分な余白のせいで 見出しの上部を画像の上部に 簡単に合わせることができない例です 余分なスペースを取り除くことで 簡単に並べられるようになります これはすべて進行中の作業です プロパティ名はleading-trimから text-box-trimに変更済みです Safari Technology Preview 171の 時点では 画面に表示されているコードが その動作方法ですが これらの詳細にあまり固執しないでください 私たちはそれが 変化し続けることを期待しています おそらくこのようになるでしょう Safari Technology Previewで試して 感想をお聞かせください みなさんのようなWebデザイナーや デベロッパからの初期のフィードバックが CSSを最高のものにしてくれます

一方 ブラウザ間で大きなサポートがあり まもなくSafari 17にも登場する カウンタースタイルがあります HTMLの順序付きリストでは 要素を使用すると 項目リストに自動的にナンバリング されるのでおそらくよくご存じでしょう CSSは使用するナンバリングシステムを 変更する簡単なメカニズムを提供します ここではlist-style: devanagariを 適用しています CSSの1行で適用できる定義済みの ナンバリングシステムは何十種類もあり 世界中の多くの言語に対応しています しかし すべてではありません セルビア・クロアチア語はどうでしょう？ list-style: upper-serbo-croatianを 指定しても デフォルトの西アラビア数字が 表示されるだけです そこでカウンタースタイルの出番です ブラウザが行うのと同様に ナンバリングシステムが定義できます counter-styleという名前を付けて スタイルの質を定義します この場合 システムをアルファベットに 設定して記号を列挙します W3C Internationalization Working Groupは世界中の 何百もの文化をカバーするレディメイドの カウンタースタイルのドキュメントを 公開しています 私たちはWebKitがサポートする 言語の数を増やし CSS Working Groupで 全ブラウザがこれらすべてを サポートするよう議論を開始しました しかし それが実現するまでは この文書からコードスニペットをコピーして コードに貼り付けることができます また リストカウンターを 独自のスタイルにすることもできます このリストは最小4桁の 2進数で項目をカウントするようにしました また 絵文字のセットを 何度も繰り返すようにしました CSSカウンターはリスト以外にページ上の コンテンツのナンバリングにも使えます 長い文書の各セクションを始める 見出しのようなものです 例を挙げましょう 3つのH2見出しがあり それぞれ単語だけが書かれています CSSではcounter-resetを宣言して カウンターを作っています 「numbering」と名付け ゼロから カウントを始めるように設定しました そして:before疑似要素を使って カウンターを インクリメントし コンテンツに 表示するようブラウザに指示します デフォルトではカウンターは 西アラビア数字の1 2 3を使用しますが これは変更可能です 前と同じように カウンターを 好きなようにスタイルすることができます これがカウンターの作成と スタイルの設定方法です しかしタイポグラフィを 次のレベルに引き上げるため 今年 私たちが実行していることは これだけではありません 実際 今年はさらに多くの CSSが登場します Safari 16.2では GridとFlexboxの最後の ベースラインアライメントをサポートし font-variant-alternatesと @font-feature-valuesの中に いくつかの関数を追加して Open Type機能をさらにサポートしました Safari 16.4では Media Queriesの範囲構文と ブーリアンロジック @propertyなどの サポートも追加されました Safari 16.5では CSS Nestingのサポートも追加しました さらにSafari 17では フォント技術や フォント形式の検出機能 contain-intrinsic-size text-transform: full-widthおよび full-size-kanaなど その他多くの 機能が追加されています どのWebテクノロジーの実装や 改良を最も必要としているかを知らせるため 問題をファイルしたり ソーシャルメディアで pingを送ったり ブログ記事を 書いてくださったみなさんに感謝しています 私たちはみなさんの声に耳を傾けています また ほかに必要なものをお知らせください WebKitのissue trackerである bugs.webkit.org では Webテクノロジーに関するバグレポートや 機能要求を提出することができます Safariのインターフェイスに関する問題や iOS iPadOS macOSに関する問題は feedbackassistant.apple.comに お寄せください Safariで何がサポートされているか 最新情報を確認してください すでに配布されているものを 実装してほしいという デベロッパからの要望をよく耳にします Caniuseはそのための 素晴らしいリソースです webkit.orgでは Safariの各リリースに関する 詳細な記事やSafari Technology Previewのリリースノート Webインスペクタに関する 豊富なドキュメントなどをご覧いただけます Safari Technology Previewを ダウンロードして最新情報をご確認ください 約2週間ごとに更新されるため WebKitに追加された 最新の情報を入手できます Safari Technology Previewには デフォルトでプレビューできる すべての新機能も用意されています また Safari 17からは Safari設定の新しい機能フラグペインで 機能のオンとオフの切り替えができます 完全に再設計された開発メニューからは Mac上のWebインスペクタを iPhoneやiPad ワイヤレスも含む その他のデバイス上のWebサイトや Webアプリケーションに 素早く接続できます また 無料のデバイスシミュレータを ダウンロードして 開発メニューまたは新しくなった レスポンシブWebデザインモードから 手元にないデバイスで テストすることもできます WWDC23の「Safariの デベロッパ機能の再発見」を ご確認ください Webアプリケーションが Macにやってきます さらに今年はiPhoneとiPadの Webアプリケーションの改良が満載です 「Webアプリの新機能」は そのすべてを網羅しています また「Web向けメディアフォーマットの詳細」 では JPEG XLを含む SafariとWebKitに登場する 新しい画像フォーマットと 新しいManaged Media Source APIについてご紹介します 今年 WebKitとSafariに どれだけ多くの新しい Webテクノロジーが搭載されるのか 非常に楽しみです そのすべてを使ってみなさんが 開発するものを楽しみにしています ご視聴ありがとうございました