Cómo no escribir plantillas para bootstrap

Pocas personas ahora están diseñando un sitio web desde cero, ¿por qué, si hay un montón de marcos CSS geniales? El más popular entre ellos es bootstrap. Sin embargo, todos quieren que el sitio se vea único, no como los demás, por eso a menudo se adhieren (lo mejor que pueden) a una plantilla gratuita o de pago, o su propio kit de UI.

Quiero hablar sobre algunos problemas que (desafortunadamente) ocurren incluso en las plantillas pagas, sin mencionar mis soluciones. El texto a continuación no pretende ser único, y es poco probable que sea de interés para desarrolladores experimentados, pero puede ser útil para desarrolladores principiantes de front-end, diseñadores de diseño y desarrolladores web de base amplia. Entonces, si aún estás interesado, ¡bienvenido!

Históricamente tenemos ...

Como regla general, si un sitio se ha desarrollado durante mucho tiempo, los requisitos para su apariencia cambian regularmente. Si, además de esto, los programadores cambian regularmente, entonces el código (en nuestro caso, css) se convierte en un desastre. En algún lugar, clases de bootstrap, a veces clases de plantilla, todo esto se diluye con muletas de varias generaciones de diseñadores de diseño y se condimenta con estilos en línea. Los intentos de cambiar algo o agregar uno nuevo conducen a largos juegos mágicos en "¡adivina qué clases necesitas poner en este bloque html!". Quiero tirar todo y reescribirlo desde cero. Pero aquí, de hecho, busqué agregar rápidamente nuevos campos al formulario, tengo suficientes tareas para el backend ... En realidad, consideraremos la razón que me llevó a escribir este artículo, en el primer ejemplo.

Tamaño de entrada

Entonces, tenemos una vista estándar de elementos de formulario, que queremos cambiar un poco, por ejemplo, reducir la altura. ¿Cuáles son las formas de hacer esto para que las entradas correspondan a la ballena UI?

¡Puedes insertar estilos en línea! Será muy divertido, ¡luego copie todo este paño en cada entrada!

Alguien se reirá, pero regularmente veo tales decisiones. Afortunadamente no en este caso, pero lo hace. ¿Qué pasa si hacemos esto? Tendrá que copiar descripciones de estilo largas en cada entrada, inflando la plantilla y haciéndola menos legible.

¡Escribamos nuestra propia clase, en la que describiremos la configuración de altura necesaria, y al mismo tiempo cambiaremos el tamaño de fuente!

Si Es el. "H40_px-16". Por el nombre de la clase, ¿queda claro de inmediato qué hace? Conocí algo como esto cuando intentaba entender por qué las nuevas entradas son un poco más gruesas de lo necesario. Miré el código en la misma plantilla y lo encontré. ¿Qué consecuencias nos esperan en este caso? En principio, nada crítico. En cada clase de elementos de formulario, además de "control de formulario", agregaremos "h40_px-16". Necesito recordar, o documentar. ¿Y si hay un requisito para hacer todos los elementos del formulario con un fondo verde? Simplemente agregue otra clase, "b_g". Y luego uno más ...

Extender clases existentes para elementos de formulario?

Es extremadamente raro ver esta solución, aunque me parece que está en la superficie. Y en mi opinión, lo más correcto. Esto nos permite ahorrar en la cantidad de clases que deben especificarse en el elemento, pero lo más importante es que reduce la cantidad de perplejidad entre los desarrolladores que intentan trabajar con este código. Si el cambio requerido afecta a todos los elementos de este tipo, simplemente agregamos nuestro propio conjunto de reglas para "control de formulario", y todas las entradas cambian su altura, fuente, fondo, etc.

Solución personalizada

De acuerdo con el kit de interfaz de usuario, debe agregar una solución innovadora que nunca antes se había visto en el sitio. Y está escrito desde cero. Enserio? No, puedo permitir esto si usa pureCSS, un marco bueno pero minimalista, y necesita implementar algo que no está incluido en él. Pero si usa bootstrap, con una probabilidad extremadamente alta, solo necesita volver a leer la documentación.

Veamos una situación extremadamente descuidada en la que el sitio tiene su propia implementación de insignias. Con bootstrap conectado. Y así, uno de los desarrolladores que no participó en la creación de estas insignias necesitaba agregarlas en algún lugar del sitio.

1. Primero, mira la documentación de arranque y copia la solución desde allí.
2. Al ver que visualmente esto no corresponde a la ballena UI, busca documentación sobre la solución innovadora utilizada.
3. Si esta documentación no es (y probablemente no lo sea), busca en el código ejemplos de cómo se implementa.
4. Después de copiar la clase beijik deseada, ve que la insignia ahora es correcta, pero azul, y necesita rojo.
5. Después de encontrar el archivo css que describe las clases para la interfaz de usuario de la ballena, detecta que no se colocó el color rojo y suspirando agrega la clase "beijik-red"

Ahora, comparemos esto con la situación en la que la clase de insignia se redefinió para su propia implementación de insignia, y la implementación de color se describió en la documentación:

1. Primero, mira la documentación de arranque y copia la solución desde allí.
2. La documentación encuentra cómo agregar rojo: insignia-rojo

Aquí examinamos un ejemplo en el que es necesario no solo cambiar la solución preparada, sino también expandirla, ya que no estamos satisfechos con la funcionalidad lista para usar (las insignias en bootstrap3 no tienen un color personalizado). En este caso, de todos modos, la mejor solución sigue siendo anular la clase existente, y solo después de eso, agregar la suya.

Por supuesto, los ejemplos que he dado son bastante refinados, pero realmente encontré una situación en la que primero busqué una solución en la documentación de bootstrap, luego en la documentación de la plantilla utilizada en el sitio (afortunadamente, había documentación para ello), luego busqué archivos css donde y cómo se redefinió el comportamiento estándar y cómo se implementó el análogo, pero al final escribí mis propios estilos para devolver (!) las posibilidades que originalmente tenían.

Si no desea perjudicar a sus colegas y quiere acelerar el trabajo del equipo en su conjunto, cumpla con las siguientes reglas al crear sus propios estilos para el sitio:

• Compruebe cómo se implementa la funcionalidad necesaria en el marco utilizado (recuerde, lo más probable es que esté allí).
• Encuentre qué clases deben redefinirse para llevar el aspecto al deseado.
• Si la funcionalidad no se implementa o no se implementa por completo, coordine con sus colegas una forma conveniente de expandir la funcionalidad e intente documentarla para el futuro.
• Si la funcionalidad no es necesaria en todas partes, sino solo en una página específica, colóquela en un archivo separado y conéctela / recójala (sin estilos en línea, por favor)

Epílogo

Todo lo anterior es mi opinión personal. No soy un desarrollador front-end profesional y, por lo general, encuentro html y css cuando agrego alguna funcionalidad nueva: es más conveniente para mí configurar de inmediato tanto el frente como la parte posterior, y luego asignarlo para peinar el diseño. Si su equipo ha establecido procesos, describió las reglas de un buen código, compiló pautas para todos los desarrolladores y todo pasa por una revisión de código, puede reírse de este artículo, no me importa. Si el artículo resulta útil para alguien, no fue en vano que expuse mis pensamientos confusos.