Solicitando identificadores CSS para temas, componentes de tema (¿plugins también?)

Característica
1

Mi tema-componente utiliza objetos para la configuración y ofrece bastantes campos.

Los estilos de cuadrícula aplicados actualmente a la configuración de objetos utilizan columnas muy estrechas para la columna de pestañas verticales y los campos del esquema.

Quería ofrecer una visualización alternativa para la configuración del objeto, pero no encontré una manera de introducir una forma de modificar la configuración solo para mi tema-componente; no quiero aplicar mis anulaciones de CSS globalmente para todos los temas.

¿Podría Discourse añadir un identificador CSS en el DOM para cada tema y tema-componente, de modo que se puedan añadir diferentes reglas CSS dirigidas a las páginas de configuración de temas específicas?

Aquí está la anulación de CSS simple que uso en mi sitio, que se aplica globalmente:

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

Los estilos predeterminados y anulados:

default_styles
default_styles1730×1927 242 KB

overwritten_styles
overwritten_styles1730×2151 302 KB

5 Me gusta
2

La “solución” es tan fácil como

pero me pregunto un par de cosas

  1. si facilitamos a los autores de temas la personalización de la apariencia de su página de configuración, ¿vamos a dificultar que la gente use esas páginas si todas son diferentes?

  2. ¿Deberíamos arreglar eso en el núcleo para que la página de configuración del tema aproveche mejor el espacio disponible? :thinking: cc @product-managers

3 Me gusta
3

Esta parece ser una preocupación legítima. Como usuario, me encanta que la ubicuidad y consistencia de Discourse haga que sea muy fácil comenzar y participar en un nuevo foro. Como administrador, si tuviera la ocasión de ayudar con otros sitios, también apreciaría la consistencia allí.

(Estoy pensando en todo el soporte técnico para amigos y familiares que me han llamado a hacer. Estoy feliz de ayudar con los iPhones, pero temo a Android porque cada maldito teléfono es diferente).

4

Sí, no creo que esto sea algo que queramos fomentar. @martin tiene bastante contexto sobre esta pregunta en lo que respecta al establecimiento de las pautas de interfaz de usuario que acordamos para la sección de administración en general hace un tiempo.

En general, consideramos que la sección de administración es algo que no queremos que se personalice, si no recuerdo mal.

Sí, creo que tratar este tema como UX tiene más sentido.

@jordan.vidrine creo que esto tiene cierta superposición con tus esfuerzos anteriores para convertir cosas a formkit, así como con los comentarios sobre formkit en sí.

1 me gusta
5

Sí, estoy bastante en contra de esto, la interfaz de usuario de administración de Discourse no debe personalizarse, la consistencia de la interfaz de usuario (bueno, en su mayoría, todavía hay algunas páginas que deben abordarse) es una parte clave de la experiencia de administración.

7

Le di otra oportunidad a este

Antes Después
before
before1961×1453 204 KB
after
after1961×1453 189 KB

Este es el más simple que pude hacer. No estoy seguro de si queremos dedicar tiempo a rehacer esta interfaz de usuario (UI): la “barra lateral interna” se siente “extraña”, pero eso podría ser más trabajo de lo que podemos priorizar ahora mismo :thinking:

8

¿Cree que es posible tener siempre visible el botón para cambiar el orden de los elementos al mismo tiempo que la barra lateral interna? Si está debajo de una larga lista de configuraciones, cambiar el orden requiere mucho desplazamiento; no se puede ver lo que sucede mientras se ve el botón.

2 Me gusta
9

@moin Gracias por señalar esto. A menudo es un problema para mí también. +1

Estoy de acuerdo, mover los botones debajo de la barra lateral (.schema-setting-editor__tree) mejoraría la experiencia del usuario.

Sin embargo, preferiría separar los botones de subir/bajar del botón de eliminar; mover los botones de subir/bajar debajo de la barra lateral y dejar el botón de eliminar como está, debajo de los campos de configuración.