La forma en que escribimos CSS para temas de WordPress está en medio de cambios radicales. Recientemente compartí una técnica para agregando soporte de tipo fluido en WordPress por medio de theme.json, un nuevo archivo que WordPress ha estado presionando mucho convertirse en una fuente central de verdad para definir estilos en temas de WordPress que admitan funciones de edición de sitio completo (FSE).

Espera no style.css ¿expediente? Todavía tenemos eso. En realidad, style.css is sigue siendo un archivo requerido en los temas de bloque, aunque su función se reduce en gran medida a la metainformación utilizada para registrar el tema. Dicho esto, el hecho es que theme.json todavía está en desarrollo activo, lo que significa que estamos en un período de transición en el que puede encontrar estilos definidos allí, en styles.css o incluso a nivel de bloque.

Entonces, ¿cómo se ve realmente el estilo en estos días de WordPress FSE? Eso es lo que quiero cubrir en este artículo. Hay una falta de documentación para diseñar temas de bloque en el Manual para desarrolladores de temas de WordPress, por lo que todo lo que estamos cubriendo aquí es lo que he recopilado sobre dónde están las cosas actualmente, así como discusiones sobre el futuro de la temática de WordPress.

La evolución de los estilos de WordPress

Las nuevas características de desarrollo que se incluyen en WordPress 6.1 acercarnos a un sistema de estilos completamente definido en theme.json, pero todavía queda mucho trabajo por hacer antes de que podamos apoyarnos completamente en él. Una forma en que podemos tener una idea de lo que vendrá en versiones futuras es mediante el uso de la Complemento de Gutenberg. Aquí es donde las características experimentales a menudo se someten a un simulacro.

Otra forma en que podemos tener una idea de dónde estamos es observando la evolución de temas predeterminados de WordPress. Hasta la fecha, hay tres temas predeterminados que admiten la edición de sitios completos:

Pero no empieces a cambiar el CSS style.css para pares de propiedad-valor JSON en theme.json todavía. Todavía hay reglas de estilo CSS que deben admitirse en theme.json antes de pensar en hacer eso. Los problemas importantes restantes se están discutiendo actualmente con el objetivo de trasladar completamente todas las reglas de estilo CSS a theme.json y consolidar diferentes fuentes de theme.json post-extracción Interfaz de usuario para configurar estilos globales directamente en el Editor del sitio de WordPress.

Eso nos deja en una situación relativamente difícil. no solo hay no hay una ruta clara para anular los estilos de tema, pero no está claro de dónde proviene la fuente de esos estilos, ¿es de diferentes capas de theme.json archivos, style.css, el complemento de Gutenberg, o en algún otro lugar?

¿Por qué theme.json en lugar de style.css?

Quizás se pregunte por qué WordPress se está moviendo hacia una definición de estilos basada en JSON en lugar de un archivo CSS tradicional. Ben Dwyer, del equipo de desarrollo de Gutenberg, explica con elocuencia por qué el theme.json el enfoque es un beneficio para los desarrolladores de temas.

Vale la pena leer la publicación de Ben, pero la esencia está en esta cita:

Anular CSS, ya sea estilos de diseño, preestablecidos o de bloque, presenta un obstáculo para la integración y la interoperabilidad: la paridad visual entre la interfaz y el editor se vuelve más difícil de mantener, las actualizaciones para bloquear elementos internos pueden entrar en conflicto con las anulaciones. Además, el CSS personalizado es menos portátil entre otros temas de bloques.

Al animar a los autores de temas a utilizar theme.json API donde sea posible, la jerarquía de estilos definidos "base> tema> usuario" se puede resolver correctamente.

Uno de los principales beneficios de mover CSS a JSON es que JSON es un formato legible por máquina, lo que significa que puede exponerse en la interfaz de usuario del editor de sitios de WordPress al obtener una API, lo que permite a los usuarios modificar los valores predeterminados y personalizar la apariencia de un sitio sin escribir cualquier CSS en absoluto. También proporciona una forma de aplicar estilo a los bloques de forma coherente, al tiempo que proporciona una estructura que crea capas de especificidad de modo que la configuración del usuario tenga la máxima prioridad sobre las definidas en theme.json. Esa interacción entre los estilos a nivel de tema en theme.json y los estilos definidos por el usuario en la interfaz de usuario de estilos globales es lo que hace que el enfoque JSON sea tan atractivo.

