Gutenberg: ブロック固有のレスポンシブコントロール

このトピックに関するいくつかの最初の調査を共有します。

この時点でレスポンシブコントロールを最も緊急に必要としているブロックは、列ブロックです。 現在、列は小さな画面に自動的にスタックされますが、何も表示されません。 Media＆Textブロックはモバイルでもスタックできますが、その動作をオンまたはオフにするトグルスイッチが含まれています。 これは、レスポンシブコントロールの優れたベースラインです。

多くのユーザーにとって、このトグルは十分な制御を提供します。現代のWebサイトビルダーは、必要に応じてこれをすべて自動的に処理できると考えるのが妥当です。 ただし、さまざまなブレークポイントに表示する列の数を指定する必要があるユーザーには、ある程度の微調整された制御を提供する必要があります。

それを念頭に置いて、私はいくつかのコアアイデアを中心に調査を構築しました。

1. レスポンシブコントロールは「詳細」パネルに表示する必要があります。 このパネルは現在非常に十分に活用されていませんが、レスポンシブ設定のための合理的な家のようです。 適切なデフォルトを設定する必要があります。ほとんどの場合、ユーザーはこのパネルにアクセスすることはありません。
2. 3つの異なるオプションを許可します：
   A.スマートなデフォルト：モバイルで列をスタックします。
   B.どこでも同じ数の列を使用します。
   C.モバイル、タブレット、およびデスクトップの画面サイズの列数を指定します。

それらを念頭に置いて、私はいくつかのプロトタイプを作成しました。

デスクトッププロトタイプ（Figma）
モバイルプロトタイプ（Figma）

_参照用のスクリーンショット：_

クリックするとお気づきのとおり、オプション（C）が選択されている場合、[デバイス]パネルに表示されるデバイスオプションは、使用していないデバイスのみです。 電話を使用している場合、[列]の下のデフォルトのスライダーで、モバイルデバイスに表示される列の数を制御します。 オプション（C）を選択したまま、デスクトップマシンからこのブロックにアクセスすると、デフォルトのスライダーでデスクトップビューに表示される列の数が制御されます。 これにより、同じことを行うコントロールの重複を防ぐことができますが、直感的であるか混乱するかは完全にはわかりません。 別の方法は、そこにあるすべてのデバイスを表示し、オプション（C）が選択されているときにデフォルトのスライダーを無効にすることですが、それは私には奇妙に思えました。

フィードバックに興味があります！ また、これらの種類のコントロールが他のタイプの設定にどのように拡張されるのか興味があります。このようなレスポンシブコントロールには、他にどのようなブロックが役立つでしょうか。

私は最近、次の数週間で開始される作業プロジェクトのためにかなり大きなテーマを構築しています。 私はおそらく私の考えのいくつかを共有するべきだと思いました。 次のパネルは、さまざまなデバイスでスタック列を処理するために実装したものです。 各デバイスは、明示的に設定することも、順序を逆にすることもできます。 （列cssにflexを使用）。

上部（マージン/パディング）もすべてのブロックで利用できます。 エディターから完全にいくつかの非常に素晴らしいレイアウトを作成することができます。

私が見たいのは、ウィンドウのサイズを変更せずにエディターをそれぞれのモードに切り替えるために、エディターの上部にあるデスクトップ/タブレット/モバイルボタンです。 これにより、すべての応答レベルで非常に迅速な構築が可能になります。 これらの3つのモードは私の目的では機能しますが、テーマでさまざまな応答レベルを構成して、それらのいずれかを切り替えることができる可能性があります。

iframeベースのエディターがなくなったため、これを実行するにはもう少し手間がかかることは明らかです。 同様のことをどのように達成できるかについて少し考えたので、エディターはメディアクエリを使用できず、代わりにcssをすべてのブロックのエディター用に特別に開発する必要があると思います。 とにかく自分のテーマでこれをやっています。 「editor-styles-wrapper」divの現在の応答がクラスに追加されている場合、クラスベースの応答の代わりにメディアクエリを簡単に使用できます。
例：.editor-styles-wrapper--mobile {}

私が見たいのは、ウィンドウのサイズを変更せずにエディターをそれぞれのモードに切り替えるために、エディターの上部にあるデスクトップ/タブレット/モバイルボタンです。 これにより、すべての応答レベルで非常に迅速な構築が可能になります。 これらの3つのモードは私の目的では機能しますが、テーマでさまざまな応答レベルを構成して、それらのいずれかを切り替えることができる可能性があります。

共有してくれてありがとう、@ mattbolt。 まだご覧になっていない方のために、まさにここでそのようなことについて話し合っています：＃13203

レスポンシブマージン/パディングルールについて：マージン+パディングのより微調整されたコントロールを見てみたいと思います。 しかし、大多数のユーザーにとって、それらはグローバルレベルでより有益であると思います。 そのため、上記の調査からそれらを除外しました。 マージン/パディングコントロールを_どこかに_含める必要があると思いますが、ブロックごとは（少なくともコアに関しては）少し細かすぎるようです。

heya @mapk @ kjellr- ＃13203にコメントを残しましたが、この号でもその一部を強調する価値があると思います。

これは私たちが取り組んでいる最新のプロトタイプです-これは、＃13203で指摘した最近のユーザビリティテストから得たフィードバックに基づいています。

フィグマ

私たちのブロックにはいくつかの異なる設定があり、それらのすべてがデバイスごとに編集可能である必要はありません。 そのため、レスポンシブコントロールを個々の設定に配置することは理にかなっていると思います。 上記の例では、レイアウトのレスポンシブコントロールを調整できますが、カテゴリによるフィルタリングは調整できません。 （カテゴリによるフィルタリングは、常にすべてのデバイスサイズに適用される必要があります）また、スマートデフォルトを使用したいので、デバイスサイズごとにレイアウトを調整する必要はありません。

テストの最初の部分は、レスポンシブレイアウトコントロールを備えていないライブブロックを使用して実行されました。 参加者の多くは、「モバイルデバイスのこれらのレイアウト設定を変更するにはどうすればよいですか？」という質問をしました。 私たちが思っているよりも多くの人がこの種のきめ細かい制御を望んでいると私は信じています。

レスポンシブコントロールを詳細設定に配置することも別のオプションですが、見つけるのが難しくなると思います...それは1回限りの問題ですが、一度見つけたら、次にどこで探すかがわかります時間。 そうは言っても、ユーザーが調整している設定のコンテキストでレスポンシブコントロールを維持することにも何かがあると思います。

この最新バージョンをテストする機会はありませんでしたが、すぐにテストすることを望んでいます。

@kjellr

フィードバックに興味があります！ また、これらの種類のコントロールが他のタイプの設定にどのように拡張されるのか興味があります。このようなレスポンシブコントロールには、他にどのようなブロックが役立つでしょうか。

私はあなたがとても複雑なものを取り、誰もが理解できるようにそれを使いやすい方法で単純化した方法が本当に好きです。 メリットが得られる可能性のあるもう1つのブロックは、基本的な列調整設定がすでにあるGalleryブロックです。

@mattbolt

上部（マージン/パディング）もすべてのブロックで利用できます。

ありがとうマット！ マージンとパディングの調査は、ここでも共有するのに適しています。 ＃11824

@LevinMedia

参加者の多くは、「モバイルデバイスのこれらのレイアウト設定を変更するにはどうすればよいですか？」という質問をしました。

本当に面白いです！

そうは言っても、ユーザーが調整している設定のコンテキストでレスポンシブコントロールを維持することにも何かがあると思います。

これは、製品番号の調整も可能にするWooブロックとの関連で意味があります。 @kjellrのモックアップのように、調整が1つ（つまり列）しかない場合に必要だと思いますか？

