CSS-Bezeichner für Themes anfragen, Theme-Komponenten (Plugins auch?)

Merkmal
1

Mein Theme-Komponente verwendet Objekte für die Einstellungen und bietet eine ganze Reihe von Feldern.

Die aktuell auf die Objekt-Einstellungen angewendeten Rasterstile verwenden sehr schmale Spalten für die Spalte der vertikalen Tabs und die Schemafelder.

Ich wollte eine alternative Anzeige für die Objekt-Einstellungen anbieten, konnte aber keinen Weg finden, eine Möglichkeit einzuführen, Einstellungen nur für meine Theme-Komponente zu ändern; ich möchte meine CSS-Überschreibungen nicht global für alle Themes anwenden.

Könnte Discourse möglicherweise einen CSS-Bezeichner (Identifier) im DOM für jedes Theme und jede Theme-Komponente hinzufügen, damit unterschiedliche CSS-Regeln hinzugefügt werden können, die auf die spezifischen Theme-Einstellungsseiten abzielen?

Hier ist die einfache CSS-Überschreibung, die ich auf meiner Seite verwende und die global angewendet wird:

.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;
}

Die Standard- und die überschriebenen Stile:

default_styles
default_styles1730×1927 242 KB

overwritten_styles
overwritten_styles1730×2151 302 KB

5 „Gefällt mir“
2

Die „Lösung“ ist so einfach wie

aber ich frage mich ein paar Dinge:

  1. Wenn wir es Theme-Autoren „einfach“ machen, das Aussehen ihrer Einstellungsseite anzupassen, machen wir es dann für Benutzer schwieriger, diese Seiten zu verwenden, wenn sie alle unterschiedlich sind?

  2. Sollten wir das stattdessen im Core beheben, damit die Theme-Einstellungsseite den verfügbaren Platz besser nutzt? :thinking: cc @product-managers

2 „Gefällt mir“
3

Das scheint eine berechtigte Sorge zu sein. Als Benutzer finde ich es großartig, dass die Allgegenwart und Konsistenz von Discourse es so einfach macht, in ein neues Forum einzusteigen und sich daran zu beteiligen. Als Administrator würde ich die Konsistenz auch begrüßen, wenn ich die Gelegenheit hätte, bei anderen Seiten zu helfen.

(Ich denke an all die Technik-Unterstützung für Freunde und Familie, zu der ich gerufen wurde. Ich helfe gerne bei iPhones, aber ich fürchte mich vor Android, weil jedes verdammte Telefon anders ist.)

4

Ja, ich denke nicht, dass dies etwas ist, das wir fördern wollen. @martin hat eine ganze Menge Kontext zu dieser Frage, da sie sich auf die Festlegung der UI-Richtlinien bezieht, die wir vor einiger Zeit für den Admin-Bereich insgesamt festgelegt haben.

Im Allgemeinen betrachten wir den Admin-Bereich als etwas, das wir nicht angepasst haben wollen, wenn ich mich richtig erinnere.

Ja, ich denke, es ist sinnvoller, dieses Thema als UX zu behandeln.

@jordan.vidrine, ich denke, dies überschneidet sich mit deinen früheren Bemühungen, Dinge in formkit umzuwandeln, sowie mit Feedback zu formkit selbst.

1 „Gefällt mir“
5

Ja, ich bin ziemlich dagegen. Die Discourse-Admin-UI sollte nicht angepasst werden. Die Konsistenz der UI (naja, meistens, es gibt noch ein paar Seiten, die angegangen werden müssen) ist ein Schlüsselteil des Admin-Erlebnisses.

7

Habe diesem noch eine Chance gegeben

Vorher Nachher
before
before1961×1453 204 KB
after
after1961×1453 189 KB

Das ist das Einfachste, was ich tun konnte. Ich bin mir nicht sicher, ob wir Zeit damit verbringen wollen, diese Benutzeroberfläche zu überarbeiten – die „innere Seitenleiste“ fühlt sich „falsch“ an, aber das könnte mehr Arbeit sein, als wir im Moment priorisieren können :thinking:

8

Glauben Sie, es ist möglich, die Schaltfläche zum Ändern der Reihenfolge der Elemente immer gleichzeitig mit der inneren Seitenleiste sichtbar zu haben? Wenn sie sich unter einer langen Liste von Einstellungen befindet, erfordert das Ändern der Reihenfolge viel Scrollen; man kann nicht sehen, was passiert, während man die Schaltfläche sieht.

2 „Gefällt mir“
9

@moin Danke, dass Sie mich darauf aufmerksam gemacht haben. Das ist oft auch ein Problem für mich. +1

Ich stimme zu, dass das Verschieben der Schaltflächen unter die Seitenleiste (.schema-setting-editor__tree) die Benutzererfahrung verbessern würde.

Ich würde jedoch vorziehen, die Auf-/Ab-Schaltflächen von der Löschen-Schaltfläche zu trennen; die Auf-/Ab-Schaltflächen unter die Seitenleiste zu verschieben und die Löschen-Schaltfläche dort zu belassen, wo sie ist, unter den Einstellungsfeldern.