Construyendo una relación entre CSS y JavaScript

 

 

 

  • Listas de verificación de diseño de interfaz inteligente
  • SmashingConf Nueva York 2024

  • Índice
    1. Mantener CSS fuera de su JavaScript
      1. Limpiando tu HTML
      2. Entornos web y de equipo
    2. Uso de CSS conductual con alternativas de JavaScript
    3. La moraleja de la historia
      1. Otras lecturas

    Aunque mantenemos JavaScript, CSS y HTML en archivos diferentes, los conceptos detrás de la mejora progresiva se complican con cada complemento jQuery que utilizamos y con cada técnica extraña que surge. En esta publicación, Tim Wright ofrece una pequeña perspectiva de dónde estamos y cómo podemos realinear nuestros objetivos.

     

    jQuery, Prototype, Node.js, Backbone.js, Moustache y miles de microbibliotecas de JavaScript se combinan en un único hecho innegable: JavaScript es popular . De hecho, es tan popular que a menudo nos encontramos usándolo en lugares donde otra solución podría ser mejor a largo plazo.

    Aunque mantenemos JavaScript, CSS y HTML en archivos diferentes, los conceptos detrás de la mejora progresiva se complican con cada complemento jQuery que utilizamos y con cada técnica extraña que surge. Debido a que JavaScript es tan poderoso, existen muchas superposiciones en las capacidades entre JavaScript y HTML (construir estructura de documentos) y JavaScript y CSS (inyectar información de estilo).

    No estoy aquí para elegir ninguna biblioteca de JavaScript, bootstrap o texto estándar; Sólo estoy aquí para ofrecer una pequeña perspectiva de dónde estamos y cómo podemos realinear nuestros objetivos.

    Mantener CSS fuera de su JavaScript

    CSS puede conectarse a HTML con una variedad de selectores diferentes; esto no es nada nuevo. Al utilizar ID, clases o cualquier atributo que se le ocurra (incluso atributos personalizados), tiene fácil acceso para diseñar un elemento. También puedes hacer esto con una gran cantidad de métodos de JavaScript y, sinceramente, es el mismo proceso básico con una sintaxis diferente (uno de mis momentos ah-ha de JavaScript). Poder acceder de forma nativa a HTML desde JavaScript y CSS es una de las razones por las que la mejora progresiva ha sido un modelo de desarrollo tan exitoso. Permite tener un punto de referencia que nos guíe y nos sirva de recordatorio a medida que desarrollamos un proyecto, para no “ cruzar corrientes ”.

     

    Pero, a medida que avanza con JavaScript y crea aplicaciones con elementos altamente interactivos, se vuelve más difícil no sólo mantener HTML fuera de JavaScript, sino también detenerse antes de inyectar información de estilo en un documento. Por supuesto, el caso para no inyectar estilo con JavaScript ciertamente no es binario (sí/no, verdadero/falso, 0/1); Hay muchos casos en los que es posible que necesite aplicar estilos progresivamente, por ejemplo, en una interfaz de arrastrar y soltar donde la información de posicionamiento debe actualizarse constantemente según la posición del cursor (o del dedo).

    Pero en términos generales, puede almacenar de forma segura toda la información de estilo que necesita dentro de CSS y hacer referencia a estilos como clases reutilizables. Este es un modelo mucho más flexible que esparcir CSS en un archivo JavaScript y se compara mucho con el modelo de agregar información de estilo a su HTML. Seguimos este modelo cuando es solo HTML y CSS, pero por alguna razón tiende a desmoronarse una vez que se agrega JavaScript a la mezcla. Sin duda es algo a lo que debemos estar atentos.

    Muchos desarrolladores de aplicaciones para el usuario se enorgullecen de tener un HTML limpio. Es fácil trabajar con él y, para ciertos súper geeks, puede resultar incluso ingenioso. Es fantástico tener HTML limpio y estático, pero ¿de qué sirve eso si el HTML generado está plagado de estilos inyectados y marcas no semánticas? Por "HTML generado", me refiero a cómo se ve el HTML después de haber sido consumido y vomitado después de haber pasado todos esos complementos y JavaScript adicional. Si el primer paso para tener HTML limpio y capas de mejora progresiva separadas es no usar un styleatributo, debo decir que el segundo paso es evitar escribir JavaScript que inyecte un styleatributo por usted.

    Limpiando tu HTML

    Probablemente todos estemos de acuerdo en que usar ciegamente una tecnología es una idea terrible, y creo que estamos en un punto con jQuery en el que, de hecho, estamos usando ciegamente muchas de las funciones sin comprender completamente lo que sucede bajo el capó. El ejemplo en el que me apoyo bastante para mantener CSS fuera de mi JavaScript es el comportamiento del hide()método de jQuery. Según los principios de mejora progresiva, no codificarías algo con CSS en línea como este:

    div/div

    No hacemos eso porque un lector de pantalla no captará un elemento si el estilo está configurado en display:noney también confunde el HTML con información de presentación innecesaria. Cuando usas un método jQuery como hide(), eso es exactamente lo que hace: establecerá un styleatributo en el área de destino y agregará una propiedad de visualización de none. Es muy fácil de implementar, pero no muy bueno en términos de accesibilidad . También viola los principios de mejora progresiva cuando se inyecta estilo en el documento de esa manera (estamos bastante confundidos, ¿eh?). No es raro que este método se utilice dentro de una interfaz de pestañas para ocultar contenido. El resultado es que el contenido no existe para un lector de pantalla. Una vez que nos damos cuenta de que agregar estilo desde JavaScript no es lo ideal en la mayoría de los casos, podemos moverlo al CSS y hacer referencia a él como una clase:

     

    CSS

    .hide { display: none;}

    jQuery

    $('.content-area').addClass('hide');

    Todavía tenemos que abordar el problema de accesibilidad de ocultar contenido con display:none, pero como ya no utilizamos un método jQuery integrado, podemos controlar exactamente cómo se oculta el contenido (cualquier método accesible que prefiera probablemente esté bien). Por ejemplo podríamos hacer algo como:

    CSS

    .hide { position: absolute; top: -9999px; left: -9999px;}.remove { display: none;}

    En el ejemplo anterior, puede ver que aunque ambas clases hacen que el contenido se elimine de la vista, funcionan de manera muy diferente desde el punto de vista de la accesibilidad. Mirar el código de esta manera deja claro que realmente estamos tratando con información de estilo que pertenece a un archivo CSS. El uso de clases de utilidad de esta manera no solo puede ayudar a que JavaScript se reduzca, sino que también puede tener un doble uso en un modelo de desarrollo CSS orientado a objetos (OOCSS). Esta es verdaderamente una forma de no repetirse (Don't Repite Yourself, o DRY) dentro de CSS, pero también en todo el proyecto, creando un enfoque más holístico para el desarrollo front-end. Personalmente, veo muchos beneficios en controlar tus comportamientos de esta manera, pero algunas personas también me han llamado fanático del control en el pasado.

    Entornos web y de equipo

    Esta es una manera de empezar a abrir líneas de comunicación entre CSS y JavaScript y apoyarnos en las fortalezas de cada lenguaje sin exagerar. Crear un equilibrio de desarrollo en el front-end es muy importante , porque el entorno es muy frágil y no podemos controlarlo como podemos hacerlo en el back-end con un servidor. Si el navegador de un usuario es antiguo y lento, la mayoría de las veces no puedes sentarte y actualizarlo (aparte: mi abuela usa Chrome); todo lo que podemos hacer es aceptar el caos ambiental, construir para lo mejor y planificar para lo peor.

    Algunas personas me han discutido en el pasado que este estilo de desarrollo, en el que se hace referencia a clases de CSS en JavaScript, no funciona bien en entornos de desarrollo en equipo porque el CSS generalmente ya está integrado cuando te sumerges en JavaScript. , lo que puede hacer que estas clases se pierdan en la mezcla y creen mucha inconsistencia en el código (lo opuesto a DRY). A esas personas les digo: asoman la cabeza por la pared del cubo, abren AIM, GTalk o Skype y comunican al resto del equipo que estas clases existen específicamente para usarse con JavaScript. Sé que el concepto de que los desarrolladores se comuniquen fuera de los mensajes de confirmación de GIT parece una locura, pero todo estará bien, lo prometo.

    Uso de CSS conductual con alternativas de JavaScript

    El uso de estos objetos CSS como enlaces para JavaScript puede ir mucho más allá de simplemente ocultar y mostrar contenido en un área de CSS de comportamiento, transiciones, animaciones y transformaciones que a menudo se realizan con animaciones de JavaScript. Con eso en mente, echemos un vistazo a un modelo de interacción común para desvanecer un divclic y veamos cómo se configuraría con este modelo de desarrollo, al mismo tiempo que proporcionamos las alternativas adecuadas para los navegadores que podrían no admitir la transición CSS que usamos. vas a usar.

     

    Para este ejemplo usaremos:

    • jQuery
    • Modernizar

    Primero, configuremos nuestro bodyelemento:

    body button type="button"Run Transition/button div/div!--/#cube--/body

    Desde allí necesitaremos configurar el CSS:

    #cube { height: 200px; width: 200px; background: orange; -webkit-transition: opacity linear .5s; -moz-transition: opacity linear .5s; -o-transition: opacity linear .5s; transition: opacity linear .5s;}.fade-out { opacity: 0;}

    Antes de agregar la capa de JavaScript, tomemos un momento y hablemos sobre el flujo de lo que sucederá :

    1. Utilice Modernizr para comprobar la compatibilidad con la transición CSS
    2. En caso afirmativo
      1. Configure un evento de clic en el botón para agregar una clase de “desvanecimiento” a#cube
      2. Agregue otro detector de eventos para detectar cuándo finaliza la transición para que podamos cronometrar la ejecución de una función que se eliminará #cubedel DOM.
    3. Si no
      1. Configure un clic incluso en el botón para usar animate()el método de jQuery para desvanecerse manualmente #cube.
      2. Ejecute una función de devolución de llamada para eliminar #cubedel DOM.

    Este proceso introducirá un nuevo evento llamado transitionend, que se ejecutará al final de una transición CSS. Es asombroso, para tu información. También hay un evento complementario llamado animationend, que se ejecutará al final de una animación CSS para interacciones más complejas.

    Lo primero que debemos hacer es configurar nuestras variables en JavaScript:

    (function () { // set up your variables var elem = document.getElementById('cube'), button = document.getElementById('do-it'), transitionTimingFunction = 'linear', transitionDuration = 500, transitionend; // set up the syntax of the transitionend event with proper vendor prefixes if ($.browser.webkit) { transitionend = 'webkitTransitionEnd'; // safari chrome } else if ($.browser.mozilla) { transitionend = 'transitionend'; // firefox } else if ($.browser.opera) { transitionend = 'oTransitionEnd'; // opera } else { transitionend = 'transitionend'; // best guess at the default? } //... rest of the code goes here.})(); // end wrapping function

    Quizás notes que nuestro nuevo transitionendevento necesita un prefijo de proveedor; Estamos haciendo una pequeña detección del navegador para solucionarlo. Normalmente, puede detectar el prefijo del proveedor y agregarlo al nombre del evento, pero en este caso los casos de sintaxis son un poco diferentes, por lo que necesitamos obtener el nombre completo del evento para cada prefijo.

     

    En el siguiente paso usaremos Modernizr para detectar soporte y agregaremos nuestros detectores de eventos a cada caso (todo esto se agrega dentro de la función de ajuste):

    // detect for css transition support with Modernizrif(Modernizr.csstransitions) { // add our class on click $(button).on('click', function () { $(elem).addClass('fade-out'); }); // simulate a callback function with an event listener elem.addEventListener(transitionend, function () { theCallbackFunction(elem); }, false);} else { // set up a normal click/animate listener for unsupported browsers $(button).on('click', function () { $(elem).animate({ 'opacity' : '0' }, transitionDuration, transitionTimingFunction, function () { theCallbackFunction(elem); }); }); // end click event} // end support check

    Finalmente, necesitamos definir una función compartida entre las dos acciones (DRY) que se ejecuta después de que se completa la transición (o animación). Por el bien de esta demostración, podemos simplemente llamarla theCallbackFunction()(aunque técnicamente no es una función de devolución de llamada). Eliminará un elemento del DOM y mostrará un mensaje en la consola informándonos que funcionó.

    // define your callback function, what happens after the transition/animationfunction theCallbackFunction (elem) { 'use strict'; // remove the element from the DOM $(elem).remove(); // log out that the transition is done console.log('the transition is complete');}

    En el navegador, esto debería funcionar de la misma manera en IE 7 (en la gama baja) que en Safari móvil o Chrome para dispositivos móviles (en la gama alta). La única diferencia está debajo del capó; la experiencia nunca cambia para el usuario. Esta es una forma de utilizar técnicas de vanguardia sin sacrificar la experiencia de usuario degradada. También mantiene CSS fuera de JavaScript, que fue realmente nuestro objetivo todo el tiempo.

    La moraleja de la historia

    Quizás se pregunte por qué deberíamos molestarnos en realizar todo este trabajo. Escribimos alrededor de 60 líneas de JavaScript para lograr la misma estética de diseño que podría crearse con ocho líneas de jQuery. Bueno, nadie dijo nunca que mantener el código limpio y apegarse a la mejora progresiva fuera lo más fácil de hacer. De hecho, es mucho más fácil ignorarlo por completo. Pero como desarrolladores responsables, es nuestro deber crear aplicaciones de una manera que sea accesible y se adapte fácilmente al futuro. Si desea hacer un esfuerzo adicional y crear una experiencia de usuario perfecta como lo hago yo, entonces vale la pena el tiempo extra que se necesita para poner los puntos sobre las íes y cruzar todas las t en un proyecto para crear una experiencia general que se degrade y se degrade con gracia. potenciar progresivamente.

    El uso de este modelo también nos permite apoyarnos en gran medida en CSS por sus puntos fuertes, como el diseño responsivo y el uso de puntos de interrupción para redefinir la interacción en los distintos tamaños de pantalla. También ayuda si está apuntando específicamente a un dispositivo con un ancho de banda limitado porque, como todos sabemos, CSS es mucho más liviano que JavaScript tanto en tiempo de descarga como de ejecución. Poder descargar parte del peso que JavaScript conlleva a CSS es un gran beneficio.

    En producción, actualmente utilizamos animaciones y transiciones CSS para microinteracciones, como efectos de desplazamiento y tal vez un gráfico giratorio o un nudo pulsante. Hemos llegado a un punto en el que CSS es un lenguaje bastante potente que funciona muy bien en el navegador y está bien usarlo más intensamente para aquellas interacciones macro que normalmente se crean utilizando JavaScript. Si está buscando una experiencia liviana y consistente que sea relativamente fácil de mantener y al mismo tiempo le permita utilizar las mejores y más recientes funciones del navegador, probablemente sea hora de comenzar a reparar las barreras y fortalecer la relación entre CSS y JavaScript. Como dijo una vez un gran hombre: "La clave para escribir un excelente JavaScript es saber cuándo usar CSS". (Fui yo... dije eso.)

    Otras lecturas

    • Bibliotecas JavaScript útiles y complementos jQuery
    • Escritura de módulos JavaScript reutilizables de próxima generación en ECMAScript 6
    • Los siete pecados capitales de la implementación de JavaScript
    • 7 cosas de JavaScript que desearía saber mucho antes en mi carrera

    (cp, señor)Explora más en

    • Codificación
    • CSS
    • javascript
    • Técnicas





    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

    Construyendo una relación entre CSS y JavaScript

    Construyendo una relación entre CSS y JavaScript

    Listas de verificación de diseño de interfaz inteligente SmashingConf Nueva York 2024 Índice Mantener C

    programar

    es

    https://aprendeprogramando.es/static/images/programar-construyendo-una-relacion-entre-css-y-javascript-808-0.jpg

    2024-05-20

     

    Construyendo una relación entre CSS y JavaScript
    Construyendo una relación entre CSS y JavaScript

    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