これまでのモックアップのほとんどがアイコンのみのコントロールを使用していることに気づいています。 理想的には、アクセシビリティ（および一般的な使いやすさ）のために、レスポンシブコントロールに表示可能なラベルがあれば最高です。 これがどれほど実現可能かはわかりませんが、グーテンベルクはさまざまな分野でアクセシビリティに苦労しているため、指摘したいと思います。アイコンのみのUIを追加しないようにすることをお勧めします。

考慮する必要があるもう1つのことは、レスポンシブ設定を必要とする可能性のあるツールバーオプションです。 たとえば、Coverブロックにあるブロック幅機能。 デスクトップでは幅を狭くし、モバイルでは全幅が必要になる場合があります。

Heya @mapk

@kjellrのモックアップのように、調整が1つ（つまり列）しかない場合に必要だと思いますか？

私がやります。 発見可能性は私にとってその理由の大きな部分です。 レスポンシブ設定は、操作されている設定のコンテキストに直接配置されます。

ブロックに複数のレスポンシブ設定があり、それらすべてがレイアウトのように1つのバケットにうまく収まるとは限らない場合が多いと思います。

たとえば、上記の2番目の質問です。

デバイスの幅に基づいてブロックを表示/非表示にする必要がありますか？

以前のページビルダーの使用法では、その質問に対する答えは「はい」でした。 独自のレスポンシブコントロールを使用して「可視性」設定を追加すると、それが可能になります。

後から考えると、この場合、可視性は最良の例ではない可能性があります。そのようなものは、トグルの単純なリストとしておそらくより適しているからです。

[トグル]デスクトップに表示
[トグル]タブレットに表示
[トグル]モバイルで表示

参加者の多くは、「モバイルデバイスのこれらのレイアウト設定を変更するにはどうすればよいですか？」という質問をしました。

@LevinMediaこの調査結果をフォローアップしたいと思いました。このテストに参加したユーザーのプールについて、さらに詳細を共有できますか？ この発見は私を少し驚かせたので、もっと学びたいと思います。 ありがとう！

ここで重要な考慮事項は、レスポンシブ操作が全体的なオーサリングエクスペリエンスにどの程度の影響を与えるかについての私たちの期待です。 現在だけでなく、将来も。

ブロックのデフォルト設定はどれですか？ デスクトップ、モバイル、タブレット？

その質問は今私にとって頭の中にあります。 私は@kjellrさんのような理由のために設計多くは、上記の@mapk、私はそれが『モバイル第一』体験に移行する方法をうまくわかりませんか？

@LevinMediaが言ったように、最近のユーザビリティテストのほとんどの参加者は、すでにモバイル設定に強い関心を示しており、それが彼らにとって「非常に重要」であると宣言しました。 もちろん、各参加者はWooCommerceユーザーであり、おそらく他のユーザーよりも「技術に精通している」ため、そこにはある程度のバイアスがあると言わなければなりません。

現時点での私の傾向は、 @ LevinMediaに同意することです。ここではコンテキストが非常に重要になります。 ユーザーがこれらの設定をするのかをは非常に簡単なはずだと思います。

関連するメモとして、私は個人的に、設定パネルの「詳細」セクションが好きではありません-ほとんどすべてのユースケースで。 それは私には恣意的であり、最初にブロックを操作したときにそこにどのような設定が見つかるかは文字通り予想していません。

その質問は今私にとって頭の中にあります。 私は@kjellrさんのような理由のために設計多くは、上記の@mapk、私はそれが『モバイル第一』体験に移行する方法をうまくわかりませんか？

これらの線に沿って、上記の私のアプローチの考慮事項の1つは、編集元の画面を認識していることです。 言い換えれば、あなたが使用しているデバイスは、あなたが「最初に」設計しているデバイスです。 携帯電話からアクセスする場合、メインエリアに表示されるスライダーはモバイルスライダーのみです。 残りはAdvancedでダウンしています。 または、タブレットからアクセスした場合：タブレットがデフォルトのコントロールとして表示され、その他は下に表示されます。 これは非常に混乱を招く可能性があります。上記のメモで最初に述べたように、通常のサイドバーパネルとAdvancedの間でコントロールを分割することは私には少し気分が悪いです。

しかし、一般的に、私はデバイスを意識するという一般的な考え方が好きです。 @LevinMediaが投稿したモックアップでは、これはデフォルトで、モバイルデバイスでアクセスするときにモバイルタブを選択すること、またはタブレットからアクセスするときにタブレットを選択することと同じです（実際、モックアップの1つでそれを見たと思います） 、しかし私は今それを見つけることができません。）

このために少し異なる方向を考えて少し時間を費やしました。 以前の反復から私に完全に満足していなかったことの1つは、メインサイドバーの[列]パネルと[詳細]パネルの間で列コントロールを分離する方法でした。

この探索により、オプションが少し単純化され、すべてがメインの「列」領域に戻ります。

🖥デスクトッププロトタイプ

📱モバイルプロトタイプ

最初のフレームは、現在利用可能な「Stackonmobile」トグルをMedia＆Textブロックに追加するだけです。 デフォルトではオンになっており、すべてが自動的に処理されます。 これは、これらの設定を管理したくないユーザーに最適な設定です。 しかし、今日とは異なり、ユーザーがそれをオフに切り替えると、代わりに、より微調整されたコントロールが表示されます。 ここから、そのままにしておくか（デフォルトではそれぞれ同じサイズになります）、デバイスタイプごとに異なる列数を設定するように調整できます。

いくつかの考慮事項：

• 一般的に、これにはより良いラベル付けと説明が必要です。
• これは1つのオプションで正常に機能しますが、ブレークポイントごとに複数の設定がある場合は適切にスケーリングされません。
• 通常、トグルスイッチがオフになっていることに基づいてコントロールを表示/非表示にすることはありません。 それがここで本当に意味があるかどうかはわかりません。
• 上記に関連して：階層的には、トグルスイッチがその上のフィールドに影響を与えるのは奇妙に思えます。 この場合、スイッチを使用する方が自然な場合があります。 ただし、ここで人々がやりたいと思う主なことは、レスポンシブコントロールを切り替えずに列数を調整することであるため、これも正しくは感じられません。

ここでの考えを探求し、読んでいるときに私が繰り返し返す1つの質問：これは_コア内でどれほど単純または複雑である必要がありますか？_一部のカスタムブロックには、各ブレークポイントの個別の設定が確実に含まれます：マージン、パディング、ブロックの表示と非表示など。それは、ユーザーベースが快適なものかもしれません。 ただし、初心者ユーザーにとっては圧倒される可能性があるため、必ずしもそのレベルの制御をデフォルトのブロックに含める必要はありません。 そうは言っても...これらの非常に複雑なシナリオにスケールアップできるデザインパターンを確立することは、私たちにとって有益である可能性があります。そうすれば、すべての場合にこれをどのように処理するかを示すことができます。 レスポンシブ設定を管理する必要がない人と、これらのことについて本当に具体的にしたい人との間でスケーリングする単純なパターンをどのように定義できますか？

素敵なモックアップ、@ kjellr！

一般的に、これにはより良いラベル付けと説明が必要です。

少なくとも、デバイスアイコンは、「🖵デスクトップ」などの各スライダーのラベルに移動する必要があります。

これは1つのオプションで正常に機能しますが、ブレークポイントごとに複数の設定がある場合は適切にスケーリングされません。

これに対する答えはトグルにあると思います。 すべてのレスポンシブコントロールに、設定のレスポンシブのカスタマイズを有効/無効にするトグルがある場合はどうなりますか？ DiviBuilderにはこれにかなり似たものがあります。

上記に関連して：階層的には、トグルスイッチがその上のフィールドに影響を与えるのは奇妙に思えます。 この場合、スイッチを使用する方が自然な場合があります。 ただし、ここで人々がやりたいと思う主なことは、レスポンシブコントロールを切り替えるのではなく、列数を調整することなので、これも正しくありません。

トグルはスライダーに影響するので、スライダーの上にトグルを置く方がいいと思います。

ただし、初心者ユーザーにとっては圧倒される可能性があるため、必ずしもそのレベルの制御をデフォルトのブロックに含める必要はありません。

