TPACのCSSワーキンググループ:CSSの新機能

公開: 2022-03-10
簡単な要約↬先週、レイチェル・アンドリューはW3C TPACで開催されたCSSワーキンググループの会議に出席し、この投稿のいくつかの議論をまとめました。これには、決定を下すのに役立つものも含まれます。

先週、私はW3CTPACとそこでのCSSワーキンググループ会議に出席しました。 仕様にさまざまな変更が加えられ、Webデザイナーや開発者にとって興味深い議論がありました。 この記事では、TPACで何が起こるかについて少し説明し、特にTPAC forCSSで話し合ったことの例とデモをいくつか示します。

TPACとは何ですか?

TPACは、W3Cの技術プレナリー/諮問委員会会議の週です。 W3Cの一部であるさまざまなワーキンググループのすべてが1つの屋根の下に集まるチャンス。 このイベントは毎年世界のさまざまな場所で開催され、今年はフランスのリヨンで開催されました。 TPACでは、CSSワーキンググループなどのワーキンググループが、他の時期と同じように独自の会議を開催しています。 しかし、私たち全員が1つの建物にいるので、他のグループの人々がオブザーバーとしてより簡単に来ることができ、クロスワーキンググループの利益について話し合うことができます。

TPACの参加者は通常、W3Cテクノロジーに取り組んでいる1つ以上のワーキンググループのメンバーです。 彼らは、メンバー組織の代表者または招待された専門家のいずれかになります。 W3Cワーキンググループの他の会議と同様に、TPACで開催されたすべての議論の議事録は、通常、会議中に記録されたIRCログとして公開されます。

CSSワーキンググループ

CSSワーキンググループは、TPACと、その年の少なくとも2回の他の機会に直接会います。 これは、毎週の電話に追加されます。 すべての会議で、仕様に関して提起されたさまざまな問題が議論され、決定が下されます。 一部の問題は、グループ全体で話し合うことができる、またはホワイトボードを回避したり、画面にデモを表示したりできるという利点があるため、対面での話し合いのために残されています。

問題が会議(対面または電話会議)で議論されると、関連するGitHubの問題が議論の議事録で更新されます。 つまり、追跡したい問題がある場合は、スターを付けて、いつ更新されるかを確認できます。 完全なIRC議事録は、wwwスタイルのメーリングリストにも掲載されています。

これが私たちがあなたにとって最も興味があると思うことの選択です。

ジャンプした後もっと! 以下を読み続けてください↓

CSSスクロールバー

CSS Scrollbars仕様は、スクロールバーのサイズと色をスタイリングする標準的な方法を提供することを目的としています。 Firefox Nightlyをお持ちの場合は、テストすることができます。 以下の例を見るには、Firefox Nightlyを使用し、Firefox Nightlyのhttps://about:configにアクセスして、 layout.css.scrollbar-color.enabled width.enabledフラグとlayout.css.scrollbar-width.enabledフラグを有効にします。

この仕様により、 scrollbar-widthscrollbar-colorの2つの新しいプロパティが提供されます。 1em scrollbar-widthプロパティは、 autothinnone 、またはlength (1emなど)の値を取ることができます。 lengthの値が仕様から削除されているように見えます。 ご想像のとおり、Web開発者は幅を操作して非常に使いにくいスクロールバーを作成できる可能性があるため、ブラウザが適切な正確な幅を決定できるようにするのではなく、薄くまたは太く表示する方がよい場合があります。スクロールバー。 Firefoxは長さオプションを実装していません。

値としてautoを使用する場合、ブラウザはデフォルトのスクロールバーを使用します。thinはthinスクロールバーを提供し、表示されるスクロールバーは表示されnoneん(ただし、要素は引き続きスクロール可能です)。

細いスクロールバーを備えたスクロール要素
この例では、 scrollbar-width: thinを設定しました。(大きなプレビュー)

CSSスクロールバーをサポートするブラウザーでは、デモでこれが実際に動作していることを確認できます。

CodePenのRachelAndrew(@rachelandrew)によるPen CSS Scrollbars:scrollbar-widthを参照してください。

CodePenのRachelAndrew(@rachelandrew)によるPen CSS Scrollbars:scrollbar-widthを参照してください。

scrollbar-colorプロパティは、予想どおり、スクロールバーの色を処理します。 スクロールバーには2つの部分があり、個別に色を付けることができます。

  • 親指
    スクロールすると上下に動くスライダー。
  • 追跡
    スクロールバーの背景。

