La evolución de la metodología BEM

 

 

 

  • Creación y mantenimiento de sistemas de diseño exitosos, con Brad Fost
  • Anuncie en la revista Smashing

  • Índice
    1. …Donde todo comenzo
      1. Proyectos de mediana escala
      2. Bloques al rescate
      3. ¿Qué hay adentro?
      4. La estructura de archivos del proyecto evoluciona
    2. Construyendo un marco: el comienzo
    3. Bloques independientes como concepto
      1. Bloques: Declaración de Independencia
      2. Bloques simples y compuestos: la clasificación errónea
      3. Bloques completamente independientes
      4. Prefijos
      5. Modificadores
    4. Un marco unificado para todo el portal
      1. Estructura del repositorio del marco: primer enfoque
      2. Archivos por página
    5. Marco de todo el portal: Lego 1.2 (2008)
    6. BEM, Est. 2009
      1. Lego 2.0 en 2009
      2. Extractos de terminología
      3. Declaraciones en XML

    En este artículo, Maxim Shirshin nos presentará la historia de la metodología BEM. BEM es una colección de ideas y métodos. Las empresas y los equipos pueden integrarlo gradualmente en su flujo de trabajo existente, descubriendo qué funciona mejor para ellos, utilizando un lenguaje unificado que consta de términos poderosos: bloques, elementos, modificadores. Conozca los desafíos que enfrenta una gran empresa al construir gradualmente un ecosistema completo de servicios con un equipo de desarrolladores en constante crecimiento.

     

    Este artículo es un estudio de caso sobre la evolución de BEM , una metodología que permite a los miembros del equipo colaborar y comunicar ideas utilizando un lenguaje unificado que consta de términos simples pero poderosos: bloques, elementos, modificadores. Conozca los desafíos que enfrenta una gran empresa al construir gradualmente un ecosistema completo de servicios con un equipo de desarrolladores en constante crecimiento.

    Érase una vez, en un país muy lejano, una empresa de TI llamada Yandex comenzó a desarrollar búsquedas web y servicios relacionados. Pasó el tiempo y sus servicios crecieron, y cada vez más desarrolladores front-end pusieron esfuerzos incansables para mejorar el ecosistema de Yandex. Hicieron grandes cosas y crearon herramientas asombrosas que facilitaron la vida de sus desarrolladores, y ahora ha llegado el momento de compartir ese conocimiento con la comunidad , para liberar el poder mágico del código abierto en beneficio de todas las buenas personas.

    Los desarrolladores front-end son bien conocidos por su insaciable curiosidad, que a menudo se traduce en innovación, así como por su notable pereza, que les lleva a idear sistemas sofisticados para ahorrar un tiempo precioso y unificarlo y automatizarlo todo.

    Viajemos en el tiempo hasta 2005 y echemos un vistazo por encima del hombro de un desarrollador front-end de Yandex muy, muy ocupado y así veamos...

    …Donde todo comenzo

    En 2005, la atención se centraba todavía en el lado del servidor. Desde la perspectiva del front-end, un proyecto típico de Yandex era un conjunto de páginas HTML estáticas utilizadas como referencia base para crear plantillas avanzadas como hojas de estilo XSL. Estas páginas se guardaron en una carpeta separada que se veía así después de pagar:

    about.htmlindex.html…project.cssproject.jsi/ yandex.png

    Había un archivo HTML estático para cada página, con todo el CSS insertado en una sola hoja de estilo project.cssy todo el JavaScript colocado en un solo project.jsarchivo, con ambos archivos compartidos entre todas las páginas del proyecto. En 2005, JavaScript se aplicaba escasamente, por lo que toda la magia de la interacción cabía cómodamente en un archivo pequeño. Las imágenes residían en una carpeta separada porque eran numerosas. Con IE 5 en libertad y sin CSS3, las imágenes se usaban para todo tipo de atractivos visuales, incluso para esquinas redondeadas (ninguno de ustedes, desarrolladores web más jóvenes, probablemente me creería).

     

    Para conservar la estructura básica, las definiciones de estilo para diferentes secciones de la página se separaron mediante comentarios CSS simples :

    /* Content container (begin) */ #body { font: 0.8em Arial, sans-serif; margin: 0.5em 1.95% 0.5em 2%; }/* Content container (end) *//* Graphical banner (begin) */ .banner { text-align: center; } .banner a { text-decoration: none; }/* Graphical banner (end) */

    En el marcado HTML se utilizaron tanto ID como nombres de clases.

    Se pegaron manualmente fragmentos de HTML en hojas de estilo XSL de producción y todos los cambios se sincronizaron en dos direcciones, manualmente . Eso fue difícil, y cuando no lo fue, fue aburrido.

    Proyectos de mediana escala

    A principios de 2006, la primera versión de Yandex.Music estaba en pleno desarrollo. Varias páginas, cada una diferente de las demás, no encajaban bien en conceptos simplistas familiares. Docenas de clases CSS para las que había que inventar nombres significativos, un número creciente de dependencias no intencionales que se extendían por todo el proyecto: todo esto requería una mejor solución .

    Aquí hay un fragmento típico de código CSS de aquellos días:

    /* Albums (begin) */ .result .albums .info { padding-right: 8.5em; } .result .albums .title { float: left; padding-bottom: 0.3em; } .result .albums .album .listen { float: left; padding: 0.3em 1em 0 1em; } .result .albums .album .buy { float: left; padding: 0.4em 1em 0 1.6em; } .result .albums .info i { font-size: 85%; }/* Albums (end) */

    Se utilizaron largas reglas en cascada en todo el código.

    Echa un vistazo a otro:

    /* Background images (begin) */ .b-foot div { height: 71px; background: transparent url(../i/foot-1.png) 4% 50% no-repeat; } .b-foot div div { background-position: 21%; background-image: url(../i/foot-2.png); } .b-foot div div div { background-position: 38%; background-image: url(../i/foot-3.png); } .b-foot div div div div { background-position: 54%; background-image: url(../i/foot-4.png); } .b-foot div div div div div { background-position: 71%; background-image: url(../i/foot-5.png); } .b-foot div div div div div div { background-position: 87%; background-image: url(../i/foot-6.png); }/* Background images (end) */

    Tenga en cuenta que en muchas reglas se utilizaron selectores de ID y nombre de etiqueta.

    Al mismo tiempo, se estaba iniciando un proyecto aún mayor, wow.ya.ru: una plataforma de blogs, un lugar para que la gente interactúe, comparta, lea y participe.

    Había docenas de páginas diferentes para apoyar. Y con el enfoque anticuado, el código estaba perdiendo control en muchos niveles.

    Bloques al rescate

    Necesitábamos especificar un dominio de datos para administrar los objetos de la interfaz de la página. Esta era una cuestión de metodología : necesitábamos aclarar la forma en que trabajábamos con conceptos como clases, etiquetas, componentes visuales, etc.

     

    Para una página web típica en un proyecto Yandex, la estructura HTML y sus estilos CSS seguían siendo el foco de nuestros esfuerzos de desarrollo, siendo JavaScript una tecnología complementaria. Para poder mantener más fácilmente el HTML y CSS de muchos componentes, se ideó un nuevo término: “bloquear”. Un bloque era parte de un diseño de página cuyo significado específico y único se definía semántica o visualmente.

    En la mayoría de los casos, cualquier elemento de página distinto (ya sea complejo o simple) podría considerarse un bloque. Su contenedor HTML obtuvo una clase CSS única, que también se convirtió en un nombre de bloque.

    Las clases CSS para bloques tienen prefijos ( b-,, ) para proporcionar una especie de emulación de espacio de nombres en CSS c-. g-La convención de nomenclatura en sí se cambió más tarde, pero aquí está la lista inicial, anotada:

    • b-(bloque) Un bloque independiente, colocado en una página donde lo necesites.
    • с-(control) Un control (es decir, un bloque independiente), con un objeto JavaScript vinculado a él.
    • g-(global) Una definición global, utilizada con moderación y siempre definida para un propósito específico y único. El número de estas definiciones se mantuvo al mínimo.

    También se emplearon algunos sufijos, como:

    • -nojs(sin JavaScript) Una regla de estilo que se aplicará con JavaScript desactivado. Una onloaddevolución de llamada podría eliminar estos sufijos de todos los nodos DOM, marcándolos semánticamente como "habilitados para JavaScript".

    ¿Qué hay adentro?

    En un contenedor HTML que contiene un bloque, algunos de los nodos internos tenían clases CSS distintas. Esto no solo facilitó la creación de reglas de estilo independientes del nombre de la etiqueta, sino que también asignó roles semánticamente significativos a cada nodo. Dichos nodos eran "elementos de bloque" o simplemente "elementos".

    La distinción principal entre un bloque y un elemento es la incapacidad de un elemento de existir fuera del contexto de su bloque principal. Si algo no se podía desprender de un bloque, era un elemento; Los elementos desmontables (probablemente) deberían ser ellos mismos bloques.

    Al principio, un elemento sólo podía existir en un contenedor de bloques. Posteriormente, se ideó una técnica para colocar algunos elementos en el exterior y mantener la consistencia del bloque.

    En las hojas de estilo, los elementos con mucho CSS obtuvieron sangría adicional y se incluyeron en comentarios:

    /* Head (begin) */.b-head { … } /* Logo (begin) */ .b-head .logo { … } .b-head .logo a { … } /* Logo (end) */ /* Right side (begin) */ .b-head .right { … } /* Info (begin) */ .b-head .info { … } .b-head .info .exit a { … } /* Info (end) */ /* Search (begin) */ .b-head .search { … } .b-head .search div div, .b-head .search div div i { … } /* Search (end) */ /* Right side (end) *//* Head (end) */

    La estructura de archivos del proyecto evoluciona

    En Yandex, un desarrollador front-end suele respaldar más de un proyecto. Cambiar entre diferentes repositorios y varias ramas es más fácil cuando todos los proyectos utilizan la misma (o similar) estructura de archivos. La granularidad es otro requisito porque proporciona más flexibilidad para los sistemas de control de versiones y ayuda a evitar conflictos durante el desarrollo concurrente.

     

    Esto nos llevó a una estructura más unificada: CSS, JavaScript y archivos de imagen residirían en carpetas separadas. En CSS, había archivos dedicados para soluciones alternativas específicas de IE, para mantener el código principal limpio y compatible con los estándares. En producción, IE obtendría su merecido hackeo de CSS a través de comentarios condicionales exclusivos de IE.

    JavaScript se empleaba cada vez más; de ahí la adición de componentes y bibliotecas opcionales.

    A continuación se muestra una estructura de archivo típica:

    index.htmlcss/ yaru.css yaru-ie.cssjs/ yaru.jsi/ yandex.png

    Los hacks específicos de IE podrían haberse incluido en el archivo CSS principal ( yaru.css) si cumplieran con los estándares CSS:

    /* Common definitions (begin) */ body { font-family: Arial, sans-serif; font-size: 0.8em; padding: 0 0 2em 0; background: #fff; } * html body { font-size: 80%; }

    Las soluciones alternativas no válidas se colocaron en un yaru-ie.cssarchivo independiente (cargado con comentarios condicionales solo para IE).

    /* Common blocks (begin) */ /* Artist (begin) */ .b-artist .i i { top: expression(7 + (90 - this.parentNode.getElementsByTagName('img')[0].height)/2); filter:progid:DXImageTransform.Microsoft.AlphaImageLoader(src='../i/sticker-lt.png', sizingMethod='crop'); }

    Construyendo un marco: el comienzo

    Diseñar proyectos similares finalmente significó recrear los mismos bloques una y otra vez. Yandex es un portal y ofrece más de cien servicios que comparten el mismo estilo corporativo, por lo que copiar y pegar sin cuidado no funcionaría a esa escala. Sólo para tener algo con qué empezar, hicimos una pequeña recopilación de componentes reutilizables , conocidos internamente como biblioteca de bloques comunes, o simplemente común.

    Los primeros fragmentos de página que se unificaron fueron el encabezado, el pie de página y algunos elementos tipográficos CSS. Los archivos correspondientes se alojaron en un servidor interno dedicado ( common.cloudkill.yandex.ruen la lista a continuación). Aquellos fueron los primeros días de nuestro marco unificado.

    Los estilos se pueden importar directamente desde ese servidor:

    @import url(https://common.cloudkill.yandex.ru/css/global.css);@import url(https://common.cloudkill.yandex.ru/css/head/common.css);@import url(https://common.cloudkill.yandex.ru/css/static-text.css);@import url(https://common.cloudkill.yandex.ru/css/foot/common-absolute.css);@import url(https://common.cloudkill.yandex.ru/css/foot/common-absolute-4-columns.css);@import url(https://common.cloudkill.yandex.ru/css/list/hlist.css);@import url(https://common.cloudkill.yandex.ru/css/list/hlist-middot.css);@import url(https://common.cloudkill.yandex.ru/css/dropdown/dropdown.css);@import url(https://common.cloudkill.yandex.ru/css/dropdown/dropdown-arrow.css);@import url(slider.css);/* Header (begin) */ /* Service (begin) */ .b-head .service h1 { … } .b-head .service h1, .b-head .service h1 a, .b-head .service h1 b { … }

    ¡Obviamente, eran demasiadas importaciones! Entonces, decidimos precompilar estilos (y, más tarde, archivos JavaScript) antes de la implementación. La compilación reemplazaría @importlas directivas con el contenido real del archivo (un proceso llamado "inlining") y realizaría optimizaciones. Nuestra herramienta de inserción interna evolucionó desde un simple script contenedor hasta un proyecto de código abierto, Borschik . ¡Pruébalo! Todos sobre el antiguo egipto

     

    Bloques independientes como concepto

    En el otoño de 2007, nuestra práctica diaria ya tenía alguna teoría detrás. El concepto de bloques independientes, la idea básica detrás de nuestra comprensión de los diseños HTML y CSS, se presentó en la conferencia ClientSide 2007 en Moscú, Rusia.

    En esa presentación se hizo el primer intento de definir un bloque.

    Bloques: Declaración de Independencia

    En nuestro intento de producir una definición formal (de hecho, semiformal) de bloque, se destacaron los siguientes tres principios:

    1. Sólo se deben utilizar nombres de clases (no ID) para CSS.
    2. El nombre de clase de cada bloque debe tener un espacio de nombres (prefijo).
    3. Cada regla CSS debe pertenecer a un bloque.

    Tan pronto como se eliminaran las identificaciones únicas, se podría usar un bloque en la misma página más de una vez. Esto también permitió que dos o más clases coexistieran en el mismo nodo DOM, lo que resultó bastante útil más adelante.

    Bloques simples y compuestos: la clasificación errónea

    Definimos bloques "simples" como aquellos que no pueden contener otros bloques en ningún lugar del interior. Por otro lado, a los bloques “compuestos” se les permitía (incluso se les exigía) tener bloques anidados.

    Esta clasificación era ingenua. Incluso los bloques más simples a veces estaban envueltos alrededor de otros bloques y tenían que ser "actualizados" y refactorizados para adaptarse a la nueva función. De hecho, esta clasificación errónea resultó contraproducente tantas veces que finalmente aceptamos el principio opuesto: cualquier bloque debe permitir que se incruste contenido arbitrario , siempre que sea posible.

    Bloques completamente independientes

    Las definiciones de CSS no eran infalibles cuando mezclamos una gran cantidad de contenido con estilos provenientes de diferentes fuentes en una sola página. En diseños complejos, los bloques podrían alterar la apariencia de los demás debido a conflictos en los nombres de los elementos. Las reglas CSS basadas en nombres de etiquetas pueden coincidir con más nodos de los previstos. Por lo tanto, se definió una versión más estricta de un bloque independiente (denominado “bloque completamente independiente” o CIB ), con las siguientes reglas agregadas:

     

    1. Nunca haga coincidir CSS con nombres de etiquetas. Utilice nombres de clases para todo..b-user b → .b-user .first-letter
    2. Los nombres de clase para elementos de bloque deben tener el prefijo del nombre del bloque principal..b-user .first-letter → .b-user-first_letter

    Estos nombres de clases tienden a ser mucho más largos y el código HTML resultante era considerablemente más grande.

    Esta fue la razón principal por la que la CIB se consideró una solución costosa, utilizada más como remedio que como práctica cotidiana.

    Prefijos

    Como seguramente sabrá, nombrar variables es uno de los problemas de desarrollo más difíciles que jamás haya existido. Lo abordamos con cautela y se nos ocurrieron cuatro prefijos que se permitirían en los nombres de los bloques, cada uno con su propia semántica.

    • b-Bloques comunes
    • h-Fundas, utilizadas para pegar varios elementos entre sí.
    • l-Cuadrículas de diseño
    • g-Estilos globales

    Modificadores

    Un "modificador" se puede definir como un estado particular de un bloque, una bandera que contiene una propiedad específica.

    Esto se explica mejor con un ejemplo. Un bloque que representa un botón puede tener tres tamaños predeterminados: pequeño, normal y grande. En lugar de crear tres bloques diferentes, asignarías un modificador al bloque. El modificador requeriría un nombre (por ejemplo, size) y un valor ( smallo normal) big.

    Hay dos motivos para que un bloque cambie su estado de presentación:

    1. La presentación de un bloque podría verse alterada debido a su ubicación en el diseño. Esto se denominó modificación “dependiente del contexto”.
    2. Un nombre de clase adicional (con posfijo) podría cambiar la apariencia de un bloque aplicando reglas CSS adicionales. Este fue un modificador "independiente del contexto".class="b-block b-block-postfix"

    Un marco unificado para todo el portal

    A principios de 2008, Yandex estaba pasando por una importante revisión de su política de diseño interno. Decidimos crear un libro de marca (para uso interno) para hacer cumplir las mejores prácticas en el diseño de interfaces en toda la empresa.

    Esta tarea fue asignada al equipo de front-end y después de reflexionar sobre las opciones, decidimos continuar con ella utilizando tecnologías familiares: HTML y CSS.

    Las interfaces evolucionan rápidamente , tan rápido que cualquier intento a largo plazo de describirlas con palabras e imágenes quedaría obsoleto incluso antes de completarse. Necesitábamos un libro de marca que representara nuestras interfaces tal como eran: cambiando rápidamente pero aún unificadas entre los diferentes servicios y productos de Yandex.

    Por lo tanto, decidimos que nuestro libro de marca de interfaz debería construirse con los mismos bloques que usamos para construir nuestros sitios web. Los bloques podrían compartirse entre proyectos y representarían lo último en el diseño de interfaz de Yandex.

    Decidimos construir un marco de bloques para todo el portal para que todos pudieran beneficiarse y contribuir. El proyecto se denominó internamente "Lego".

     

    Estructura del repositorio del marco: primer enfoque

    El nivel superior correspondía a varias implementaciones disponibles :

    css/html/js/xml/xsl/

    Cada implementación tenía su propia subestructura de carpetas.

    CSS entró en tres carpetas diferentes:

    css/ block/ b-dropdown/ b-dropdown.css service/ auto/ block/ b-head-logo-auto.css head.css util/ b-hmenu/ b-hmenu.css
    1. blockEstos eran bloques compartidos entre servicios.
    2. utilHabía bloques de uso general listos para ser de código abierto.
    3. serviceEstos eran estilos CSS para servicios específicos de Yandex, utilizados para marcas, encabezados y pies de página, etc.

    La estructura de carpetas del HTML era idéntica a la del CSS:

    html/ block/ b-dropdown.html service/ auto/ l-head.html util/ b-hmenu.html

    Sin embargo, JavaScript estaba estructurado de manera flexible y se usaba de manera inconsistente entre los servicios:

    js/ check-is-frame.js check-session.js clean-on-focus.js dropdown.js event.add.js event.del.js

    Cada servicio tenía un archivo XML correspondiente que describía semánticamente el encabezado de su página (y que proporcionaba los datos necesarios específicos del proyecto). Junto con una hoja de estilo XSL, el archivo XML fue suficiente para generar el código HTML del encabezado.

    xml/ block/ b-head-tabs-communication.xml common-services.ru.xml head-messages.ru.xml service/ auto/ head.xml

    Las plantillas XSL para varios bloques (un archivo por bloque) estaban contenidas en una carpeta:

    xsl/ block/ b-dropdown.xsl b-head-line.xsl i-common.xsl i-locale.xsl l-foot.xsl l-head.xsl

    ¿Qué pasa con la integración?

    Lego se vinculó a proyectos con la ayuda de una función de control de versiones conocida como svn:externals.

    Cuando se creaba un paquete para su implementación en producción, el código de la biblioteca externa (Lego) se incrustaba en el paquete, de forma similar a la vinculación de bibliotecas estáticas en lenguajes compilados.

    Lego proporcionó una rama SVN para cada uno de sus lanzamientos principales. Cumplir con una rama permitió svn:externalsintroducir correcciones urgentes en un proyecto; Para una estabilidad extrema, un proyecto podría congelarse en una revisión específica de Lego. En cualquier caso, se podrían preparar y realizar cambios de versión principal cuando sea necesario.

    Esta sencilla técnica resultó bastante flexible y se utiliza hasta el día de hoy en muchos servicios de Yandex.

    Archivos por página

    Los archivos CSS importaban definiciones de reglas para los bloques utilizados en una página desde la estructura de carpetas de Lego.

    @import url(../../block/l-head/l-head.css);@import url(../../block/b-head-logo/b-head-logo.css);@import url(../../block/b-head-logo/b-head-logo_name.css);@import url(block/b-head-logo-auto.css);

    La coherencia de las directivas de importación se mantuvo manualmente.

     

    En ese momento, aún no habíamos llegado a una convención para la nomenclatura unificada de archivos y probamos varios enfoques.

    Marco de todo el portal: Lego 1.2 (2008)

    Tras el lanzamiento de Lego 1.2, el código fue refactorizado y la estructura de carpetas cambió.

    common/ css/ js/ xml/ xsl/example/ html/service/ auto/ css/ xml/

    Se combinaron bloques previamente separados y colocados en utilcarpetas . blockLos estilos comunes compartidos por la mayoría de los bloques se trasladaron a common/css. Habíamos estado considerando la posibilidad de abrir el código, pero lo pospusimos hasta dos años después.

    common/ css/ b-dropdown/ arr/ b-dropdown.arr.css b-dropdown.arr.ie.css b-dropdown.css b-dropdown.ie.css

    Se cambió el nombre de los estilos específicos de IE de *-ie.cssa *.ie.css.

    Todo el contenido de los archivos CSS opcionales (como b-dropdown_arr.css) se movieron a carpetas separadas ( arr/b-dropdown.arr.css).

    Para la modificación de un bloque basada en el nombre de clase, se asignó el guión bajo como separador, reemplazando el guión único que se usaba anteriormente.

    Esto hizo que el nombre de un bloque se separara visualmente del nombre de un modificador, y resultó muy útil para nosotros mientras desarrollamos herramientas automatizadas porque permitía una búsqueda y coincidencia de patrones inequívocas.

    BEM, Est. 2009

    En marzo de 2009, se lanzó Lego 2.0. Ese evento marcó el auge de la metodología BEM .

    BEM significa "bloque, elemento, modificador", las tres entidades clave que utilizamos para desarrollar componentes web.

    Lego 2.0 en 2009

    ¿Qué actualización clave entregó la versión 2.0?

    Estableció la primacía del concepto de “bloque” sobre las tecnologías de implementación subyacentes.

    Cada bloque estaba contenido en una carpeta separada y cada tecnología (CSS, JavaScript, XSL, etc.) estaba representada por un archivo separado. La documentación tiene su propio tipo de archivo, como .wiki.

    ¿Qué otros principios seguíamos en ese momento?

    Extractos de terminología

    Se podría utilizar un "bloque independiente" en cualquier página web y colocarlo en cualquier parte del diseño. Como utilizamos plantillas XML y XSL, un bloque estaba representado por un nodo en el legoespacio de nombres.

    XML:

    lego:l-headlego:b-head-logo

    En HTML, un nodo contenedor de bloques obtuvo un nombre de clase que corresponde exactamente al nombre del bloque.

    HTML:

    tablediv

    CSS:

    .l-head.b-head-logo

    Todos los archivos de bloque (CSS, JavaScript, HTML, XSL) se almacenaron en la carpeta del bloque:

     common/ block/ b-head-logo/ b-head-logo.css b-head-logo.xsl b-head-logo.js b-head-logo.wiki

    En los archivos XML que definen la estructura de la página, los bloques se definen con nodos en el legoespacio de nombres (con el prefijo del nombre del bloque omitido):

     

    lego:b-head-logo lego:name//lego:b-head-logo

    También se omitieron los prefijos para las clases HTML dentro del bloque.

    div spanWeb Service Name Here/span/div.b-head-logo .name { … }

    Los archivos que describen elementos del bloque tienen cada uno su propia carpeta:

    common/ block/ b-head-logo/ name/ b-head-logo.name.css b-head-logo.name.png b-head-logo.name.wiki

    Los modificadores en XML se especificaron como atributos de nodo en el legoespacio de nombres:

    lego:b-head-tabs lego_theme="grey"

    En HTML, se agregó un nombre de clase adicional:

    div.b-head-tabs_grey { … }

    Los archivos modificadores (es decir, estilos, etc.) se guardaban en carpetas separadas, con el prefijo de guión bajo:

    common/ block/ b-head-logo/ _theme/ b-head-logo_gray.css b-head-logo_gray.png b-head-logo_gray.wiki

    Declaraciones en XML

    Todos los componentes de Lego utilizados en un proyecto se definieron en un archivo XML:

    lego:page lego:l-head lego:b-head-logo lego:name/ /lego:b-head-logo lego:b-head-tabs type="search-and-content"/

    Este XML permitió generar importaciones de CSS:

    @import url(../../common/block/global/_type/global_reset.css);@import url(../../common/block/l-head/l-head.css);@import url(../../common/block/b-head-logo/b-head-logo.css);@import url(../../common/block/b-head-logo/name/b-head-logo.name.css);@import url(../../common/block/b-head-tabs/b-head-tabs.css);@import url(../../common/block/b-dropdown/b-dropdown.css);@import url(../../common/block/b-dropdown/text/b-dropdown.text.css);@import url(../../common/block/b-pseudo-link/b-pseudo-link.css);@import url(../../common/block/b-dropdown/arrow/b-dropdown.arrow.css);@import url(../../common/block/b-head-search/b-head-search.css);@import url(../../common/block/b-head-search/arrow/b-head-search.arrow.css);@import url(../../common/block/b-search/b-search.css);@import url(../../common/block/b-search/input/b-search.input.css);@import url(../../common/block/b-search/sample/b-search.sample.css);@import url(../../common/block/b-search/precise/b-search.precise.css);@import url(../../common/block/b-search/button/b-search.button.css);@import url(../../common/block/b-head-userinfo/b-head-userinfo.css);@import url(../../common/block/b-head-userinfo/user/b-head-userinfo.user.css);@import url(../../common/block/b-user/b-user.css);@import url(../../common/block/b-head-userinfo/service/b-head-userinfo.service.css);@import url(../../common/block/b-head-userinfo/setup/b-head-userinfo.setup.css);@import url(../../common/block/b-head-userinfo/region/b-head-userinfo.region.css);@import url(block/b-head-logo/b-head-logo.css);@import url(block/b-head-search/b-head-sear 




    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

    La evolución de la metodología BEM

    La evolución de la metodología BEM

    Creación y mantenimiento de sistemas de diseño exitosos, con Brad Fost Anuncie en la revista Smashing Índice

    programar

    es

    https://pseint.es/static/images/programar-la-evolucion-de-la-metodologia-bem-812-0.jpg

    2024-04-04

     

    La evolución de la metodología BEM
    La evolución de la metodología BEM

    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