デフォルトでモックアップにあるようなトグルの後ろに、または単にデフォルトで閉じたアコーディオンに保持することによって、多くのものを隠すことができると思います。 マージンとパディングは両方とも同じアコーディオンである可能性があり、モックアップのようにトグルでこれらのコントロールの応答性を切り替えることができます。 このアコーディオンがより一般的なすべてのオプションの下に配置され、デフォルトで閉じられている場合、これによってユーザーがオプションで過負荷になることはないと思います。

@ kjellr-ジェイのコメントのフォローアップ。 サンプルサイズが小さかった（参加者は8人）ので、前述したように、より多くのテスト/調査が確実に必要です。

すべての参加者はWooCommerceデザインフィードバックグループから来ました-ジェイが述べたように、私たちの参加者、そして特にこの参加者グループは、DIYショップの所有者ではなく、より経験豊富なビルダー/ストア

昨日投稿しアップ：

🖥デスクトッププロトタイプ

📱モバイルプロトタイプ

@jasmussenや他の人々と一緒にそれをToggleの代わりにButtonGroupを、いくつかの（うまくいけば）より明確なコピーと一緒に使用してみました。 この方法でフォーマットとコピーを変更すると、より自然に列コントロールの上にコントロールを配置できます。 それは階層的にもっと期待されているように感じます。

このアプローチについて私が本当に気に入っていることの1つは、これらのコントロールはデフォルトでブロックによって処理される必要があるという先例を設定することです。 ブロック設計者は、独自のブレークポイントを定義できるため、ユーザーよりもはるかに多くの制御を行うことができます。 ブロック設計者はまた、多くのユーザーよりもレスポンシブデザインの経験が豊富であり、ここでベストプラクティスを適用できるはずです。

また、ユーザーが手動に切り替え、ブレークポイント設定に多くの調整を加え、物事を台無しにした場合、「自動」オプションはユーザーのためのクイックエスケープハッチです。

ここで整理する必要のある奇妙なことがまだいくつかあります（たとえば、これらの正確なブレークポイントを誰が選択するのですか？）。 しかし、これはより複雑な設定に拡張できるよう

大好きだ、ケル。 これにより、ほとんどの場合に最適なデフォルトが可能になりますが、必要なユーザーには細分性があります。 また、columnsブロックから他のブロック、さらにはサードパーティのブロックまでスケーリングできるパターンのように感じます。 よくやった。

とても素敵です、@ kjellr！

アクセシビリティと明確さの理由から、各スライダーにはテキストラベルを表示する必要があると思いますが、それ以外は、この機能を実際に実装できるようになりつつあると思います。

また、アクセシビリティの観点から、このコンテキストではボタングループがトグルよりも適切であると確信していますか？

私はこれらの概念が好きで、列に対してはうまく機能しますが、両方にいくつかの小さな問題があります。

トグルのコンセプトは私のお気に入りの2つですが、ラベルは毎回異なるため、設定間で一貫性がありません。 そのため、設定にモバイルオプションがあることはすぐにはわかりません。 スケーラビリティが心配です。

セグメント化されたコントロールの概念は、実際に列の設定を操作する前に、作成者に自動か手動かを選択するように求めているため、少し奇妙に感じます。 これは、設定で「列」セクションを開いたときに表示されるとは思わないものです。 ラベルも私には特にはっきりとは感じません。

@LevinMediaが以前に共有したコンセプトについてもっと考えを聞きたいと思っています。 一連のユーザビリティテストの後でその解決策に到達しましたが、他のブロック作成者が行っていることとかなり一致しているようです。 そのアプローチを割り引く理由はありますか？

@LevinMediaが以前に共有したコンセプトについてもっと考えを聞きたいと思っています。 一連のユーザビリティテストの後でその解決策に到達しましたが、他のブロック作成者が行っていることとかなり一致しているようです。 そのアプローチを割り引く理由はありますか？

承知しました！ 私はその解決策を軽視するつもりはありません。 その方向から欠落していると私が思う重要なことは、「それを処理させてください」オプションの提示です。 より上級のユーザーはすぐにジャンプして、これらの各デバイスアイコンの下にあるすべてを編集しますが、それは通知ユーザーにとっては多くの作業になります。 特に私たちが彼らのためにそれを自動的に処理することができたとき。

それとは別に、その方向の核心は、デバイスのセグメント化されたコントロールです。

かなりうまく機能し、ここで使用するパターンになる可能性があると思いますが、その上にセグメント化されたコントロールを

その方向から欠落していると私が思う重要なことは、「それを処理させてください」オプションの提示です。

ガッチャ。 それで、懸念はタブレット/モバイルトグルがオプションであると感じないということですか？ それは理にかなっている。 しかし、デバイスのセグメント化されたコントロールは、さまざまな設定タイプ間でより一貫したパターンを提供し、したがってより適切にスケーリングできると思います。 使いやすさvs.一貫性とスケーラビリティは難しいものです！

これらの概念をもう少しストレステストするために、列の下に別のオプションを追加することをお勧めします。これには、レスポンシブコンポーネントである行も含まれます。

これらの概念をもう少しストレステストするために、列の下に別のオプションを追加することをお勧めします。これには、レスポンシブコンポーネントである行も含まれます。

ええ、私はそれを試すためにこのようなものをすばやくモックアップしました。 技術的には機能しますが、少し繰り返し+長蛇の列になります。

@kjellrと私が追加の考えのためにここで取り組んだ別の概念をログに記録します。

Figmaプロトタイプ

好きなもの：

1. つまり、作成者は、物事を自動的に処理したい場合、1つの設定を調整するだけで済みます。
2. 「自動モード」でも、モバイルで取得する列の数を確認できます。謎はありません。
3. 完全に制御するための設定のリンクを解除するのは、ワンクリックです。

私がそれほど熱心ではないこと：

1. 視覚的にかなりのスペースを占めます
2. 単純な「モバイルでの列のスタック」オプションはありません。 正直なところ、それが大したことかどうかはわかりませんが…

ラベルを付けるのが簡単なので、チェーンリンクアイコンボタンよりも標準のトグルの方が好きだと思います。 UIはアクセシビリティを念頭に置いて設計する必要があることに注意してください。

UIは次のようになると思います。

列数
（ON⚫）モバイルデバイスの列を自動的に調整します。
――――― o― [__4]

列数
（⚫OFF）モバイルデバイスの列を自動的に調整します。

🖥️デスクトップ
――――― o― [__4]
⬛タブレット
――― o --― [__3]
📱電話
―o --- ― [__2]

可視性
（ON⚫）🖥️デスクトップに表示
（ON⚫）⬛タブレットに表示
（ON⚫）📱モバイルで表示

技術的には「リンク」の概念は同じものであり、トグルは視覚的に異なる場所にあります。 それでも、ほぼ同じ方法でスクリーンリーダーに表示でき、ツールチップをラベルとして追加できます（ただし、どの程度アクセスできるかはわかりません）。 また、「自動」モードであっても、プレビューを強制せずに、小さな画面で使用される列の数を作成者に通知するという追加の利点もあります。 おそらくそれはそれほど有用ではありません-テストなしで知るのは難しいです。

ただし、この形式は可視性の設定ではうまく機能しないことに同意します。 これらのオプションをリンクすることは無意味に思えます。 しかし、私にとって、その設定には自動/手動の切り替えも必要ありません。 デバイスごとに1つの可視性トグルが最も理にかなっています。

技術的には「リンク」の概念は同じものであり、トグルは視覚的に異なる場所にあります。 それでも、ほぼ同じ方法でスクリーンリーダーに表示でき、ツールチップをラベルとして追加できます（ただし、どの程度アクセスできるかはわかりません）。

