テーマ、テーマコンポーネント(プラグインも?)のCSS識別子をリクエスト

私のテーマコンポーネントは設定にオブジェクトを使用しており、かなりの数のフィールドを提供しています。

現在、オブジェクト設定に適用されているグリッドスタイルでは、垂直タブ列とスキーマフィールドの列が非常に狭くなっています。

オブジェクト設定の代替表示を提供したいのですが、私のテーマコンポーネントの設定のみを変更する方法を導入する方法が見つかりませんでした。すべてのテーマにCSSオーバーライドをグローバルに適用したくありません。

Discourse は、各テーマとテーマコンポーネントに対して DOM に CSS 識別子を追加することは可能でしょうか?そうすれば、特定のテーマ設定ページを対象とする異なる CSS ルールを追加できます。

以下は、私のサイトで使用している、グローバルに適用される簡単な CSS オーバーライドです。

.schema-setting-editor .schema-setting-editor__wrapper {
    grid-template-columns: minmax(15em, 0.3fr) 1fr;
    gap: 0 3rem;
}
.schema-setting-editor .schema-field {
    grid-template-columns: 1fr;
    gap: 0;
    background-color: var(--tertiary-100);
    padding: 1rem 5px;
}

デフォルトスタイルと上書きされたスタイル:

「いいね!」 5

「修正」は次のリンクと同じくらい簡単です。

しかし、いくつか疑問があります。

  1. テーマ作成者が設定ページの見た目をカスタマイズしやすくした場合、ページがすべて異なると、それらを使用する人々にとって難しくなりませんか?

  2. それをコアで修正して、テーマ設定ページが利用可能なスペースをより有効に活用するようにすべきでしょうか? :thinking: @product-managers さんにもCCします

「いいね!」 3

これはもっともな懸念のように思えます。ユーザーとして、Discourse の遍在性と一貫性のおかげで、新しいフォーラムに簡単に参加できるのは素晴らしいことです。管理者として、他のサイトで手伝う機会があった場合も、その一貫性があればありがたいと思います。

(親戚や友人の技術サポートで呼ばれたことを考えています。iPhone の手伝いは喜んでしますが、どの携帯電話もすべて違うので Android は気が重いです。)

ええ、これは推奨したいことではないと思います。@martin は、以前策定した管理セクション全体のUIガイドラインを確立することに関連して、この質問についてかなりの背景知識を持っています。

一般的に、管理セクションはカスタマイズされたくないものと考えているはずです、私の記憶が正しければ。

ええ、このトピックを#uxとして扱う方が理にかなっていると思います。

@jordan.vidrine さん、これは、以前の formkit への変換の取り組みや、formkit 自体へのフィードバックと重複する部分があると思います。

「いいね!」 1

はい、私はこれに強く反対します。Discourse の管理 UI はカスタマイズされるべきではなく、UI の一貫性(まあ、まだ対応が必要なページがいくつかありますが)は、管理エクスペリエンスの重要な部分です。

もう一度試してみました

これが私ができる最も簡単なものです。「インナーサイドバー」が「おかしい」と感じますが、現時点で優先できる作業量よりも多くの作業になるかもしれませんね :thinking:

内側のサイドバーが表示されているときに、要素の順序を変更するためのボタンを常時表示することは可能でしょうか?設定項目が長いリストの下にある場合、順序を変更するには多くのスクロールが必要になり、ボタンを見ている間には何が起こっているかが見えません。

「いいね!」 2

@moin これを指摘してくれてありがとう。私もよくこの問題に遭遇します。+1

ボタンをサイドバー(.schema-setting-editor__tree)の下に移動させれば、ユーザーエクスペリエンスが向上することに同意します。

ただし、上下移動ボタンと削除ボタンは分けたいです。上下移動ボタンはサイドバーの下に移動させ、削除ボタンは現状のままで、設定フィールドの下に残すのが良いと思います。