Enfoque

Mientras que las páginas de inicio proporcionan un recorrido introductorio del proyecto y lo que ofrece, este documento se centra en por qué hacemos lo que hacemos en Bootstrap. Explica nuestra filosofía de construcción en la web para que otros puedan aprender de nosotros, contribuir con nosotros y ayudarnos a mejorar.

¿Ves algo que no suena bien, o que quizás podría hacerse mejor? Abre un issue—nos encantaría discutirlo contigo.

Summary

Profundizaremos en cada uno de estos puntos más adelante, pero a grandes rasgos, esto es lo que guía nuestro enfoque.

• Los componentes deben ser responsive y mobile-first
• Los componentes deben construirse con una clase base y extenderse mediante clases modificadoras
• Los estados de los componentes deben obedecer una escala común de z-index
• Siempre que sea posible, preferir una implementación con HTML y CSS sobre JavaScript
• Siempre que sea posible, usar utilidades sobre estilos personalizados
• Siempre que sea posible, evitar imponer requisitos estrictos de HTML (selectores de hijos)

Responsive

Los estilos responsive de Bootstrap están construidos para ser responsive, un enfoque que a menudo se conoce como mobile-first. Usamos este término en nuestra documentación y en gran medida estamos de acuerdo con él, pero a veces puede ser demasiado amplio. Aunque no todos los componentes deben ser completamente responsive en Bootstrap, este enfoque responsive se trata de reducir las sobrescrituras de CSS al impulsarte a añadir estilos a medida que el viewport se hace más grande.

En todo Bootstrap, verás esto más claramente en nuestras media queries. En la mayoría de los casos, usamos queries de min-width que comienzan a aplicarse en un breakpoint específico y se mantienen hasta los breakpoints superiores. Por ejemplo, un .d-none se aplica desde min-width: 0 hasta el infinito. Por otro lado, un .d-md-none se aplica desde el breakpoint medium hacia arriba.

A veces usaremos max-width cuando la complejidad inherente de un componente lo requiera. A veces, estas sobrescrituras son más claras funcional y mentalmente de implementar y soportar que reescribir la funcionalidad central de nuestros componentes. Nos esforzamos por limitar este enfoque, pero lo usaremos de vez en cuando.

Clases

Aparte de nuestro Reboot, una hoja de estilos de normalización entre navegadores, todos nuestros estilos tienen como objetivo usar clases como selectores. Esto significa evitar los selectores de tipo (p. ej., input[type="text"]) y clases padre extrañas (p. ej., .parent .child) que hacen que los estilos sean demasiado específicos para sobrescribirlos fácilmente.

Como tal, los componentes deben construirse con una clase base que albergue pares propiedad-valor comunes que no deben sobrescribirse. Por ejemplo, .btn y .btn-primary. Usamos .btn para todos los estilos comunes como display, padding y border-width. Luego usamos modificadores como .btn-primary para añadir el color, background-color, border-color, etc.

Las clases modificadoras solo deben usarse cuando hay múltiples propiedades o valores que cambiar a través de múltiples variantes. Los modificadores no siempre son necesarios, así que asegúrate de que realmente estás ahorrando líneas de código y evitando sobrescrituras innecesarias al crearlos. Buenos ejemplos de modificadores son nuestras clases de colores de tema y las variantes de tamaño.

Escalas de z-index

Hay dos escalas de z-index en Bootstrap—elementos dentro de un componente y componentes superpuestos.

Elementos de componentes

• Algunos componentes en Bootstrap se construyen con elementos superpuestos para evitar bordes dobles sin modificar la propiedad border. Por ejemplo, grupos de botones, grupos de entrada y paginación.
• Estos componentes comparten una escala estándar de z-index de 0 a 3.
• 0 es el valor predeterminado (inicial), 1 es :hover, 2 es :active/.active, y 3 es :focus.
• Este enfoque coincide con nuestras expectativas de máxima prioridad para el usuario. Si un elemento tiene el foco, está a la vista y en la atención del usuario. Los elementos activos son los segundos en prioridad porque indican estado. Hover es el tercero en prioridad porque indica la intención del usuario, pero casi cualquier cosa puede recibir hover.