目に見えるラベルは常にアクセスしやすくなっています。 また、コントロールの視覚的な順序はタブの順序と一致し、タブの順序は情報アーキテクチャに従う必要があることにも注意してください。つまり、論理的に使用するコントロールは、後で使用するコントロールの前に表示されます。見出しのように、見出しの段落の前に来ます。 @aferciaにpingを

また、「自動」モードであっても、プレビューを強制せずに、小さな画面で使用される列の数を作成者に通知するという追加の利点もあります。 おそらくそれはそれほど有用ではありません-テストなしで知るのは難しいです。

これは間違いなく素晴らしい利点ですが、デフォルトで無効にされたコントロールの束を表示することが、UIが圧倒されるのを防ごうとするのに適しているかどうかはわかりません。 個人的には気になりませんが、気になる人もいます。

このアイデアとディスカッションが大好きです！

これまでのところ、議論の焦点は管理UXに向けられているようです。
ただし、フロントエンド、コンテンツファースト、および最新のWebについて考えるための資料を提供したいと思います。

通常のユーザーに「レスポンシブデザイン」を理解させることになると、3つのデバイスのパラダイムに勝るものはありません。 3つのデバイスの3つのデザインは、実際にはレスポンシブデザインではありません。 アダプティブデザインです。 それは、現代のウェブには存在しない、ピクセルパーフェクトの夢のようなものです。 それは堅く、壊れやすく、将来の証拠ではなく、ユーザーが期待するものを常に生み出すとは限りません。

新しいCSS機能は、アダプティブデザインからレスポンシブデザインへと私たちを導くために、常にリリースされています。 rem 、 vw 、 flex 、 grid 。

レスポンシブデザインとは、デザインにコンテンツを指示させて妥協させるのではなく、コンテンツに情報を提供させることです。

これがTwentyNineteenのコラムビューです

私のサイトのデザインで6列のテキストが必要な場合は、段落の幅が150px未満になる前に、デザインを少し妥協したいと思います。

Flexboxはこれをかなり自動化できます。 やってみよう。

.wp-block-columns {
    display: flex;
    flex-wrap: wrap;
}

.wp-block-column {
    flex: auto;
    width: 100%;
    margin: 0 1rem 1rem;
}

.has-4-columns .wp-block-column {
    width: calc(100% / 4 - 2rem);
}

.has-6-columns .wp-block-column {
    width: calc(100% / 6 - 2rem);
}

.wp-block-column {
    min-width: 100px
}

これまでに説明したことは、UXの観点からは素晴らしいことですが、次のようになります。

3つの異なるオプションを許可します。
A.スマートなデフォルト：モバイルで列をスタックします。
B.どこでも同じ数の列を使用します。
C.モバイル、タブレット、およびデスクトップの画面サイズの列数を指定します。

私はこれをコンテンツファーストの観点からそこに投げ出したい：

多分これらの3つのオプション？
A.スマートデフォルト：最小列幅は200px（ish）です。
B.列数を指定します。
C.列が次の行にプッシュされる最小列幅を微調整します。

これを持ってきてくれてありがとう、@ meh。 あなたはこれの多くについて絶対に正しいです—それは間違いなく私の心にもありました。

私にとって最も重要な部分はこのビットです。レスポンシブデザインを人々に理解させるためのデバイスパラダイムに勝るものはありません。 彼らはアイコンを見て、すぐにそれを手に入れます。 「列が次の行にプッシュされる最小列幅を微調整する」などの設定は私たちには理にかなっていますが、それらははるかに抽象的であり、ユーザーが理解するためにより多くの頭脳を必要とします。 多くの専門家は真のレスポンシブデザインを理解するのに苦労しているため、これをユーザーに伝える最も簡単な方法を探す必要があります。

真のレスポンシブデザインは、コンテキストとコンテンツに大きく依存しています。 提案したような3つのオプションは、columnsブロックではうまく機能する可能性がありますが、製品または作成者のbioブロックの設定は完全に異なる場合があります。 チケットの主要な目標の1つは、さまざまなコンテキストで機能するソリューションを見つけ、ブロックの設計者/開発者が従う共通のパターンを作成することです。 これが、上記で投稿し

お気づきのように、デザイナーと開発者は、任意のデバイス測定ではなく、コンテンツがレイアウトを壊す必要がある場所にブレークポイントを設定することに大きくシフトしています。 私たちはそれを行うのが得意です（主に😄）。 各ブロックの「スマートデフォルト」は、それに取り組むのに最適な場所だと思います。 ブロックの設計者/開発者は（一般に）ブロックに含まれる可能性のあるコンテンツの種類を知っており、理想的には、デフォルトの状態でこれらのデバイスブレークポイントに準拠する必要はありません。 ユーザーがこれらを自分で管理することを決定した場合、開発者が組み込んだ非常に具体的なレスポンシブルールを削除し、ユーザーが編集できる、より標準化されたわかりやすい代替手段を提供できます。

それはすべて完全に議論の余地がありますが、少なくともこのトピックについての私の考えです。 🙂

はい、デバイス駆動型ソリューションを検討する理由を理解し、同意します💯。 計画中、このバグを耳に貼り付けたかっただけです。

妥協点があると思います。 ほとんどの場合、CSSが渡された選択肢と値を処理する方法。

先週からのこの方向に関するいくつかのマイナーアップデートを共有するだけです。

まず、トグルオプションのいくつかの代替ラベルについて考えました。

私は右側のどちらかに傾いています：私が最初にそこに入れたものよりも明確であり、技術者でない友人との簡単なその場でのテストから、彼女はそれらが何であるかを理解しているようでした他のものよりも明確に意味しました。 実際のButtonGroupラベルについては、「カスタム」を「手動」に交換するのは少し意味があると思いますか？ 私は強い好みはありませんが。

また、ブロックがデフォルトの動作に少し追加されたコンテキストを提供できるように、オプションのセカンダリテキスト行を含めると便利だと思います。 columnsブロックの場合、これは次のようになります。

また、より複雑なセットアップに関する調査を再評価

この問題について他の人とチャットしているときに浮かんだもう1つのことは、別のデバイスの設定を行うことと、その変更をプレビューすることの間のリンクです。 おそらく、この領域にデバイス固有のプレビューへのリンクを含めることができる場所があります（＃13203の静脈内）。

プロセスに関する注意：チーム間のコラボレーションを改善し、より良い製品を構築することを本当に目指している場合、新しいUIコントロールの導入を議論する問題には「アクセシビリティ」ラベルを付ける必要があります。 適切なラベル付けと参加の奨励をいただければ幸いです🙂

Re：「自動」および「カスタム」オプションを備えた最新のプロトタイプ：これらのコントロールの基礎となるネイティブHTML要素は何ですか？

• ボタン：支援技術によって文脈から読み取られた「自動」および「カスタム」というテキストはあまり意味がありません
• ラジオボタン：上記の「デバイス固有のレイアウト」テキストは、ラジオボタンにコンテキストを与えるフィールドセットの凡例に使用できます。

この時点で：単一選択オプションに使用される適切な要素であるネイティブラジオボタンを使用しないという議論は何ですか？

@kjellr @afercia
「カスタムデバイス固有のレイアウトを使用する」というラベルの付いたトグルなど、デフォルトで無効になっているものを使用しない理由はありません。 グーテンベルクの既存のトグルコントロールと同様に、現在の状態を説明する追加のテキストをトグルの下に表示できます。 ただし、ラジオボタンを使用する場合は、「手動」よりも「カスタム」の方がうまく機能することに同意します。

「カスタムデバイス固有のレイアウトを使用する」というラベルの付いたトグルなど、デフォルトで無効になっているものを使用しない理由はありません。 グーテンベルクの既存のトグルコントロールと同様に、現在の状態を説明する追加のテキストをトグルの下に表示できます。

これを+1します。

セグメント化されたコントロールに関する私の主な不満は、2つのオプションのように見えることです。これにより、1回の切り替えと比較して、知覚される複雑さが100％増加します。 作成者は、_one_ではなく_two_設定を理解する必要があります。