Los desarrolladores mantienen la coherencia en JSON y los usuarios obtienen flexibilidad con personalizaciones sin código. Eso es ganar-ganar.

Hay otros beneficios, seguro, y Mike McAlister de WP Engine enumera varios en este hilo de Twitter. Puede encontrar aún más beneficios en este discusión en profundidad en el blog Make WordPress Core. Y una vez que haya leído eso, compare los beneficios del enfoque JSON con las formas disponibles para definir y anular estilos en temas clásicos.

Definición de estilos con elementos JSON

Ya hemos visto mucho progreso en cuanto a qué partes de un tema theme.json es capaz de peinar. Antes de WordPress 6.1, todo lo que realmente podíamos hacer era diseñar encabezados y enlaces. Ahora, con WordPress 6.1, podemos agregar botones, subtítulos, citas y encabezados a la mezcla.

Y lo hacemos definiendo elementos JSON. Piense en los elementos como componentes individuales que viven en un bloque de WordPress. Digamos que tenemos un bloque que contiene un encabezado, un párrafo y un botón. Esas piezas individuales son elementos, y hay una elements objeto en theme.json donde definimos sus estilos:

{ "version": 2, "settings": {}, // etc. "styles": { // etc. "elements": { "button": { ... }, "h1": { ... }, "heading": { ... }, }, }, "templateParts": {}
}

Una mejor manera de describir los elementos JSON es como componentes de bajo nivel para temas y bloques que no necesitan la complejidad de los bloques. Son representaciones de primitivas HTML que no están definidos en un bloque pero se pueden usar entre bloques. Cómo se admiten en WordPress (y el complemento de Gutenberg) se describe en el Manual del editor de bloques y este Tutorial de edición completa del sitio de Carolina Nymark.

Por ejemplo, los vínculos se diseñan en el elements objeto, pero no son un bloque por derecho propio. Pero un enlace se puede usar en un bloque y heredará los estilos definidos en el elements.link objeto en theme.json. Sin embargo, esto no encapsula completamente la definición de un elemento, ya que algunos elementos también se registran como bloques, como los bloques de encabezado y botón, pero esos bloques aún se pueden usar dentro de otros bloques.

Aquí hay una tabla de los elementos que están actualmente disponibles para diseñar en theme.json, cortesía de carolina:

Como puede ver, todavía es pronto y aún queda mucho por pasar del complemento de Gutenberg a WordPress Core. Pero puede ver lo rápido que sería hacer algo como diseñar todos los encabezados en un tema globalmente sin buscar selectores en archivos CSS o DevTools.

Además, también puede comenzar a ver cómo la estructura de theme.json forma capas de especificidad, pasando de elementos globales (por ejemplo, headings) a elementos individuales (p. ej. h1) y estilos a nivel de bloque (p. ej. h1 contenido en un bloque).

Información adicional sobre elementos JSON está disponible en esta propuesta de Make WordPress y este boleto abierto en el repositorio de GitHub del complemento de Gutenberg.

Especificidad JSON y CSS

Sigamos hablando de la especificidad de CSS. Mencioné anteriormente que el enfoque JSON para diseñar establece una jerarquía. Y es verdad. Estilos que se definen en elementos JSON en theme.json se consideran estilos de tema predeterminados. Y todo lo que establezca el usuario en la interfaz de usuario de Estilos globales anulará los valores predeterminados.

En otras palabras: los estilos de usuario tienen más especificidad que los estilos de tema predeterminados. Echemos un vistazo al bloque Botón para tener una idea de cómo funciona.

Estoy usando Tema vacío, un tema de WordPress en blanco sin estilo CSS. Voy a agregar un bloque de botón en una nueva página.

Bien, sabemos que WordPress Core viene con un estilo ligero. Ahora, cambiaré al tema TT3 predeterminado de WordPress 6.1 y lo activaré. Si actualizo mi página con el botón, el botón cambia de estilo.

Puedes ver exactamente de dónde vienen esos nuevos estilos en TT3 theme.json expediente. Esto nos dice que los estilos de elementos JSON tienen prioridad sobre los estilos de WordPress Core.