Componentes de superposición

Bootstrap incluye varios componentes que funcionan como algún tipo de superposición. Esto incluye, en orden de mayor z-index, desplegables, barras de navegación fijas y sticky, modales, tooltips y popovers. Estos componentes tienen su propia escala de z-index que comienza en 1000. Este número inicial se eligió arbitrariamente y sirve como un pequeño buffer entre nuestros estilos y los estilos personalizados de tu proyecto.

Cada componente superpuesto aumenta su valor de z-index ligeramente de tal manera que los principios comunes de UI permiten que los elementos enfocados o con hover por el usuario permanezcan siempre visibles. Por ejemplo, un modal bloquea el documento (p. ej., no puedes realizar ninguna otra acción más que la del modal), por lo que lo ponemos por encima de nuestras barras de navegación.

Obtén más información sobre esto en nuestra página de diseño z-index.

HTML y CSS sobre JS

Siempre que sea posible, preferimos escribir HTML y CSS sobre JavaScript. En general, HTML y CSS son más prolíficos y accesibles para más personas de todos los niveles de experiencia. HTML y CSS también son más rápidos en tu navegador que JavaScript, y tu navegador generalmente proporciona una gran cantidad de funcionalidad por ti.

Este principio es nuestra API de JavaScript de primera clase usando atributos data. No necesitas escribir casi nada de JavaScript para usar nuestros plugins de JavaScript; en su lugar, escribe HTML. Lee más sobre esto en nuestra página de overview de JavaScript.

Por último, nuestros estilos se basan en los comportamientos fundamentales de los elementos web comunes. Siempre que es posible, preferimos usar lo que el navegador proporciona. Por ejemplo, puedes poner una clase .btn en casi cualquier elemento, pero la mayoría de los elementos no proporcionan ningún valor semántico ni funcionalidad del navegador. Así que en su lugar, usamos <button>s y <a>s.

Lo mismo se aplica a componentes más complejos. Aunque podríamos escribir nuestro propio plugin de validación de formularios para añadir clases a un elemento padre basándose en el estado de una entrada, permitiéndonos así estilizar el texto digamos de rojo, preferimos usar los pseudo-elementos :valid/:invalid que todo navegador nos proporciona.

Utilidades

Las clases utilitarias—antes helpers en Bootstrap 3—son un aliado poderoso para combatir la inflación de CSS y el bajo rendimiento de la página. Una clase utilitaria es típicamente un par propiedad-valor único e inmutable expresado como una clase (p. ej., .d-block representa display: block;). Su principal atractivo es la velocidad de uso al escribir HTML y limitar la cantidad de CSS personalizado que tienes que escribir.

Específicamente en cuanto al CSS personalizado, las utilidades pueden ayudar a combatir el aumento del tamaño del archivo al reducir tus pares propiedad-valor más repetidos en clases únicas. Esto puede tener un efecto dramático a escala en tus proyectos.

HTML flexible

Aunque no siempre es posible, nos esforzamos por evitar ser demasiado dogmáticos en nuestros requisitos de HTML para los componentes. Por lo tanto, nos centramos en clases únicas en nuestros selectores CSS e intentamos evitar selectores de hijos directos (>). Esto te da más flexibilidad en tu implementación y ayuda a mantener nuestro CSS más simple y menos específico.

Convenciones de código

Code Guide (del co-creador de Bootstrap, @mdo) documenta cómo escribimos nuestro HTML y CSS en Bootstrap. Especifica pautas para formato general, valores predeterminados de sentido común, orden de propiedades y atributos, y más.

Usamos Stylelint para aplicar estos estándares y más en nuestro Sass/CSS. Nuestra configuración personalizada de Stylelint es de código abierto y está disponible para que otros la usen y extiendan.

Usamos vnu-jar para aplicar HTML estándar y semántico, así como detectar errores comunes.