トグルにはより詳細なラベルを付けることができるため、さらに理解しやすくなります。 説明が非常に明確な1つの設定と、説明があいまいな2つの設定の場合のようです。 そこには明確な勝者がいます。

ただし、トグルはデフォルトで_on_であると考え、ラベルを「他の画面サイズのレイアウトを自動的に構成する」のようなものに設定します。 私の理由は、これがデフォルトで_有効_である「スマートデフォルト」として提示しているものだからです。 私には、オプトアウトしたような気がします。 補助輪を外したり、ABSを無効にしたりするようなものです。

私はあなたのプロセスに本当に感銘を受けました。ここ、Kjell —あなたはこれについて前向きでオープンマインドであり、モデルの生産的な貢献者❤️であり、既存のパターンとUIコントロールを活用しています。

これのトグルバージョンを作成しているのを見たことを思い出します（どこを思い出せませんか、プライベートDM？）。また、 ButtonGroupを使用して実際に使いやすさとアクセシビリティを向上させることを検討しました。 おそらく、そのモックアップもここに投稿する価値がありますか？

個人的には、激動のレビューの海にどのバージョンを設定するかについての好みはありませんが、最近のトグルの言及を考えると、オプションとしてそれを示す価値があるようです。

ボタングループは、特にグループ内の各アイテムが明確に関連しているため、画像のサイズに適しています。

いつものようにフィードバックをありがとう。 👏

@afercia

適切なラベル付けと参加の奨励をいただければ幸いです。

もちろん！ このスレッドは非常に活発で、私はここ数週間、ラベルを見るために上にスクロールしていません。 アクセシビリティラベルを追加していただきありがとうございます。ディスカッションへようこそ。

この時点で：単一選択オプションに使用される適切な要素であるネイティブラジオボタンを使用しないという議論は何ですか？

私は以前にそれを試しましたが、調査を共有しませんでした：

これが私が個人的にそれを渡した理由です：

1. ラジオのコントロールは多くのスペースを占めます、そして私はそれらがそれほど明確であるとは思いません。 ここでの目標は、これを単純に見せることです。ほとんどの人は、この設定を理解して、処理できるようにする必要があります。
2. RadioControlのガイドラインでは、「単一の設定のオンとオフを切り替えるには、ToggleControlコンポーネントを使用する」ことを推奨しています。 これは単一の設定であるため、ある種の切り替えがより適切であるように思われました。
3. ここで使用するパターンについては、マテリアルを探していました。 追加のコントロールの表示/非表示をトリガーするラジオボタンの例を見つけることができませんでした。 しかし、私は

@jasmussen

これのトグルバージョンを作成しているのを見たことを思い出します（どこを思い出せませんか、プライベートDM？）。また、 ButtonGroupを使用して実際に使いやすさとアクセシビリティを向上させることを検討しました。 おそらく、そのモックアップもここに投稿する価値がありますか？

うん、これを話している間、私はDMであなたとそれを共有しました。 ここにあります：

また、このアプローチのデスクトッププロトタイプを

私はこれらの2つの解決策の間で引き裂かれました。 独自のガイドラインに従って、 ButtonGroupを使用して「関連するボタンをグループ化」し、標準のFormToggleを使用して「単一の設定をオンまたはオフに切り替えます」。

これらの簡単な説明だけに基づいて、FormToggleの方が理にかなっていると思いました。 しかし、それは2つのアプローチの間で多かれ少なかれトスアップでした。

ButtonGroupが目指していた主なことは、両方の状態（Auto、Manual）にさらに明確にラベルを付けることができたという事実でした。 これの言い回しは本当に紛らわしいので、それはプラスのように思えました。 そうでなければ完全に確信することができ、両方ともテストする価値があります。

ああまた、ここから自分自身に応答

この問題について他の人とチャットしているときに浮かんだもう1つのことは、別のデバイスの設定を行うことと、その変更をプレビューすることの間のリンクです。 おそらく、この領域にデバイス固有のプレビューへのリンクを含めることができる場所があります（＃13203の静脈内）。

モーダル内のプレビューについて考えながら、これがどのように見えるかを簡単に調べました。

これはちょっと楽しいようですが、この問題の範囲外である可能性もあります。

また、プレビューアイコンの「ホバーのみ」の扱いにもあまり興味がありません。 モバイルでこれを試すとき、私はそれを少し微調整しました：

そのレスポンシブプレビューを本当に掘り下げてください。 私は暇なときに同じ線に沿って落書きをしてきましたが、プレビューボタンを次のボタンに置​​き換えるだけです。

👆しかし、それはオーブンでもっと時間が必要です、それを提案でさえ考えないでください。 ミックスを投入し、何かに成長するためのアイデアの種です。

@kjellrのすっきりとしたモックアップの1つを調整して、デバイスアイコンにラベルを追加し、スライダーのグループに「列数」ラベルを追加して、アクセシビリティを向上させました。 （最後の1つは必要ですか、@ afercia？）

よくわからないことの1つは、ブレークポイントの幅がどのように定義されているかです。 それらはテーマまたはブロックによって提供されますか？ ブロックは、3つではなく2つのブレークポイントを持つことを選択できますか？ 4はどうですか？ カスタムブレークポイント幅はどうですか？ いずれにせよ、私は編集者がそれらを提供するべきではないと思います。

この種のことは、@ mehがこのコメントで話していたことと結びついています。 私はそのコメントの最後に彼が提案したものと同様の何かに傾倒し始めています。 列のレスポンシブコントロールは、2つのスライダーだけで実装できると思います。

最小列幅
――――― o ―――― [300] px
1行あたりの最大列数
――― o ―――――――― [__3]

これは、平均的なデバイス画面幅に基づいてハードブレークポイントに頼る必要がなく、私にははるかに単純ではるかに「応答性」があるように見えます。

ここでの目標は、これをシンプルに見せることです

@kjellr確かに、説明してくれてありがとう。 ただし、コントロールは単純に見えるだけではありません。 また、支援技術をサポートするには、意味的に正しい必要があります。 たとえば、スクリーンリーダーが意味のある方法でアナウンスする必要があります。 スクリーンリーダーのユーザーがフォーカス可能なコントロールをタブで移動することを想像してみてください。ある時点で、スクリーンリーダーは次のことをアナウンスします。
「自動」
"マニュアル"
コンテキストなし：「自動」と「手動」は何を指しますか？

代わりに、凡例のあるフィールドセットにグループ化されたラジオボタンは、凡例がアナウンスされるため、

原則として、ネイティブフォームコントロールは、セマンティクスとアクセシビリティに必要なものをすでに提供しています。 代わりに、カスタムコントロールは、予想されるセマンティクスと相互作用を破壊することがよくあります。

設計者と開発者にとって、カスタムコントロールを実装するときは、同等のネイティブコントロールのすべての機能を再構築するために細心の注意を払う必要があることを理解することが非常に重要です。

この場合、これは2つのオプションからの単一の選択肢です。 ボタンは適切ではありません。 凡例のあるフィールドセットにグループ化されたラジオボタンが理想的です。 このコントロールの_意味_を2つのオプション間の単一の選択から、単一のチェックボックスに相当する「オン/オフ」スイッチに変更する場合、トグルは許容できるトレードオフになる可能性があります（トグルに関するすべての警告について詳しく説明します）前号）。

Re：マテリアルデザイン：可能な限りアクセスしやすくすることを目的としたWordPressのようなプロジェクトのインスピレーションの源である必要があるかどうかはわかりません🙂マテリアルパターンの多くは主にモバイルユーザーインターフェイスに触発されており、長い道のりがありますそれらのパターンに完全にアクセスできるようにするためです。