scrollbar-colorプロパティの値は、 autodarklight 、および<color> <color>です。

キーワード値としてautoを使用すると、そのブラウザのデフォルトのスクロールバーの色が表示されます。darkは、そのプラットフォームのダークモードまたはカスタムダークモードのいずれかでdarkスクロールバーを提供し、プラットフォームのlightモードまたはカスタムライトモードを点灯します。 。

独自の色を設定するには、スペースで区切られた値として2つの色を追加します。 最初の色は親指に使用され、2番目の色はトラックに使用されます。 色の間に十分なコントラストがあることに注意する必要があります。そうしないと、スクロールバーが一部の人にとって使いにくい場合があります。

紫と白のスクロールバーを備えたスクロール要素
この例では、スクロールバー要素にカスタムカラーを設定しました。 (大プレビュー)

CSSスクロールバーをサポートするブラウザーでは、デモでこれを確認できます。

CodePenのPenCSS Scrollbars:scrollbar-color by Rachel Andrew(@rachelandrew)を参照してください。

CodePenのPenCSS Scrollbars:scrollbar-color by Rachel Andrew(@rachelandrew)を参照してください。

アスペクト比の単位

CSSのパディングハックを使用してアスペクト比ボックスを実現してきましたが、グリッドレイアウトの出現とコンテンツのサイズ変更の改善により、CSSでアスペクト比を実際に実行する方法がより差し迫ったニーズになっています。 。

この要件に関連してGitHubで提起された2つの問題があります。

  • 必要なアスペクト比の単位
  • アスペクト比。

現在、CSSサイジングのレベル4にドラフト仕様があり、会議の決定は、決定を下す前にGitHubでさらに議論する必要があるというものでした。 したがって、これに興味がある場合、または追加のユースケースがある場合は、CSSワーキンググループがこれらの問題に関するコメントに興味を持っています。

:where()機能的な疑似クラス

昨年、CSSWGは、 :matches()のように機能するが、特異性がゼロの疑似クラスを追加することを決議しました。これにより、後の要素の特異性を人為的に膨らませてデフォルトのスタイルシートの何かをオーバーライドする必要なしに、簡単にオーバーライドできます。

:matches()疑似クラスは、レベル4セレクターであるため、初めて使用する場合がありますが、CSSを適用するセレクターのグループを指定できます。 たとえば、次のように書くことができます。

 .foo a:hover, pa:hover { color: green; }

または:matches()を使用

:matches(.foo, p) a:hover { color: green; }

同じ2つのルールを設定するためだけにセレクターのスタックが大量にある場合は、これがどれほど役立つかがわかります。 次のCodePenは、 webkit-anyおよび-moz-anyのプレフィックス名を使用して、 matches()機能を示しています。 MDNのmatches()について詳しく読むこともできます。

CodePenのPen:matches()およびRachel Andrew(@rachelandrew)によるプレフィックス付きバージョンを参照してください。

CodePenのPen:matches()およびRachel Andrew(@rachelandrew)によるプレフィックス付きバージョンを参照してください。

この種のセレクターのスタックを頻繁に行う場所、つまり:matches()が最も役立つ場所は、ある種の初期のデフォルトのスタイルシートです。 ただし、これらのデフォルトを上書きする場合は、デフォルトよりも具体的な方法で上書きが行われるように注意する必要があります。 ゼロ特異性バージョンが提案されたのはこのためです。

会議で議論された問題は、この疑似クラスの命名に関するものでした。ここで最終的な解決策を確認できます。さまざまな名前が除外された理由がわからない場合は、スレッド全体をご覧ください。 CSSで名前を付けるのは非常に困難です。なぜなら、私たち全員がCSSを永遠に使用しなければならないからです。 多くの議論の末、グループは投票し、このセレクターを:where()と呼ぶことにしました。

会議以来、そして私がこの投稿を書いている間に、 matches()の名前をis() )に変更するという提案が出されました。 いずれにせよ強い気持ちがあれば、問題を見てコメントしてください!

マージンとパディングの論理的な省略形

名前の付け方については、過去にSmashing Magazineで論理プロパティと値について書いたことがありますが、「論理プロパティと値について」を参照してください。 これらのプロパティと値は、フローの相対的なマッピングを提供します。 これは、英語など、水平上から下への書き込みモード以外の書き込みモードを使用している場合、余白やパディング、幅と高さはテキストの方向に従い、物理的な画面サイズにリンクされないことを意味します。

