¿Está bien incluir CSS en línea en los complementos?


21

Normalmente en un complemento agregaría estilos usando wp_enqueue_style. Sin embargo, actualmente estoy creando un complemento que solo necesita unas pocas líneas de CSS y me pregunto si sería mejor servir los estilos en línea para guardar una solicitud. Obviamente, hay muchas ventajas de usar wp_enqueue_style, pero ¿valen la pena la solicitud adicional de un CSS tan pequeño? ¿Hay alguna 'mejor práctica' aceptada en esta área?

Respuestas:


14

TL; DR; Enqueue

Usando una hoja de estilo externa

  • PRO: Todos tus estilos están en un solo lugar.
  • PRO: Reduce la codificación de la página web.
  • PRO: más fácil de mantener el complemento.
  • PRO: puede usar ganchos para alterar la ubicación del archivo.
  • PRO: puede usar ganchos para eliminar la cola del archivo.
  • PRO: puede usar estilos minify automáticamente.
  • CON: Podría agregar una solicitud HTTP adicional (se puede superar).

Usando estilos en línea

  • PRO: puede ver directamente el estilo aplicado.
  • PRO: No hay solicitudes HTTP adicionales.
  • CON: No se pueden usar ganchos para alterar los estilos.
  • CON: No se pueden usar ganchos para eliminar los estilos.
  • CON: No se pueden minimizar estilos en absoluto.
  • CON: ¡ Necesito ! Importante para anular el estilo

Normalmente diría: Claro, si usted es el único que lo usa, continúe y hágalo en línea. Pero está hablando de un complemento, lo que significa que el código será público, así que apunte a la extensibilidad. En este momento solo tienes unas pocas líneas de estilo:

  • CON: ¿Qué pasa si esos pocos se vuelven más?
  • CON: ¿Qué pasa si alguien extiende su complemento?
  • CON: ¿Qué pasa si alguien quiere alterarlo?
  • CON: ¿Qué pasa si alguien lo busca en archivos CSS?
  • CON: ¿Qué pasa si alguien quiere minificarlo automáticamente?

Por lo tanto, en cola. (Preferiblemente condicionalmente solo si el complemento lo necesita). Lo mismo se aplica a JavaScript . (Pero eso debería incluirse en el pie de página si es posible).


¿Está bien usar estilos en línea en el backend?
shea

@bungeshea Si alguien va a cambiar su complemento, es posible que también desee cambiar el backend correctamente;) Solo asegúrese de poner en cola el script solo cuando esté en el backend. Por ejemplo: function _your_enqueue( $hook )puede probar $ hook para ver si está en su página de opciones. Alternativamente, puede usar current_screen()para propiedades más simples . La cuestión es que se le permite hacer esto, pero el uso general es un complemento que consiste en un archivo .php para el código del servidor y puede o no tener imágenes, archivos .js y .css.
Derk-

1
Usted nota que la solicitud http adicional se puede superar, ¿puede aclarar esto?
Dustin

2
No puedes, pero el usuario del complemento sí. Hay varios complementos y funciones escritos, justo antes de que salga la página, obtenga TODOS los estilos en cola y agréguelos a un archivo combinado y minimizado. No importa cuántos archivos CSS agregue, el espectador solo verá uno. Lo mismo para javascript. Sin embargo, este no es su "problema" en su caso. Es una optimización que no es necesaria y, en mi opinión, la solicitud HTTP adicional se queda corta frente a todos los PRO.
Derk-

1
Acerca de la última oración: los estilos AFAIK deben aparecer en el encabezado, no en el pie de página
Mark Kaplun

2

Esto es difícil de responder y realmente no estoy seguro de si hay una respuesta oficial.

Entiendo el sentimiento acerca de guardar una solicitud, pero el estilo en línea casi siempre gana. Un tema o usuario final tendrá dificultades para alterar su CSS.

Con eso en mente, creo que haría esto en un complemento lanzado públicamente ...

  1. si el CSS es absolutamente crítico para el funcionamiento del complemento, como es el caso de las presentaciones de diapositivas, por ejemplo.

  2. O, si también incluí un filtro en el complemento que permite alterar o eliminar el CSS en línea.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.