Reducción de la metodología BEM para proyectos pequeños

 

 

 

  • SmashingConf Nueva York 2024
  • ¡Registro!

  • Índice
    1. BEM 101
      1. Bloques
      2. Elementos
      3. Modificadores
      4. Bloques y el DOM
      5. El árbol BEM
    2. Dar el primer paso
    3. Deje que su CSS hable en voz alta
      1. Convenciones de nomenclatura BEM para CSS
    4. Por qué elegir BEM CSS sobre otros enfoques
      1. Una clase para gobernarlos a todos
      2. Problemas de especificidad resueltos
      3. ¡¿Adiós cascada?!
      4. Bloques absolutamente independientes
    5. Convenciones de nomenclatura BEM alternativas
    6. JavaScript semántico: código orientado a BEM
      1. Aprendiendo a declarar
      2. Métodos
      3. “… Sentado en un árbol (BEM)”
      4. Modificar modificadores para controlar controles
      5. Código orientado a BEM explicado
    7. De una convención de nomenclatura a una guía de estilo

    Para tomar las decisiones correctas para su proyecto, debe comenzar con un enfoque o metodología general. Probablemente ya conozcas BEM, una de esas metodologías desarrolladas por una gran empresa, pero Maxim Shirshin decidió probar BEM a menor escala. Quería los mismos beneficios que Yandex obtiene de BEM: código compartido, una guía de estilo en vivo, escalabilidad y desarrollo más rápido. Ahora está convencido de que BEM también se aplica a proyectos pequeños. Maxim ha escrito sus hallazgos, por si los encuentras útiles.

     

    El desarrollo front-end ya no se trata de marcos individuales. Las herramientas están disponibles; simplemente tenemos que elegir. Para tomar las decisiones correctas para su proyecto, debe comenzar con un enfoque o metodología general . ¿Pero la mayoría de las metodologías han sido creadas por grandes empresas? ¿Siguen siendo útiles para las pequeñas empresas o necesitamos reinventarlos a pequeña escala?

    Probablemente ya conozca BEM , una de esas metodologías desarrolladas por una gran empresa: Yandex . BEM postula que tres entidades básicas ( bloques , elementos y modificadores ) son suficientes para definir cómo crear HTML y CSS, estructurar código y componentes, describir interfaces y escalar un proyecto hasta convertirlo en un servicio líder en la industria.

    Pasé algún tiempo con Yandex y BEM y sé que esta metodología funciona para proyectos grandes. Yandex utiliza BEM para desarrollar componentes CSS y JavaScript; Yandex también optimiza plantillas y rastrea dependencias en BEM, desarrolla utilidades BEM, admite experimentos de código e investiga el campo. A gran escala, esta inversión vale la pena y permite a Yandex desarrollar cientos de sus servicios más rápidamente.

    ¿Se beneficiarían los equipos más pequeños de BEM? No estaba seguro. BEM es una capa de abstracción que se ofrece con otras herramientas y tecnologías. Un equipo pequeño y ágil que cambie a una pila BEM completa sería cuestionable. ¿Podría ser útil la idea (el enfoque en sí)?

    Tuve que reconsiderar esta pregunta cuando mi carrera recientemente me llevó de Yandex a Deltamethod, una startup de tamaño mediano en Berlín. Ante ambiciosos planes de desarrollo, decidimos probar BEM a menor escala. Queríamos los mismos beneficios que Yandex obtiene de BEM: código compartido, una guía de estilo en vivo, escalabilidad y desarrollo más rápido. También queríamos mantener nuestra cadena de herramientas y actualizar la base de código existente gradualmente, en lugar de empezar desde cero.

    Durante algún tiempo, nos hemos centrado en la arquitectura y los conceptos básicos, probando aspectos de BEM uno por uno, evaluando los resultados y luego avanzando. Seguimos anotando ideas, pautas, consejos útiles y breves tutoriales. Ahora estoy convencido de que BEM también se aplica a proyectos pequeños. He anotado mis hallazgos, por si los encuentras útiles. Empecemos repasando lo básico.

    BEM 101

    Si bien la semántica se considera la base del desarrollo web, varias tecnologías front-end no comparten el mismo modelo semántico. El HTML de una aplicación moderna es principalmente una sopa div. CSS por sí solo no ofrece ningún modelo estructurado. Los componentes de JavaScript de alto nivel utilizan abstracciones que no están vinculadas sistemáticamente a estilos o marcas. A nivel de UX, las interfaces se describen en términos que no tienen nada en común con las implementaciones técnicas. Ingrese BEM, un modelo semántico unificado para marcado, estilos, código y UX. Miremos más de cerca.

    Bloques

    Un bloque es una entidad independiente con su propio significado que representa una parte de la interfaz en una página.

    Ejemplos de bloques incluyen:

    • un título,
    • un botón,
    • un menú de navegación.

    Para definir un bloque, le daría un nombre único y especificaría su semántica. Pueden existir varias instancias de la misma definición de bloque (como varios botones o múltiples menús) en la interfaz.

    Cualquier interfaz web se puede representar como una colección jerárquica de bloques. La representación más simple es la propia estructura HTML (etiquetas como bloques), pero es semánticamente inútil porque HTML fue diseñado para texto estructurado, no para aplicaciones web.

    Elementos

    Un elemento es parte de un bloque , vinculado a él semántica y funcionalmente. No tiene significado fuera del bloque al que pertenece. No todos los bloques tienen elementos.

    Ejemplos de elementos incluyen:

    • un menú de navegación (bloque) que contiene elementos de menú;
    • una tabla (bloque) que contiene filas, celdas y encabezados.

    Los elementos también tienen nombres y elementos similares dentro de un bloque (como celdas en una cuadrícula o elementos en una lista) tienen el mismo nombre. Los elementos son entidades semánticas y no son exactamente iguales al diseño HTML; una estructura HTML compleja podría constituir un solo elemento.

    Modificadores

    Los modificadores son banderas colocadas en bloques o elementos; definen propiedades o estados. Pueden ser booleanos (por ejemplo, visible: trueo false) o pares clave-valor ( size: large, medium, small), algo similares a los atributos HTML, pero no exactamente iguales. Se permiten varios modificadores en un solo elemento si representan propiedades diferentes.

    Bloques y el DOM

    ¿Cómo se trabaja con BEM sin dejar de utilizar HTML? Lo hace asignando nodos DOM a entidades BEM utilizando una convención de nomenclatura.

    BEM utiliza nombres de clases CSS para indicar bloques, elementos y modificadores. Los bloques, elementos o modificadores no pueden reclamar ninguna "propiedad exclusiva" de los nodos DOM. Un nodo DOM puede albergar varios bloques. Un nodo puede ser un elemento dentro de un bloque y (al mismo tiempo) un contenedor para otro bloque.

     

    Un nodo DOM que se reutiliza para alojar más de una entidad BEM se denomina "mixin BEM". Tenga en cuenta que esto es solo una característica de conveniencia: combine solo cosas que se puedan combinar, no convierta una mezcla en un desastre.

    El árbol BEM

    Al marcar consistentemente un documento con entidades BEM, desde el bloque raíz (es decir, bodyo incluso html) hasta los bloques más internos, se forma una superposición semántica de la estructura existente del DOM. Esta superposición se llama árbol BEM.

    El árbol BEM le brinda el poder de manipular todo el documento en términos BEM de manera consistente, centrándose en la semántica y no en una implementación específica de DOM.

    Dar el primer paso

    Quizás esté pensando: “Probaré BEM. ¿Cómo empiezo a migrar mi proyecto a BEM? ¿Puedo hacerlo de forma incremental? Seguro. Comencemos definiendo algunos bloques. Sólo cubriremos la semántica; Más adelante procederemos con tecnologías específicas (como CSS y JavaScript).

    Como recordará, cualquier cosa independiente puede ser un bloque. Por ejemplo, los títulos de los documentos son bloques. No tienen elementos internos, pero sus niveles (desde el más alto hasta el más interno) pueden definirse como modificadores clave-valor.

    Si necesita más niveles más adelante, defina más modificadores. Yo diría que HTML4 se equivocó con h1to h6. Hizo diferentes bloques (etiquetas) de lo que debería haber sido solo una propiedad modificadora. HTML5 intenta remediar esto con elementos de sección, pero la compatibilidad con el navegador está retrasada.

    Por ejemplo, obtenemos esto:

    BLOCK headingMOD level: alpha, beta, gamma

    Como segundo ejemplo, los controles de entrada de formularios web pueden verse como bloques (incluidos botones). HTML tampoco lo entendió exactamente aquí. Esta vez, se combinaron diferentes cosas (entradas de texto, botones de opción, casillas de verificación) bajo la misma inputetiqueta, mientras que otras (aparentemente del mismo origen) se definieron con etiquetas separadas ( selecty textarea). Otras cosas, como labely la autosugerencia datalist, deberían ser elementos (opcionales) de estos bloques porque tienen poco o ningún significado por sí solos.

    Veamos si podemos solucionar esto:

    BLOCK text-inputMOD multilineMOD disabled ELEMENT text-field ELEMENT label

    La característica esencial de una entrada de texto es su capacidad para aceptar texto sin formato. Cuando necesitamos que sea de varias líneas, nada cambia semánticamente; por eso multilinees solo un modificador. A nivel HTML, esto se representa mediante un marcado diferente por razones técnicas, lo cual también está bien porque solo estamos definiendo la semántica, no la implementación. La textfieldetiqueta en sí es un elemento y labeles un elemento más; Más adelante, es posible que necesitemos otros elementos, como un icono de estado, un marcador de posición de mensaje de error o una sugerencia automática.

    BLOCK checkbox ELEMENT tick-box ELEMENT label
    BLOCK radio ELEMENT radio-button ELEMENT label

    Estos dos bloques son bastante sencillos. Aún así, labeles un elemento, y inputlas etiquetas "nativas" también son elementos.

     

    BLOCK selectMOD disabledMOD multiple ELEMENT optgroup ELEMENT option MOD disabled MOD selected

    Los cuadros de selección realmente no necesitan etiquetas, y cualquier otra cosa aquí es más o menos similar a un control de cuadro de selección normal. Técnicamente, podemos reutilizar la selectetiqueta existente con toda su estructura. Tenga en cuenta que tanto el selectbloque como su optionelemento tienen un disabledmodificador. Estos son diferentes modificadores: el primero deshabilita todo el control, mientras que el segundo (siendo un ejemplo perfecto de un modificador de elemento) deshabilita solo un individuo option.

    Intente encontrar más ejemplos de bloques en sus proyectos web. Clasificar cosas según BEM requiere algo de práctica. ¡No dudes en compartir tus hallazgos o hacer tus preguntas al equipo de BEM !

    Deje que su CSS hable en voz alta

    Quizás haya oído hablar mucho de BEM como una forma de optimizar CSS y se pregunte cómo funciona.

    Como se mencionó, BEM usa nombres de clases CSS para almacenar información sobre bloques, elementos y modificadores. Con una convención de nomenclatura simple, BEM le enseña a su CSS a hablar y le agrega significado que lo hace más simple, más rápido, más escalable y más fácil de mantener.

    Convenciones de nomenclatura BEM para CSS

    Estos son los requisitos previos:

    • Mantenga los nombres de bloques, elementos y modificadores breves y semánticos.
    • Utilice únicamente letras, guiones y dígitos latinos.
    • No utilice guiones bajos ( _), que están reservados como caracteres “separadores”.

    Los contenedores de bloques obtienen una clase CSS de un prefijo y un nombre de bloque:

    .b-heading.b-text-input

    Ese b-prefijo significa "bloque" y es el predeterminado en muchas implementaciones de BEM. Puedes usar el tuyo propio, pero sé breve. Los prefijos son opcionales, pero emulan espacios de nombres CSS muy esperados (¡y faltantes!).

    Los contenedores de elementos dentro de un bloque obtienen clases CSS que consisten en su clase de bloque, dos guiones bajos y el nombre del elemento:

    .b-text-input__label.b-text-input__text-field

    Los nombres de los elementos no reflejan la estructura del bloque. Independientemente de los niveles anidados internos, siempre es solo el nombre del bloque y el nombre del elemento (por lo tanto, nunca )..b-blockelem1elem2

    Los modificadores pertenecen a un bloque o un elemento. Su clase CSS es el nombre de clase de su "propietario", un guión bajo y un nombre de modificador:

    .b-text-input_disabled.b-select__option_selected

    Para un modificador "booleano", esto es suficiente. Sin embargo, algunos modificadores son pares clave-valor con más de un valor posible. Utilice otro guión bajo para separar los valores:

    .b-heading_level_alpha

    Las clases modificadoras se usan junto con las clases de bloque y elemento, así:

    divBEM/div

    Por qué elegir BEM CSS sobre otros enfoques

    Una clase para gobernarlos a todos

    El CSS a veces depende mucho de la estructura del documento: si cambias la estructura, rompes el CSS. Con BEM, puede eliminar completamente los nombres de etiquetas y los ID de su CSS, utilizando solo nombres de clases. Básicamente, esto lo libera de dependencias estructurales. Cómo Localizar un Celular Móvil [ Contenido Actualizado Mayo del 2024 ]

     

    Problemas de especificidad resueltos

    Grandes porciones de CSS son difíciles de mantener porque se redefinen a sí mismas de manera impredecible.

    Este problema se llama especificidad de CSS. El problema original es que tanto los nombres de etiquetas como los ID de elementos cambian la especificidad del selector de tal manera que si confía en la herencia (lo más común que se puede esperar de CSS), entonces solo puede anularla con selectores de la misma o mayor especificidad. Los proyectos BEM son los menos afectados por este problema. Veamos por qué.

    Digamos que tienes una tabla con estas reglas de estilo:

    td.data { background-color: white }td.summary { background-color: yellow }

    Sin embargo, en otro componente, es necesario redefinir el fondo de una celda en particular:

    .final-summary { background-color: green }

    Esto no funcionaría porque tag.classsiempre tiene una especificidad mayor que simplemente .class.

    Agregaría un nombre de etiqueta a la regla para que funcione:

    td.final-summary { background-color: green }

    Debido a que BEM proporciona nombres de clase únicos para la mayoría de los estilos, usted dependerá únicamente del orden de las reglas.

    ¡¿Adiós cascada?!

    Los selectores de CSS anidados no son lo suficientemente rápidos en los navegadores antiguos y pueden crear anulaciones no deseadas que rompan los estilos de otros elementos. Es posible eliminar gran parte de la cascada de CSS con BEM. ¿Cómo es esto posible y por qué es importante? ¿ No se supone que la cascada debería estar ahí? ¿No es la “C” en CSS)?

    Como sabes, cada clase de CSS de BEM es única y autosuficiente . No depende de etiquetas o ID, y diferentes bloques nunca comparten nombres de clases. Es por eso que solo necesita un selector de nombre de clase único para hacer lo siguiente:

    • diseñar un contenedor de bloques,
    • diseñar cualquier elemento de bloque,
    • agregue extras de estilo y anulaciones con un modificador.

    Esto cubre la mayoría de tus necesidades de estilo, todo con un solo selector de clase . Entonces, ahora se trata principalmente de selectores de una sola clase, y son extremadamente rápidos. Para aplicar un selector, el navegador comienza con un conjunto inicial (más amplio) de elementos (generalmente determinado por la parte más a la derecha de un selector) y luego reduce gradualmente el conjunto aplicando otras partes hasta que solo quedan elementos coincidentes. Cuantos más pasos se necesiten, más tiempo llevará, por lo que difícilmente podrás superar a los selectores de una sola clase en cuanto a velocidad.

    CSS rara vez supone un cuello de botella en el rendimiento en páginas pequeñas, pero las reglas de CSS deben volver a aplicarse con cada reflujo de documento. Entonces, cuando tu proyecto crezca, las cosas se volverán más lentas en algún momento. Según la ciencia de la usabilidad, 250 milisegundos es el límite de percepción del "instante". Cuanto más rápidos sean tus selectores, más espacio tendrás para maniobrar para mantener esa sensación de "increíble velocidad" para tus usuarios.

     

    Entonces, ¿no hay cascada? Bueno, casi. En algunos casos, es posible que necesites dos nombres de clase en un selector; por ejemplo, cuando un modificador de bloque afecta a elementos individuales:

    .b-text-input_disabled .b-text-input__label { display: none;}

    Lo bueno es que cualquier regla que redefina ésta probablemente dependerá de otro modificador (¡debido a la semántica unificada!), lo que significa que la especificidad sigue siendo la misma y solo importa el orden de la regla. Seguramente, podemos inventar más casos que requieran aún más cascada (dependencias de elementos internos, modificadores anidados, etc.). Si bien la metodología BEM permite esto, casi nunca la necesitarás en código real.

    Bloques absolutamente independientes

    Si los bloques dependen de los estilos de cada uno, ¿cómo lo expresamos en CSS? La respuesta es que no deberían hacerlo. Cada bloque debe contener todos los estilos necesarios para su presentación. La sobrecarga es mínima, pero esto garantiza que puedas mover bloques libremente dentro de una página o incluso entre proyectos sin dependencias adicionales. Evite los restablecimientos de CSS en todo el proyecto por el mismo motivo.

    Este no es el caso de los elementos porque se garantiza que permanecerán dentro de su bloque principal y, por lo tanto, heredarán los estilos de bloque en consecuencia.

    Convenciones de nomenclatura BEM alternativas

    Existen varias convenciones de nomenclatura BEM alternativas. ¿Cuál deberíamos utilizar? La convención de nomenclatura "oficial" de BEM para CSS no es la única posible. Nicolas Gallagher propuso una vez algunas mejoras, y otros adoptantes también lo han hecho. Una idea es utilizar atributos para representar modificadores, y los prefijos CSS no están "estandarizados" en absoluto.

    La mayor ventaja de la sintaxis propuesta por el equipo detrás de BEM es que es la que se admite en las herramientas de código abierto distribuidas por Yandex, lo que puede resultarle útil en algún momento. Al final, lo que importa es la metodología, no la convención de nomenclatura; Si decide utilizar una convención diferente, asegúrese de hacerlo por una razón.

    JavaScript semántico: código orientado a BEM

    Muchos editores y autores ven a BEM como una convención de nomenclatura sólo para CSS, pero eso aporta sólo la mitad de los beneficios a un proyecto. La metodología BEM fue diseñada para arreglar (es decir, polyfill) estructuras DOM no semánticas en todos los niveles (HTML, CSS, JavaScript, plantillas y diseño UX), de manera similar a cómo jQuery “arregla” las API DOM rotas. HTML fue diseñado como un lenguaje de marcado de texto, pero lo usamos para crear las interfaces más interactivas que existen. Los esfuerzos experimentales, como los componentes web, se esfuerzan por devolver la semántica a nuestro marcado y código, pero BEM se puede usar ahora en una amplia gama de navegadores, manteniendo la compatibilidad con enfoques futuros, porque no depende de ninguna API o biblioteca en particular.

     

    ¿Cómo se aplica el modelo BEM al código JavaScript? Revisaremos un paradigma de desarrollo utilizando la menor cantidad de código posible. Será muy abstracto y de alto nivel, pero la abstracción nos ayudará a comprender la idea más claramente. Notarás otro término en el título anterior: "código orientado a BEM". Antes de explicar qué hay detrás de esto, repasemos algunas ideas que es útil conocer al aplicar BEM a JavaScript.

    Aprendiendo a declarar

    El primer paso es adoptar un paradigma declarativo. La programación declarativa es un enfoque que se concentra en el "qué", no en el "cómo". Las expresiones regulares, SQL y XSLT son todas declarativas y no especifican el flujo de control, sino la lógica detrás de él. Al realizar programación declarativa, comenzaría describiendo un conjunto de condiciones, cada una de ellas asignada a acciones específicas.

    En BEM, las condiciones están representadas por modificadores y cualquier acción solo puede ocurrir en un bloque o elemento . Los ejemplos de código de este artículo utilizarán el i-bem.jsmarco, escrito y de código abierto por Yandex, pero su marco favorito podría hacer cosas similares o mejores porque la programación declarativa no está vinculada a una implementación específica.

    BEM.DOM.decl('b-dropdown', { onSetMod: { disabled: function(modName, modVal) { this.getLabel().setMod('hidden', 'yes'); if (modVal === 'yes') { this.getPopup().hide(); } }, open: { yes: function() { this.populateList(); } } }, /* … */

    El fragmento de código anterior define acciones para dos modificadores en un b-dropdownbloque. Son similares a los controladores de eventos, pero todos los estados se reflejan inmediatamente en el CSS. Los modificadores todavía se almacenan como nombres de clase en las entidades de bloque y elemento correspondientes.

    Habilitar y deshabilitar diferentes combinaciones de teclas en un b-editorbloque es otro ejemplo de cómo usar modificadores:

    BEM.DOM.decl('b-editor', { onSetMod: { hotkeys: { windows: function() { this.delMod('theme'); this.loadKeyMap('windows'); }, emacs: function() { this.setMod('theme', 'unix'); this.loadKeyMap('emacs'); enableEasterEgg(); } } }, onDelMod: { hotkeys: function() { this.clearKeyMaps(); this.delMod('theme'); } } /* … */

    En este ejemplo, vemos cómo los modificadores aportan lógica a nuestras transiciones de estado.

    Métodos

    Con un enfoque declarativo, los métodos no siempre están "vinculados" a un componente automáticamente. En cambio, también se puede declarar que pertenecen a algunas instancias en determinadas circunstancias:

    BEM.DOM.decl({ name : 'b-popup', modName : 'type', modVal : 'inplace' }, { appear: function() { // makeYouHappy(); }});

    Este método se define solo para bloques que tienen el typemodificador específico: inplace.

    Al igual que en la programación clásica orientada a objetos, puede ampliar los métodos definidos semánticamente proporcionando declaraciones aún más específicas y reutilizar el código original si es necesario. Por lo tanto, son posibles tanto anulaciones como extensiones. Por ejemplo:

     

    BEM.DOM.decl({'name': 'b-link', 'modName': 'pseudo', 'modVal': 'yes'}, { _onClick : function() { // runs the basic _onClick defined // for all b-link instances this.__base.apply(this, arguments); // redefine the appearance from within CSS, // this code only gives you a semantic basis! this.setMod('status', 'clicked'); }});

    Como se especifica en esta definición, el _onClickmétodo extendido se ejecuta solo en b-linkinstancias con un _pseudo_yesmodificador. En todos los demás casos, se implementa el método "original".

    La semántica migrará lentamente de su marcado (donde ya no es necesario) a su código (donde admite modularidad y legibilidad, lo que facilita el trabajo).

    “… Sentado en un árbol (BEM)”

    ¿Cuál es el uso práctico de un enfoque declarativo si es demasiado abstracto? La idea es trabajar con un árbol BEM, que es semántico y controlado por usted, en lugar de un árbol DOM, que está vinculado al marcado y los detalles específicos de la implementación:

    BEM.DOM.decl('b-checkbox-example', { onSetMod: { js: { inited: function() { var checkbox = this.findBlockInside({ blockName: 'b-form-checkbox', modName: 'type', modVal: 'my-checkbox' }); this.domElem.append('Checkbox value: ' + checkbox.val()); } } }});

    Existen otras API, como this.elem(‘name’)y this.findBlockOutside(‘b-block’). En lugar de proporcionar una referencia completa, simplemente resaltaría los árboles BEM como base de la API.

    Modificar modificadores para controlar controles

    La sección anterior deja sin abordar el importante tema de los cambios de estado de la aplicación. Cuando se declaran los estados de la aplicación, necesita una forma de realizar transiciones. Esto debe hacerse operando en un árbol BEM, con la ayuda de modificadores. Los modificadores BEM se pueden configurar directamente en los nodos DOM (como nombres de clases), pero no podemos monitorearlo de manera efectiva (por razones técnicas). En su lugar, i-bem.jsproporciona una API simple que puede usar como inspiración:

    // setterthis.setMod(modName, modVal);// getterthis.getMod(modName);// check for presencethis.hasMod(modName, modVal);// togglethis.toggleMod(modName, modVal);// remove modifierthis.delMod(modName);

    Por lo tanto, podemos conectar internamente la llamada de cambio del modificador y ejecutar todas las acciones especificadas para este caso particular.

    Código orientado a BEM explicado

    Muchas bibliotecas de JavaScript proporcionan suficiente potencia para admitir la metodología BEM sin introducir una cadena de herramientas completamente nueva. Aquí hay una lista de verificación para ver si el que estás viendo lo hace:

    • Adopta un enfoque declarativo
    • Define su sitio web o aplicación en términos de BEM. ¿Se pueden “asignar” muchas de las entidades existentes del proyecto a bloques, elementos y propiedades modificadoras?
    • Le permite colocar el árbol DOM para el árbol BEM . Independientemente de cualquier API de marco en particular, elimine la mayor cantidad posible de interacción DOM sin procesar, reemplazándola con la interacción de árbol de BEM. Durante este proceso, algunos de los nodos con los que trabaja se redefinirán como bloques o elementos; nómbrelos y vea cómo se revela la verdadera estructura semántica de su aplicación.
    • Utiliza modificadores para trabajar con transiciones de estado . Obviamente, no deberías definir todos los estados con modificadores. Comience con los que se pueden expresar en CSS (para ocultar y revelar elementos, cambiar el estilo según los estados, etc.) y limpie su código de cualquier manipulación directa del estilo.

    Si el marco de su elección puede hacer esto, entonces ya está listo para el código orientado a BEM.

     

    Los usuarios de jQuery pueden probar estos complementos livianos para ampliar su código con métodos BEM:

    • Complemento jQuery BEM
    • Ayudantes de jQuery BEM ( setMody getMod)

    De una convención de nomenclatura a una guía de estilo

    Si trabaja mucho con diseñadores, su equipo también se beneficiaría de un enfoque BEM. Imagina que tienes una guía de estilo creada por un Real Designer™. Por lo general, lo obtendrá como un archivo PDF y podrá aprender todo sobre los tipos de letra, combinaciones de colores, principios de interacción de la interfaz, etc. Sirve perfectamente como un libro gráfico interesante para mirar en tu tiempo libre. Sin embargo, sería de poca o ninguna utilidad para la mayoría de los desarrolladores de aplicaciones para el usuario: a nivel de código, los desarrolladores de aplicaciones para el usuario operan con entidades totalmente diferentes.

    Pero, ¿qué pasaría si usted y el diseñador pudieran hablar entre sí utilizando el mismo idioma? Por supuesto, esto requeriría algo de formación, pero los beneficios merecen la pena. Su guía de estilo sería una biblioteca de bloques interactiva, expresada en términos BEM. Una biblioteca de este tipo consistiría en bloques que están listos para usarse para construir su producto.

    Una vez que el diseñador esté familiarizado con los términos de BEM, puede iterar hacia el diseño de bloques y elementos, en lugar de "pantallas". Esto también les ayudará a identificar partes similares de la interfaz de usuario y unificarlas. Los modificadores ayudan a definir variaciones visuales (es decir, que se aplican a todos los bloques) y estados (es decir, sólo para bloques interactivos). Los bloques serían lo suficientemente granulares como para permitirle realizar una estimación temprana de la cantidad de trabajo que debe realizarse. El resultado es una especificación que cubre completamente todos los estados importantes que se pueden reutilizar con otras pantallas o páginas.

    Esto eventualmente le permitirá simular interfaces como esquemas o bocetos, porque todos los bloques de construcción ya han sido definidos. Más importante aún, este modelo se asigna directamente a la base del código, porque los bloques, elementos y modificadores definidos por el diseñador son esencialmente los mismos bloques, elementos y modificadores






    Tal vez te puede interesar:

    1. ¿Deberían abrirse los enlaces en ventanas nuevas?
    2. 24 excelentes tutoriales de AJAX
    3. 70 técnicas nuevas y útiles de AJAX y JavaScript
    4. Más de 45 excelentes recursos y repositorios de fragmentos de código

    Reducción de la metodología BEM para proyectos pequeños

    Reducción de la metodología BEM para proyectos pequeños

    SmashingConf Nueva York 2024 ¡Registro! Índice BEM 101

    programar

    es

    https://aprendeprogramando.es/static/images/programar-reduccion-de-la-metodologia-bem-para-proyectos-pequenos-853-0.jpg

    2024-05-20

     

    Reducción de la metodología BEM para proyectos pequeños
    Reducción de la metodología BEM para proyectos pequeños

    Si crees que alguno de los contenidos (texto, imagenes o multimedia) en esta página infringe tus derechos relativos a propiedad intelectual, marcas registradas o cualquier otro de tus derechos, por favor ponte en contacto con nosotros en el mail [email protected] y retiraremos este contenido inmediatamente

     

     

    Top 20