たとえば、物理的なマージンについては、次のようになります。

  • margin-top
  • margin-right
  • margin-bottom
  • margin-left

これらの論理マッピング(horizo​​ntal-tbを想定)は次のとおりです。

  • margin-block-start
  • margin-inline-end
  • margin-block-end
  • margin-inline-start

2つの値の省略形を持つことができます。 たとえば、 margin-block-startmargin-block-end両方を省略形として設定するには、 margin-block: 20px 1emを使用できます。 ブロック次元の開始エッジを表す最初の値、ブロック次元の終了エッジを表す2番目の値。

ただし、4つの値の短縮marginに関しては問題が発生します。 そのプロパティ名は物理的なマージンに使用されます—論理的な4つの値のバージョンをどのように示しますか? ファイルの先頭にあるスイッチなど、さまざまなことが提案されています。

 @mode "logical";

または、メディアクエリに少し似ているブロックを使用するには:

 @mode (flow-mode: relative) { }

次に、句読文字を使用したり、新しいプロパティ名を作成したりして、キーワード修飾子に関するさまざまな提案を行います。

 margin: relative 1em 2em 3em 4em; margin: 1em 2em 3em 4em !relative; margin-relative: 1em 2em 3em 4em; ~margin: 1em 2em 3em 4em;

問題を読んで、検討されているさまざまなことを確認できます。 議論された問題は、論理バージョンが一般的にデフォルトになる可能性がある一方で、画面のジオメトリに関連するものが必要になる場合があるということでした。 1つのスタイルシートに両方のオプションを含めることができる必要があります。 CSSの上部に@mode設定があると、混乱する可能性があります。 誰かがスタイルシートのチャンクをコピーして貼り付けると失敗します。

私の好みは、ある種のキーワード値を持つことです。 そうすれば、ルールを見ると、少しエレガントに見えなくても、どのモードが使用されているかを正確に確認できます。 これは、プリプロセッサが処理できるようなものです。 すべてのプロパティと値で論理バージョンを使用する必要がある場合。

この問題を解決することはできませんでした。そのため、これらのどれが最適かについて考えている場合、または説明していない問題が見られる場合は、GitHubで問題についてコメントしてください。

Webプラットフォームテストディスカッション

CSSワーキンググループの会議で、そしてアンカンファレンススタイルのテクニカルプレナリーデーで、CSS仕様のテストの作成にもっと多くの人を参加させる方法について話し合いました。 Webプラットフォームテストプロジェクトは、すべてのWebプラットフォームにテストを提供することを目的としています。 これらのテストは、ブラウザベンダーがブラウザが仕様に関して正しいかどうかを確認するのに役立ちます。 CSSワーキンググループの目的は、候補推奨(CR)ステータスに達した仕様への規範的な変更には、テストを伴う必要があることです。 仕様がCRに入ると、ブラウザにその仕様を実装してフィードバックを提供するように求めているため、これは理にかなっています。 コードを更新できるように、仕様に変更があるかどうかを知る必要があります。

問題は、スペックを作成する人が非常に少ないことです。そのため、スペック作成者がすべてのテストを作成する必要があると、CSSの進行が遅くなります。 Webプラットフォームに貢献し、仕様がどのように機能するかについて深い知識を得る方法であるため、他の人がテストを作成するのを見てみたいと思います。 そこで私たちは、人々にその取り組みへの参加を促す方法について考えるために集まりました。 私は過去にこの主題について書いたことがあります。 プラットフォームのテストを作成するというアイデアに興味がある場合は、「Webプラットフォームのテスト」に関する24の方法に関する記事を参照してください。

仕事で!

TPACは私の個人的なやることリストにかなり追加されました。 ただし、仕様の編集、テストの作成に関するヒントを入手し、共同編集者であるMulti-ColumnLayout仕様をCRステータスに戻す計画を立てることができました。 ミーティングのファンではない私は、これらの対面ミーティングがWebプラットフォームにとってどれほど価値があるかを知り、私たちが貢献している人々に、私たちが個々に開発している知識を共有する機会を与えています。 しかし、より多くの人々がプラットフォームの開発と使用に関与できるようにするために、その知識をグループの外で共有することが重要だと感じています。

CSSワーキンググループがどのように機能するか、そして新しいCSSがどのように発明され、ブラウザに組み込まれるかに興味がある場合は、2017年のCSSConf.euプレゼンテーション「CSSはどこから来たのか」を確認してください。 そして、彼女の投稿「W3CでのCSSワーキンググループの内部ビュー」のファンタサイからの情報。