Ahora voy a modificar TT3 anulándolo con un theme.json archivo en un tema secundario, donde el color de fondo predeterminado del bloque Botón se establece en rojo.

Pero observe el botón de búsqueda en esa última captura de pantalla. Debería ser rojo también, ¿verdad? Eso debe significar que tiene un estilo de otro nivel si el cambio que hice es a nivel global. Si queremos cambiar ambas botones, podríamos hacerlo a nivel de usuario utilizando la interfaz de usuario de Estilos globales en el editor del sitio.

Cambiamos el color de fondo de ambos botones a azul y también modificamos el texto usando la interfaz de usuario de estilos globales. ¡Observe que el azul de allí prevaleció sobre los estilos temáticos!

El motor de estilo

Esa es una idea muy rápida, pero buena, de cómo se gestiona la especificidad de CSS en los temas de bloque de WordPress. Pero no es la imagen completa porque aún no está claro donde se generan esos estilos. WordPress tiene sus propios estilos predeterminados que provienen de alguna parte, consume los datos en theme.json para obtener más reglas de estilo y anula aquellas con cualquier configuración en Estilos globales.

¿Están esos estilos en línea? ¿Están en una hoja de estilo separada? Tal vez se inyectan en la página en un <script>?

Eso es lo nuevo Motor de estilo es de esperar que va a resolver. Style Engine es una nueva API en WordPress 6.1 que tiene como objetivo brindar coherencia a la forma en que se generan los estilos y dónde se aplican los estilos. En otras palabras, toma todas las fuentes posibles de estilo y es singularmente responsable de generar estilos de bloque correctamente. Sé que sé. Otra abstracción más sobre otras abstracciones solo para crear algunos estilos. Pero tener una API centralizada para estilos es probablemente la solución más elegante dado que los estilos pueden provenir de varios lugares.

Solo estamos viendo por primera vez el motor de estilos. De hecho, esto es lo que se ha completado hasta ahora, según el billete:

• Audite y consolide dónde el código genera CSS de soporte de bloque en el back-end para que se entreguen desde el mismo lugar (en lugar de múltiples lugares). Esto cubre las reglas de CSS como el margen, el relleno, la tipografía, los colores y los bordes.
• Elimine estilos repetitivos específicos del diseño y genere nombres de clase semánticos.
• Reduzca la cantidad de etiquetas de estilo en línea que imprimimos en la página para compatibilidad con bloques, diseño y elementos.

Básicamente, esta es la base para establecer una única API que contenga todas las reglas de estilo CSS para un tema, vengan de donde vengan. Limpia la forma en que WordPress inyectaría estilos en línea anteriores a 6.1 y establece un sistema para nombres de clase semánticos.

Se pueden encontrar más detalles sobre los objetivos a corto y largo plazo de Style Engine en este Hacer una discusión sobre el núcleo de WordPress. También puedes seguir el problema de seguimiento y junta de proyecto para más actualizaciones.

Trabajando con elementos JSON

Hablamos un poco sobre los elementos JSON en el theme.json archivo y cómo son básicamente primitivas de HTML para definir estilos predeterminados para cosas como encabezados, botones y enlaces, entre otros. Ahora, veamos en realidad usando un elemento JSON y cómo se comporta en varios contextos de estilo.

Los elementos JSON generalmente tienen dos contextos: el nivel global y del nivel de bloque. Los estilos de nivel global se definen con menos especificidad que en el nivel de bloque para garantizar que los estilos específicos de bloque tengan prioridad para la coherencia dondequiera que se utilicen bloques.

Estilos globales para elementos JSON

Veamos el nuevo tema predeterminado de TT3 y examinemos el estilo de sus botones. El siguiente es un copiar y pegar abreviado del TT3 theme.json archivo (aquí está el código completo) que muestra la sección de estilos globales, pero puede encontrar el código original aquí.