列に加えて、画像ブロックの「モバイルスタック」オプションの必要性に直面しています。 私がWordpressTwenty Nineteenに移行しているレガシーWebサイトには、幅が300px程度の（そしてそのままにしておく必要がある）左右に浮かぶテキストで折り返された画像がたくさんあります。 段落ブロックにドロップすると、これらの画像ブロックはデスクトップでは正常に機能しますが、ほとんどのモバイル画面では、横にあるテキストが読みにくくなります。 画像ごとに、ImageブロックのAdvancedパネルを使用して、ブレークポイントの画像を100％の幅に拡張するCSSクラス.isom（「is-stacked-on-mobile」と入力するよりも速い！）を追加する必要があります。 29の使用。 これは、移行者だけでなく、多くのユーザーに共通の問題である可能性があると思います（それが一言で言えば）。

私はまだグーテンベルクに精通していないので、解決策を提案するための単なる提案です。

皆様、継続的なフィードバックをありがとうございます！

よくわからないことの1つは、ブレークポイントの幅がどのように定義されているかです。 それらはテーマまたはブロックによって提供されますか？ ブロックは、3つではなく2つのブレークポイントを持つことを選択できますか？ 4はどうですか？ カスタムブレークポイント幅はどうですか？ いずれにせよ、私は編集者がそれらを提供するべきではないと思います。

一般に、ブレークポイントはブロック作成者によって指定されます。 私は最近これについて@jasmussenとチャットし、Gutenbergが最初にいくつかのデフォルトを提供することは理にかなっていることに同意しました（おそらくこれらはGutenbergが使用するデフォルトのブレークポイントにマップされて

この場合、人々は多かれ少なかれ標準のトグルコントロールを使用して集まっているようです。

上記の@ZebulanStanphillのコンプを$dark-gray-300 、AAを通過します。

更新されたモックアップとプロトタイプは次のとおりです。

🖥デスクトッププロトタイプ

📱モバイルプロトタイプ

私も先に進んで、いくつかの代替ケースをモックアップしました：

• ギャラリーブロック
• より複雑な例（ここの一番下のセクションのラベルの一部を統合できると思います）。

物事を進めるために、私が考えていることは次のとおりです。

1. スレッド内の全員からフィードバックを
2. いくつかの代替ラベルを収集します。 トグルフィールドのラベルはまだ少し紛らわしいです。 さらにいくつかのオプションを生成してから、次のことを行う必要があります。
3. ラベルの簡単なユーザーテストを行って、この機能に対する期待を適切に設定しているものを確認します。

この方向性と次のステップについての考えを教えてください！

@kjellr

パネルタイトルと個々のフィールドラベルを区別するためにすでにテキストの太さを使用しているため、個々のデバイスラベルの色を調整しました。 それらの灰色は$dark-gray-300 、AAを通過します。

個人的には、念のため、濃い灰色を好みます。 ラベルは淡い色なので少し奇妙に見えます。

より複雑な例（ここの一番下のセクションのラベルの一部を統合できると思います）。

ええ、各トグルの上にラベルがある理由はありません。 アイコンは、トグルラベルの前のトグルの横に配置できます。

また、これは単なる落とし穴ですが、これらのスライダーは、ブレークポイントラベルからインデントされているように見えるのではなく、左端まで伸びるべきではありませんか？

個人的には、念のため、濃い灰色を好みます。 ラベルは淡い色なので少し奇妙に見えます。

少し暗くしても大丈夫です。 ただし、 $dark-gray-500よりも暗くなることはありません（下の図を参照）。そうしないと、灰色が残りのテキストと非常によく似たものになります。

また、これは単なる落とし穴ですが、これらのスライダーは、ブレークポイントラベルからインデントされているように見えるのではなく、左端まで伸びるべきではありませんか？

フィールドにもう少し階層を追加するために、それらをインデントしました。 各フィールドが全角の場合、これらが「列数」ラベルに従属していることはあまり明確ではありません。

@kjellr

フィールドにもう少し階層を追加するために、それらをインデントしました。 各フィールドが全角の場合、これらが「列数」ラベルに従属していることはあまり明確ではありません。

その場合、ブレークポイントラベルもインデントするのは意味がありませんか？

その場合、ブレークポイントラベルもインデントするのは意味がありませんか？

ある種ですが、通常はインデントしません。 ここでそうすることは、私には意図的ではない/壊れているように見えます：

比較のために、これも全幅フィールドのコンプです。

上で述べたように、これにより視覚的な階層の一部が削除され、一見するとスキャンしにくくなります。 フィールドだけをインデントすることは、良い妥協点のように思えました。

フィールドだけをインデントするレイアウトが本当に好きです。 これはa11yの問題に対処しているようで、そこでフィードバックを得ることに同意します。

私の唯一の本当の懸念は、共有された「複雑な例」にあります。 これは、デザインがうまく機能しないと私が感じるところです。 レスポンシブコントロールが必要なものが2つあると（つまり、列と製品の数）、それらすべてのアイコンとラベルは私が解析するのに非常に多くなります。 良い面としては、それは十分に構造化されているので、私はまだそれを解析することができます。 😉

私の唯一の本当の懸念は、共有された「複雑な例」にあります。 これは、デザインがうまく機能しないと私が感じるところです。 レスポンシブコントロールが必要なものが2つあると（つまり、列と製品の数）、それらすべてのアイコンとラベルは私が解析するのに非常に多くなります。

私はそこで完全に同意します。 ラベルがなかった以前の有効期限では、これらはまだほとんど消化可能であると感じました。

...しかし、新しいバージョンは、複雑になるとスキャンするのがかなり難しくなります。 これを改善するための1つの可能な方法は、次のアイデアを採用することです。

• 同じデバイスセクションに複数のコントロールを統合することをお勧めします（以下のレイアウトセクションを参照）。
• コントロールのラベルに代わりにデバイス名を記載できる場合は、デバイスラベルを削除します（以下の[表示]セクションを参照）。

私が最初に感じたもの。 2番目についてはよくわかりません。これは、その周りのベストプラクティスを特定するのが難しいと思うからです。

最初にセマンティクスの観点から考えてから、必要なセマンティクスを中心に設計することをお勧めします。

各入力には、意味のある_独自の_方法でラベルを付ける必要があります。 これらのテキストラベルは、スライダーと数値フィールドに関連付けられた<label>要素になります。 支援技術のユーザーとして、すべて同じテキストでラベル付けされた複数のフィールドをどのように区別する必要がありますか？

例えば：

• スクリーンリーダーのユーザーとして、さまざまな数値フィールドにタブで移動すると、複数のフィールドの「列数」が表示されますが、それらが何を指しているのかわかりません（デスクトップ、モバイル？）
• 音声入力ユーザーとして、「列の数をクリック」コマンドを発声すると、同じ名前のフィールドを区別できないため、使用している音声認識ソフトウェアが混乱します。

ユーザーが使用できる回避策はありますが、フィールドの周囲を探索したり、別の方法を使用してコンテンツをナビゲートしたりすることを強制することは理想的とは言えません。

これらのラベルはすべて、より良いコンテキストを提供する必要があり、フィールドごとに一意である必要があります。

このインターフェースは複雑なので、根本的に単純化する方法を模索することをお勧めします。 例えば：

• スライダーの「かわいさ」以外に、どのような付加価値があるのか​​わかりません。マウスでも使いづらく、スペースも多く、すでに入力フィールドがあります。
• デバイスアイコンが本当に必要かどうかわからない：それらを削除すると、スペースを節約できる可能性があります

「自動」ボタンと「手動」ボタンが最後のプロトタイプでなくなり、トグルに置き換えられたことをうれしく思います（トグルには独自の問題がありますが）。 ありがとうございました。

では、可視性の設定は、特定のデバイスのブロック全体を非表示にすることですか？ これはすべてのブロックのオプションとして追加されますか？ ボタン、段落、セパレーターなど？

私は個人的にはこのプラクティスのファンではありませんが、それを回避できないユースケースはまだあると思います。
しかし、十分なユースケースはありますか？ それとも、他のページビルダーがそれを行うと想定しているので、それが必要である必要がありますか？

