Enfoque

Si bien las páginas de inicio rápido ofrecen un recorrido introductorio del proyecto y lo que ofrece, este documento se centra en el porqué hacemos las cosas que hacemos en Bootstrap. Explica nuestra filosofía para construir en la web para que otros puedan aprender de nosotros, colaborar con nosotros y ayudarnos a mejorar.

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

Resumen

Profundizaremos en cada uno de estos aspectos a lo largo del documento, pero a un alto nivel, esto es lo que guía nuestro enfoque.

• Los componentes deben ser responsivos y mobile-first (primero móviles)
• Los componentes deben construirse con una clase base y extenderse mediante clases modificadoras
• Los estados de los componentes deben obedecer a una escala de z-index común
• Siempre que sea posible, prefiere una implementación HTML y CSS sobre JavaScript
• Siempre que sea posible, usa utilidades sobre estilos personalizados
• Siempre que sea posible, evita imponer requisitos de HTML estrictos (selectores de hijos inmediatos)

Responsivo

Los estilos responsivos de Bootstrap están diseñados para ser responsivos, un enfoque que a menudo se denomina mobile-first. Usamos este término en nuestra documentación y estamos de acuerdo con él en gran medida, pero a veces puede ser demasiado amplio. Si bien no todos los componentes deben ser completamente responsivos en Bootstrap, este enfoque responsivo se trata de reducir las anulaciones de CSS al impulsarte a agregar estilos a medida que la ventana gráfica (viewport) se agranda.

En todo Bootstrap, verás esto más claramente en nuestras consultas de medios (media queries). En la mayoría de los casos, usamos consultas min-width que comienzan a aplicarse en un punto de interrupción específico y continúan a través de los puntos de interrupción 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 punto de interrupción mediano en adelante.

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

Clases

Aparte de nuestro Reboot, una hoja de estilo de normalización para varios navegadores, todos nuestros estilos tienen como objetivo utilizar clases como selectores. Esto significa mantenerse alejado de los selectores de tipo (por ejemplo, input[type="text"]) y clases principales extrañas (por ejemplo, .parent .child) que hacen que los estilos sean demasiado específicos para anularlos fácilmente.

Como tal, los componentes deben construirse con una clase base que albergue pares de propiedad-valor comunes que no se deban anular. 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 agregar el color, background-color, border-color, etc.

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

Escalas z-index

Hay dos escalas z-index en Bootstrap: elementos dentro de un componente y componentes superpuestos (overlay).

Elementos del componente

• Algunos componentes en Bootstrap están construidos 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 z-index estándar 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 mayor prioridad para el usuario. Si un elemento está enfocado, está a la vista y en la atención del usuario. Los elementos activos son los segundos más altos porque indican el estado. El estado hover es el tercero más alto porque indica la intención del usuario, pero casi cualquier cosa puede recibir hover.

Componentes superpuestos

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

Cada componente superpuesto aumenta ligeramente su valor z-index de tal manera que los principios comunes de la interfaz de usuario permiten que los elementos enfocados o con hover del usuario permanezcan a la vista en todo momento. Por ejemplo, un modal bloquea el documento (es decir, no puedes realizar ninguna otra acción excepto la del modal), por lo que lo colocamos 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 comunes 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 te brinda una gran cantidad de funcionalidad.

Este principio se traduce en nuestra API de JavaScript de primera clase mediante atributos data. No necesitas escribir casi nada de JavaScript para usar nuestros complementos de JavaScript; en su lugar, escribe HTML. Lee más sobre esto en nuestra página de resumen de JavaScript.

Por último, nuestros estilos se basan en los comportamientos fundamentales de los elementos web comunes. Siempre que sea posible, preferimos utilizar lo que proporciona el navegador. 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 o funcionalidad del navegador. Por lo tanto, en su lugar, usamos <button> y <a>.

Lo mismo ocurre con los componentes más complejos. Si bien podríamos escribir nuestro propio complemento de validación de formularios para agregar clases a un elemento primario en función del estado de una entrada (lo que nos permitiría dar estilo al texto en rojo, por ejemplo), preferimos usar los pseudoelementos :valid/:invalid que nos proporciona cada navegador.

Utilidades

Las clases de utilidad —anteriormente ayudantes (helpers) en Bootstrap 3— son un poderoso aliado para combatir la saturación de CSS y el bajo rendimiento de la página. Una clase de utilidad suele ser un par único e inmutable de propiedad-valor expresado como una clase (por ejemplo, .d-block representa display: block;). Su principal atractivo es la rapidez de uso al escribir HTML y limitar la cantidad de CSS personalizado que tienes que escribir.

Específicamente con respecto al CSS personalizado, las utilidades pueden ayudar a combatir el aumento del tamaño del archivo al reducir los pares de propiedad-valor más repetidos en clases individuales. Esto puede tener un efecto dramático a gran 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 individuales en nuestros selectores de CSS y tratamos de evitar los selectores de hijos inmediatos (>). Esto te brinda 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 todo Bootstrap. Especifica pautas para formato general, valores predeterminados de sentido común, orden de propiedades y atributos, y más.

Usamos Stylelint para hacer cumplir 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 hacer cumplir el HTML estándar y semántico, así como para detectar errores comunes.