{ "version": 2, "settings": {}, // ... "styles": { // ... "elements": { "button": { "border": { "radius": "0" }, "color": { "background": "var(--wp--preset--color--primary)", "text": "var(--wp--preset--color--contrast)" }, ":hover": { "color": { "background": "var(--wp--preset--color--contrast)", "text": "var(--wp--preset--color--base)" } }, ":focus": { "color": { "background": "var(--wp--preset--color--contrast)", "text": "var(--wp--preset--color--base)" } }, ":active": { "color": { "background": "var(--wp--preset--color--secondary)", "text": "var(--wp--preset--color--base)" } } }, "h1": { "typography": { } }, // ... "heading": { "typography": { "fontWeight": "400", "lineHeight": "1.4" } }, "link": { "color": { "text": "var(--wp--preset--color--contrast)" }, ":hover": { "typography": { "textDecoration": "none" } }, ":focus": { "typography": { "textDecoration": "underline dashed" } }, ":active": { "color": { "text": "var(--wp--preset--color--secondary)" }, "typography": { "textDecoration": "none" } }, "typography": { "textDecoration": "underline" } } }, // ... }, "templateParts": {}
}

Todos los botones tienen estilo a nivel global (styles.elements.button).

También podemos confirmar esto en DevTools. Observe que una clase llamada .wp-element-button es el seleccionador. La misma clase también se usa para diseñar los estados interactivos.

Nuevamente, este estilo está ocurriendo a nivel global, viniendo de theme.json. Siempre que usemos un botón, tendrá el mismo fondo porque comparten el mismo selector y ninguna otra regla de estilo lo anula.

Aparte, WordPress 6.1 agregó soporte para diseñar estados interactivos para ciertos elementos, como botones y enlaces, usando pseudo-clases en theme.json - incluyendo :hover, :focusy :active — o la interfaz de usuario de Estilos globales. Ingeniero Automático Dave Smith demuestra Esta característica en un video de YouTube.

Podríamos anular el color de fondo del botón en theme.json (preferiblemente en un tema secundario ya que estamos usando un tema predeterminado de WordPress) o en la configuración de Estilos globales en el editor del sitio (no se necesita un tema secundario ya que no requiere un cambio de código).

Pero luego los botones cambiarán todos a la vez. ¿Qué pasa si queremos anular el color de fondo cuando el botón es parte de un determinado bloque? Ahí es donde entran en juego los estilos a nivel de bloque.

Estilos a nivel de bloque para elementos

Para entender cómo podemos usar y personalizar estilos a nivel de bloque, cambiemos el color de fondo del botón que está contenido en el bloque Buscar. Recuerde, hay un bloque de botón, pero lo que estamos haciendo es anular el color de fondo en el nivel de bloque del bloque de búsqueda. De esa forma, solo aplicaremos el nuevo color allí en lugar de aplicarlo globalmente a todos los botones.

Para hacer eso, definimos los estilos en el styles.blocks objeto en theme.json. Así es, si definimos los estilos globales para todos los botones en styles.elements, podemos definir los estilos específicos de bloque para elementos de botón en styles.block, que sigue una estructura similar:

{ "version": 2, // ... "styles": { // Global-level syles "elements": { }, // Block-level styles "blocks": { "core/search": { "elements": { "button": { "color": { "background": "var(--wp--preset--color--quaternary)", "text": "var(--wp--preset--color--base)" } } }, // ... } } }
}

¿Mira eso? puse el background y text propiedades en styles.blocks.core/search.elements.button con dos variables CSS que están preestablecidas en WordPress.

¿El resultado? El botón de búsqueda ahora es rojo (--wp--preset--color--quaternary), y el bloque de botón predeterminado conserva su fondo verde brillante.

También podemos ver el cambio en DevTools.

Lo mismo es cierto si queremos diseñar botones que están incluidos en otros bloques. Y los botones son simplemente un ejemplo, así que veamos otro.

Ejemplo: Estilo de encabezados en cada nivel

Llevemos toda esta información a casa con un ejemplo. Esta vez, vamos a:

• Aplicar estilo a todos los encabezados globalmente
• Aplicar estilo a todos los elementos del Título 2
• Encabezado de estilo 2 elementos en el bloque Query Loop

Primero, comencemos con la estructura básica para theme.json:

{ "version": 2, "styles": { // Global-level syles "elements": { }, // Block-level styles "blocks": { } }
}

Esto establece el esquema para nuestros estilos globales y de nivel de bloque.

Aplicar estilo a todos los encabezados globalmente

Agreguemos el headings oponerse a nuestros estilos globales y aplicar algunos estilos:

{ "version": 2, "styles": { // Global-level syles "elements": { "heading": { "color": "var(--wp--preset--color--base)" }, }, // Block-level styles "blocks": { } }
}

Eso establece el color de todos los encabezados en el color base preestablecido en WordPress. Cambiemos el color y el tamaño de fuente de los elementos del Título 2 a nivel global también:

{ "version": 2, "styles": { // Global-level syles "elements": { "heading": { "color": "var(--wp--preset--color--base)" }, "h2": { "color": "var(--wp--preset--color--primary)", "typography": { "fontSize": "clamp(2.625rem, calc(2.625rem + ((1vw - 0.48rem) * 8.4135)), 3.25rem)" } } }, // Block-level styles "blocks": { } }
}

Ahora, todos los elementos del Título 2 están configurados para ser el color preestablecido principal con un tamaño de fuente fluido. Pero tal vez queremos un arreglo fontSize para el elemento Encabezado 2 cuando se usa en el bloque Query Look:

{ "version": 2, "styles": { // Global-level syles "elements": { "heading": { "color": "var(--wp--preset--color--base)" }, "h2": { "color": "var(--wp--preset--color--primary)", "typography": { "fontSize": "clamp(2.625rem, calc(2.625rem + ((1vw - 0.48rem) * 8.4135)), 3.25rem)" } } }, // Block-level styles "blocks": { "core/query": { "elements": { "h2": { "typography": { "fontSize": 3.25rem } } } } } }
}

Ahora tenemos tres niveles de estilos para los elementos del Título 2: todos los títulos, todos los elementos del Título 2 y los elementos del Título 2 que se utilizan en el bloque Query Loop.

Ejemplos de temas existentes

Si bien en este artículo solo vimos los ejemplos de estilo para botones y encabezados, WordPress 6.1 admite elementos adicionales de estilo. Hay una tabla que los describe en el “Definiendo estilos con elementos JSON” .

Probablemente se esté preguntando qué elementos JSON admiten qué propiedades CSS, sin mencionar cómo las declararía. Mientras esperamos la documentación oficial, los mejores recursos que tenemos serán los theme.json archivos para temas existentes. Voy a proporcionar enlaces a temas en función de los elementos que personalicen y señalaré qué propiedades se personalizan.

Asegúrese de darle a cada theme.json fíjese bien porque estos temas incluyen excelentes ejemplos de estilo a nivel de bloque en el styles.blocks objeto.

Terminando

Los cambios frecuentes en el editor de sitio completo se están convirtiendo en un principales fuentes de irritación para muchas personas, incluyendo Usuarios de Gutenberg expertos en tecnología. Incluso las reglas CSS muy simples, que funcionan bien con temas clásicos, no parecen funcionar para temas de bloque debido a la nuevas capas de especificidad cubrimos antes.

Con respecto a un propuesta de GitHub para rediseñar el editor del sitio en un nuevo modo de navegador, Sara Gooding escribe en una publicación de WP Tavern:

Es fácil perderse al tratar de moverse por el Editor del sitio, a menos que esté trabajando día y noche dentro de la herramienta. La navegación es inestable y confusa, especialmente cuando se pasa de la exploración de plantillas a la edición de plantillas y la modificación de bloques individuales.

Incluso como uno de los primeros entusiastas del mundo del editor de bloques de Gutenberg y los temas de ojos de bloque, tengo toneladas de mis propias frustraciones. Sin embargo, soy optimista y anticipo que el editor del sitio, una vez completado, será una herramienta revolucionaria tanto para los usuarios como para los desarrolladores de temas expertos en tecnología. Este tuit esperanzador eso ya lo confirma. Mientras tanto, parece que deberíamos estar preparándonos para más cambios, y tal vez incluso para un viaje lleno de baches.

Referencias

Estoy enumerando todos los recursos que utilicé mientras buscaba información para este artículo.

elementos JSON

Estilos globales

Motor de estilo

¡Gracias por leer! Me encantaría escuchar sus propias reflexiones sobre el uso de los temas de bloque y cómo administra su CSS.

• Coinsmart. El mejor intercambio de Bitcoin y criptografía de Europa.Haga clic aquí
• Platoblockchain. Inteligencia del Metaverso Web3. Conocimiento amplificado. Accede Aquí.
• Fuente: https://css-tricks.com/managing-css-styles-in-a-wordpress-block-theme/