では、可視性の設定は、特定のデバイスのブロック全体を非表示にすることですか？ これはすべてのブロックのオプションとして追加されますか？ ボタン、段落、セパレーターなど？

ああ、混乱して申し訳ありません。これは、さまざまな状況でこのパターンをストレステストする例にすぎません（上記のサードパーティ製品ブロックのコンテキストで発生しました）。 これをコアブロックに追加することはありません。

入力ありがとう、@ afercia！ ここにフィードバックをお寄せいただきありがとうございます。

支援技術のユーザーとして、すべて同じテキストでラベル付けされた複数のフィールドをどのように区別する必要がありますか？

これらの各セクション（デスクトップ、タブレット、モバイルなど）の親ヘッダーがそれらを区別するための鍵になると思いましたが、誰かがコントロールをタブで移動するという観点から、それを予想していました。 たとえば、誰かが代わりにナレーションを使用していて、子コントロールの1つを直接タップした場合、それがどのように混乱するかがわかります。

各ラベルを明確に区別することで、最善のサービスが提供されるようです。 これが正しい解決策かどうかはわかりませんが、説明のために、ラベルの観点から提案しているのはこのようなものですか？

• スライダーの「かわいさ」以外に、どのような付加価値があるのか​​わかりません。マウスでも使いづらく、スペースも多く、すでに入力フィールドがあります。

この場合、ブロックのデフォルト状態で使用されているスライダーコントロールを再利用しているだけです。 スライダーを削除する場合は、「自動」レスポンシブ設定とデバイスごとの手動設定の両方で削除したいと思います。 しかし、それは一般的なスライダーの有用性についてのより大きな議論の始まりのようであり、このチケットがそれに対処するための適切な場所であるかどうかはわかりません。

いずれにせよ、これはレスポンシブブロック設定の再利用可能なパターンの定義を開始することを目的としているため、この場合はスライダーを削除すると役立つ場合がありますが、スライダーが引き続き使用される状況は他にもあります。

• デバイスアイコンが本当に必要かどうかわからない：それらを削除すると、スペースを節約できる可能性があります

アイコンは視覚的な参照ポイントとして役立つと思うので、そのままにしておきたいと思います。 特に私の最新のコンプのインデントされたフィールドでは、アイコンはテキストとコントロールの海の中で迅速な視覚的マーカーとして際立っています。 ラベルにテキストを追加することになれば、このメリットはさらに強化されます。

@afercia

最初にセマンティクスの観点から考えてから、必要なセマンティクスを中心に設計することをお勧めします。

HTMLがfieldset 、 legendなどを使用して適切に記述されている場合、

各ラベルを明確に区別することで、最善のサービスが提供されるようです。

@kjellr yes :)あなたの例のように各ラベルにコンテキストを与えることを検討したいと思います。 それはより単純でより理解しやすいです。 少し短い言葉遣いが役立つかもしれません。 たとえば、「数」は本当に必要ですか？ 視覚的にも処理することがたくさんあり、物事を単純化することは少し役立つかもしれません。

@mapkうん、私はそれを考慮しました。 fieldsetとlegendは、一連のコントロールをグループ化し、グループに名前を付ける正しい方法です。 ただし、これは実際のサポートの問題であり、テストする必要があります。 ラジオボタンまたはチェックボックスのグループで非常にうまく機能します。 rangeとnumber入力でうまく機能するかどうかはわかりません。

RangeControlコンポーネントには、もう1つの問題があります。範囲と数値の両方の入力に同じラベル値が使用されます。 したがって、範囲と入力された数値は同じアクセス可能な名前を持ちます。 理想的ではありません。 本日、アクセシビリティチームミーティングで話し合うことを提案します（どなたでもご参加いただけます）。

範囲と数値の両方の入力に同じラベル値が使用されます

私はそれを変更するために望んでいるhttps://github.com/WordPress/gutenberg/pull/13863 @afercia

ありがとう@meh！ 私はすぐにそこにコメントしました。

@kjellr yes :)あなたの例のように各ラベルにコンテキストを与えることを検討したいと思います。 それはより単純でより理解しやすいです。 少し短い言葉遣いが役立つかもしれません。 たとえば、「数」は本当に必要ですか？ 視覚的にも処理することがたくさんあり、物事を単純化することは少し役立つかもしれません。

ありがとう、@ afercia。 これがそのモックアップです：

フィールドラベルの「Columnson」の部分は、「NumberofColumns」ラベルの後に少し繰り返されているように見えます。 しかし、私はそれが実行可能だと思います。

うん、私はそれを考慮しました。 fieldsetとlegendは、一連のコントロールをグループ化し、グループに名前を付ける正しい方法です。 ただし、これは実際のサポートの問題であり、テストする必要があります。 ラジオボタンまたはチェックボックスのグループで非常にうまく機能します。 rangeとnumber入力でうまく機能するかどうかはわかりません。

rangeおよびnumber入力で機能するかどうかをどのように確認できますか？ このラベル付けの問題がすでにこの方法でカバーされている場合は、個々のフィールドラベルをより簡潔に保つことをお勧めします。

「列」、「アイテム」などの部分は、最新のモックアップにあるように、各フィールドラベルのデバイスタイプに役立つと思います。
先ほどお話ししたナレーションのシナリオに加えて、たとえば、ランドスケープモバイルを使用していて、親の見出しが表示されていない場合に便利だと思います。

また、デバイスタイプ名はすべて単数形またはすべて複数形になります。 私は彼らがモックアップであることを知っています。 ただ言う：スマイリー：

また、デバイスタイプ名はすべて単数形またはすべて複数形になります。 私は彼らがモックアップであることを知っています。 ただ言ってください😃

上記で更新。

この非常に興味深いアイデアのバックエンドはどうですか？ 誰かがそれを扱うためのアプローチを思いついたことがありますか？ 必要なすべての値を格納するオブジェクトや複数の個別のプロパティのようなものはありますか？

その最後のモックアップ@kjellrに関して、「列」のアコーディオンタイトルは、「列の数」という見出しと「デスクトップ上の列」または「タブレット上の列」などの継続的な読みで冗長に見えます。「列」という単語たくさん登場します。

見出し"列数が"だった場合しまうのa11yのニーズはまだ満たされてlegendでfieldset ？ 次に、そのフィールドセットのグループ化されたアイテムがすべて「列の数」に関連していることを示しているはずです。 したがって、入力ラベルは「デスクトップ」、「タブレット」、「モバイル」のようになります。

フィールドセットと凡例：前にコメントしたように、テストする必要があります。

@mapkうん、私はそれを考慮しました。 フィールドセットと凡例は、一連のコントロールをグループ化し、グループに名前を付ける正しい方法です。 ただし、これは実際のサポートの問題であり、テストする必要があります。 ラジオボタンまたはチェックボックスのグループで非常にうまく機能します。 範囲と数値の入力でうまく機能するかどうかはわかりません。

上記の私のコメントに基づいて、多分以下のようなものですか？ マークアップも含めました。 @kjellr 、どう思いますか？

@mapkスライダーは、列数などの大まかなコントロールのコンテキストではあまり役に立たないため、おそらく削除する必要があります。

@ZebulanStanphillと同じことを考えてい

範囲入力は、ボリュームコントロールや、スライダーを見るだけで結果がわかる画像オーバーレイの不透明度などに適しています。 _25％、50％、100％_

MDNドキュメントから

この種のウィジェットは不正確であるため、コントロールの正確な値が重要でない限り、通常は使用しないでください。

目盛りはそれをより便利にするかもしれないと思いますが、それでも、なぜ列を調整するための2つの方法を提供するのですか？

数値入力のみを使用する場合は、コンテキストで入力とラベルを使用するためにスペースを解放します。

[4] columns on desktops
[2] columns on tablets
[1] column on mobile devices

こんにちは、みんな！ レスポンシブな可視性に関しては、 EditorsKitプラグイン（以前はBlock Options）にこの機能が

https://www.youtube.com/watch?v=1VuBXAUqTjA

あなたがそれを好きになることを願っています！ 乾杯！

@phpbitsに感謝します！ そこでの調査に感謝しますが、この場合、「オン/オフ」状態を識別するのは非常に難しいと思います。 その場合のトグルコントロールやチェックボックスのようなものがうまくいくかもしれませんか？

スライダーは、列数などの大まかなコントロールのコンテキストではあまり役に立たないため、おそらく削除する必要があります。

@ZebulanStanphillに感謝します。 @aferciaもこれについて上記で言及しました。 私はこれを探求する別の設計反復を受け入れています。 @kjellr何か考えはありますか？

また、これをデザインを超えて、PRを始めましょう。 プラグインで実際のユーザーとよりよくテストできると思います。

@phpbitsに感謝します！ そこでの調査に感謝しますが、この場合、「オン/オフ」状態を識別するのは非常に難しいと思います。 その場合のトグルコントロールやチェックボックスのようなものがうまくいくかもしれませんか？

@mapk私もそう思いましたが、多くのスペースが必要で、ブロックの下にこれらのチェックボックスがあり、オプションが多すぎるのはあまり気分が良くありません。 以前のバージョンにはそのチェックボックスがありました。 しかし、設計チームとアクセシビリティチェックを行うことで、私よりもうまくやれると思います。 私はできることなら何でも貢献します:)ありがとう！

範囲入力は、最小/最大値の明確な（より）視覚的な表示を提供するので、素晴らしいと思います。

スライダーは、列数などの大まかなコントロールのコンテキストではあまり役に立たないため、おそらく削除する必要があります。

@ZebulanStanphillに感謝します。 @aferciaもこれについて上記で言及しました。 私はこれを探求する別の設計反復を受け入れています。 @kjellr何か考えはありますか？

これは間違いなく変更される可能性がありますが、レスポンシブコントロールが実現するかどうかに関係なく、これらのスライダーが存在するため、このチケットでもこれを行う必要があるかどうかはわかりません。 スライダーの探索/監査に焦点を当てた別のチケットがあります。 それまでの間、このスレッドをスライダーの有無にかかわらず機能するレスポンシブコントロールソリューションの取得に集中して、列ブロックだけでなく拡張できるようにすることは理にかなっていると思います。

私はここでほとんどすべてのコメントを読みましたが、フロントエンドにコンテンツをロードせず、 display:noneを使用するだけでなく、デバイスの可視性を関数として使用することを考えた人は誰でもいます。フロントモバイルで多くの画像を非表示にしますが、画像がまだロードされているかどうかは関係ありません...だから私はそれを防ぐためにACFのものを作成します...

列を調整するという文脈では、スライダーを使用すると個人的に素晴らしいと思います。スライダーをクリック/ドラッグするだけで、その設定のすべての値のすべての結果をすばやく確認できるからです。 これは、同様のコントロールを使用した以前の経験に基づいています。明らかに、これはまだ構築されていません。 設定が単なる入力フィールドである場合、可能な各値を編集して評価するのは面倒です。 値ごとに、入力、バックスペース、数値の入力をクリックし、エディターで結果を確認して、繰り返す必要があります。

もう1つの利点は、スライダーを適切に設計すると（大きな親指、目盛りなど）、相対的な最小値/最大値を視覚的に伝達できることです。

私はマウスユーザーであり、他のユーザーにとってはスライダーも理想的ではない可能性があることを理解しています。 できるだけ多くのユーザーに役立つバランスを見つけられることを願っています。

私は今合併しました：

• ResponsiveBlockControlコンポーネント
• DimensionControlコンポーネント

これらは、 paddingなどの特定のブロック属性に対してビューポート固有のコントロールをます。

＃19909で、レスポンシブ編集の代替アプローチを発券しました。これは、既存のすべてのブロックで、追加のコードなしでレスポンシブ変更を行えるようにすることに焦点を当てています。

モバイルで列幅を調整できるハンドイングローブは、モバイルでは列の順序になります。

たとえば、全画面で列1-2-3-4-5を設定します。 これがレスポンシブに変換されるとき、私はそれらを5、4、3、2、1に表示したいと思うかもしれません。
または5-3、1（* 2、4は表示されません）。

個々の列は_レスポンシブ_で制御します：

1. 表示/非表示を切り替えます
2. コントロール幅
3. 再注文用のドロップダウンボックス

価値があるのは-これは、最初に単一のブロックに対して、次にカスタム列ブロックに対して、カスタムスタイルコントロールの最新の反復です。

大好きです！！！！！！！！！！！！！！

いつ？ いつ？！

それを共有してくれてありがとう！ 私は興奮しています!!!!!

これは、私が独自のカスタムブロックレスポンシブコントロール用に開発したものです。

@mattboltは、レイアウトの反復が現在実際に開発されているということですか？ 後者の場合は、メディアクエリの障害をどのように分類したかを知りたいと思います。

これは、これらのツールの2番目の視覚的な反復です。 Wordpress 5が2018年末にリリースされた直後に社内で開発したオリジナルは、2019年1月からいくつかのサイトで本番環境で使用されていますが、主にwww.minderoo.orgです。

メディアクエリに関しては、すべてのブロックがサーバー側のレンダリングコンポーネントによってサポートされています。 $content = apply_filters('the_content', $post->post_content);を呼び出す前に、現在登録されているスタイルをすべてフラッシュします。 次に、レンダリングプロセス中に、各ブロックは一意に適用されたスタイルを登録し、ブロックのcssクラスに含まれる一意のIDを受け取ります。

the_content呼び出した後、一意のスタイルを変数に「レンダリング」します。 これは、「メディアクエリ」cssを生成し、それをに挿入する関数呼び出しです。

それは非常に徹底的な説明でした、 @ mattbolt私にそれを説明するために時間を割いてくれてありがとう:)私の能力を少し超えているように内部に何があるかを見るのは興味深いでしょう。

もう一度ありがとう、マット:)

これはボタンブロックです。 その周りのすべての空白を見てください-特に上下に。

ブロック要素のauto / 0マージンは、配置に変換されます。
例：「margin-left：auto; margin-right：0; `はブロック要素を右側にプッシュします。
ブロックアライメントオプション（左/右）をマージン固有のアライメントとどのように調整できますか？

一歩後退して、私の2c：
デスクトップ/タブレット/モバイルの区別全体が少し恣意的であり、将来性がないことがわかります...歴史が私たちに何かを教えてくれたとしたら、デバイスは急速に変化し、今日私たちが標準と見なしていることはせいぜい一瞬です。

スマートウォッチ、スマートTV、メガネ、その他のデバイスがWebにアクセスできるのはなぜですか？ デスクトップを構成するものは何ですか？ 12インチのラップトップと13インチのタブレットの違いは何ですか？ 画面の解像度について話している場合、7インチの電話は50インチのテレビよりも解像度が高くなる可能性があるためです。
そして、なぜ1つ（小/大）ではなく2つのブレークポイント（モバイル/タブレット、タブレット/デスクトップ）なのですか？

ピクセルパーフェクトになるように努力するものを構築する代わりに、視点を少しシフトして、ピクセルにとらわれないものを構築しようとすべきでしょうか？

任意のブレークポイントを設定する代わりに、たとえば列内のコンテンツが読み取り不能になったときを検出して、意味のあるものに折りたたむ必要がありますか？

＃19909に示されているモックアップは非常に古くなっていますが、そのチケットの主な目的は、レスポンシブブレークポイント編集のための_グローバルで拡張可能な_インターフェイスを探索することです。 これを正しく行うと、デスクトップブレークポイントのように見えるエディターで列ブロックのモバイルプロパティを編集する状況を回避できます。 逆に、エディターの表示モードとレスポンシブプロパティを接続することで、逆の操作を実行できます。モバイルデバイス上でもデスクトップブレークポイントを編集できると同時に、各レスポンシブブレークポイントの視覚的表現が向上します。