Mostrando las entradas con la etiqueta desarrollo web. Mostrar todas las entradas
Mostrando las entradas con la etiqueta desarrollo web. Mostrar todas las entradas

CSS - Por qué usar pre-procesadores: Less / Sass (conceptos básicos)

viernes, 26 de septiembre de 2014

CSS (Cascading Style Sheets) es el lenguaje utilizado para detallar los estilos y formatos de webpages basadas en contenidos creados en documentos HTML.

CSS es muy simplista, accesible y esencial para quienes hacen diseños web pero también es bastante limitado.

El problema con CSS es que cuando el proyecto empieza a hacerse más complejo es cuando saltan a la luz las limitaciones que este lenguaje presenta respecto de las necesidades de desarrollo cada vez más sofisticadas - para las cuales no fue pensado -. Si bien se fueron haciendo cambios en los features de CSS con nuevas versiones y propiedades, todavía le falta mucho para poder satisfacer los requerimientos actuales del diseño web. Esto lleva a que las hojas de estilo se hagan cada vez más repetitivas y difíciles de mantener.

Para cubrir estas necesidades aparecieron los pre-procesadores de CSS que posibilitan el desarrollo de código más ordenado, optimizado y de fácil mantenimiento.

Estos pre-procesadores no ocupan el lugar de CSS sino que ayudan en el ahorro de tiempo de desarrollo, en la creación de documentos más prolijos y en facilitar el uso de características avanzadas de estilos.

Dos de los pre-procesadores más conocidos y utilizados son LESS (Less CSS) y SASS (Syntactically Awesome Stylesheets), cuyas características comunes son:

  • permiten una mejor organización del código
  • ofrecen el uso de variables
  • implementan el uso de mixins
  • permiten reutilizar código
  • tienen funciones nativas para llevar a cabo funciones de uso común
  • dan la posibilidad de ocultar comentarios
  • permiten incluir archivos
  • habilitan el uso de namespaces

Algunas de las virtudes que resaltan quienes prefieren Less

Extensiones

Si bien Sass cuenta con una librería (Compass) conteniendo muchísimas extensiones, Less también puede usar diversas extensiones que, a diferencia de Compass que agrupa todas en un único repositorio, están dispersas y construídas por distintos desarrolladores.
Algunas extensiones disponibles para Less:

Por su simplicidad Less es ideal para quienes ya saben de CSS pero necesitan ponerse rápidamente prácticos en el uso de un pre-procesador que les ayude en sus tareas. La curva de aprendizaje puede ser un poco menos pronunciada con Less que con Sass, aunque en este punto están muy parejos.

Para algunos el sitio oficial de Less es más fácil de usar y es más vistoso que el de Sass, aunque este último ha mejorado mucho la estética y usabilidad de su sitio.

Puntos que resaltan quienes prefieren Sass

Anidamiento

Tanto Less como Sass permiten anidamiento, lo que es útil para evitar escribir selectores repetidamente. Pero Sass va un poco más allá permitiendo también el anidamiento de propiedades individuales.

Mixins y herencia de selectores

Ambos pre-procesadores ofrecen el uso de "mixins" y sólo difieren en la manera de definirlos (en Less con la directiva "@" y en Sass con class selector).

Los mixins en ambos casos se usan para incluir propiedades de un conjunto de reglas en otro. Pero Sass agrega la capacidad de herencia de selectores.

La herencia permite a los selectores heredar las propiedades de otros selectores, Sass soporta esta capacidad naturalmente mientras Less no puede hacerlo.

Documentación

En el sitio de Sass la documentación es mucha, muy comprensible y extensa. La presentación de información es muy sencilla, al estilo Wikipedia.

Por otro lado Less también ofrece buena documentación pero puede parecer más simple y directa, con mucho uso de ejemplos. En cuanto a la documentación puede parecer un poco más atractiva en cuanto a su presentación.


Consideraciones en general

Mas allá de que estas tecnologías nos ofrecen ciertas ventajas a la hora de desarrollar, por otro lado, la organización de nuestros estilos es tan o más importante que las ventajas en sí. Al final del día, que nuestro css logre ser mantenido y comprendido por todos los integrantes de nuestro equipo también es un objetivo a cumplir. Particularmente, nos estamos sumergiendo en la implementación de una guía de estilos

El hecho de que Less haya sido elegido por Bootstrap hizo que muchos se inclinaran por este pre-procesador, pensando en el "aval" que esto le daba. Sin duda le ha dado más y mejor prensa.

Por su lado Sass tiene el soporte de Google que por supuesto representa también un respaldo importante.

Sobre Sass hay varios pre-conceptos que suponen cosas como que es necesario tener un manejo avanzado de Ruby o usar líneas de comando "truculentas"  o cambiar radicalmente la forma de escribir las hojas de estilo. Nada de eso es cierto.

En general al recorrer la web se encuentra más coincidencia en que Sass es más robusto y cubre más necesidades que Less (o al menos de mejor forma).

Particularmente creo que el uso de uno u otro depende de las necesidades de cada desarrollo y las circunstancias en que tengamos que usarlo o la urgencia por empezar a aplicar un pre-procesador como estos.
Algunos de los puntos que es importante tener en cuenta a la hora de elegir:
  • Evaluar el rendimiento de cada uno para servir a los distintos tipos de necesidades del proyecto
  • Tener clara la guía de estilos y las necesidades del front end
  • Evaluar la curva de aprendizaje
  • Tener conocimientos previos de CSS
  • Recurrir a la documentación ofrecida por ambos

Links donde encontrar más información


Sobre comparaciones ambos pre-procesadores estos dos links me parecieron muy interesantes:


Para quienes quieran empezar a ver Less:  

Sobre Sass y Compass: Introducción a Saas y Compass  (en español)














Leer más...

Uso de texto en lugar de imágenes (icon fonts)

lunes, 24 de febrero de 2014

Desde hace ya un par de años una de las prácticas instaladas en desarrollos web es el uso de fuentes tipográficas en lugar de íconos o pequeñas imágenes o incluso sprites css. O sea, se manejan los íconos como textos lo que permite cambiar sus propiedades usando CSS.




El uso de estos “icon fonts” (icon web fonts) presenta muchas ventajas respecto de otras técnicas de inserción de imágenes dado que disminuyen la carga del servidor y las peticiones HTTP, no son tan complejos de implementar como los sprites, son adaptables a distintos dispositivos (los íconos pueden verse pixelados al cambiar de tamaño), se puede cambiar fácilmente sus propiedades, entre otras.

Varios son los sitios donde podemos encontrar conjuntos de font-icons – gratuitos y pagos - y abarcan una enorme variedad de temas. Algunas de estas colecciones hemos aplicado en nuestro web site.

Recomendamos aquí muy buenos artículos donde pueden leer más detalles sobre su implementación y sitios desde donde descargar colecciones:

CSS Tricks

(imagen: htttp://commons.wikimedia.org/wiki/File:Early_writing_tablet_recording_the_allocation_of_beer.jpg)

    
Leer más...

Video en HTML5

jueves, 27 de junio de 2013


Hablar de video en HTML5 es hablar de una intensa lucha que se da entre pesos pesados de internet y de la singular batalla por la estandarización de un códec. En años pasados (2004/2005) la manera que tenian los administradores web de compartir videos en sus web era mediante el recordado Quicktime, Windows media player o los archivos .swf que popularizó Adobe.

Hoy en día, apelamos a Youtube o Vimeo para compartir videos y Steve Jobs para sus dispositivos jamás quiso flash así que se reabrió el debate por tener un estándar para manipular video desde los navegadores.

Pensemos en video como las imágenes. Pueden ser .jpg, .png, .gif, pero no dejan de ser una imágen y el navegador es el encargado de implementarlas a todas. Con el video pasa lo mismo.

Cómo se usa?

Para incluir un video con HTML5 usas el siguiente formato:


Además del ancho y el alto y tal como ocurre con la etiqueta <audio>, tenemos atributos adicionales:

  • Preload: Carga el video junto con la página. Opción recomendada solo si el video es contenido muy importante en nuestra página


Por el contrario, si es un información secundaria, ¿para que penalizar al usuario con espera si quizás no vea el video?. En este caso usaremos algo como esto:


donde le especificamos al navegador que no descargue información del video a menos que el usuario de Play.

  • Autoplay: Esta opción dará play al video automáticamente al terminar de descargarse la página. Lo implementamos de la siguiente manera:
  • Controls: Manipula la visibilidad de los controles para el video (Play, Pause, Seek bar y volúmen).

Compatibilidad

Como ocurre con el tag <audio>, necesitamos especificar varios sources para garantizar la reproducción del video en la mayor cantidad de navegadores. Podemos escribir un código similar a este:

De esta manera, con el primer <source> nos aseguramos que el video funcione en el mundo Apple y con la otra apoyamos una versión más liberal empujada por Google.

Con respecto a IE en sus versiones viejas está de más aclarar que no soporta el tag video, pero podemos contar con flash para solucionar nuestro problema: Incluyendo el código embed justo debajo del último <source>, encerrado también dentro del tag <video>

La documentación oficial del tag video está aquí



Existe un proyecto interesante para utilizar y cuanto menos mirar que es VideoJS. Si te vas a tomar en serio la cuestión de alojar los videos en tu sitio y no depender de terceros, este es tu proyecto. Es un proyecto libre y tiene skins para imitar los principales sitios de video de la web.







Leer más...

Closures- Un primer enfoque

viernes, 14 de junio de 2013

Vamos a tocar un tema que estos últimos días a los integrantes de 3p nos tuvo algo ocupados: Closures en javascript.

"Un closure es un tipo especial de objeto que combina dos cosas: una función y el contexto en el que fué declarada". La definición no ayuda mucho a entender el concepto, así que vamos a plantear un ejemplo sencillo

En Javascript podemos definir funciones en cualquier momento, incluso dentro de otra función. Por ejemplo:


Ver ejemplo en JSFiddle

Dentro de la función sumar tenemos:
  • La variable total que posee la sumatoria resultante y será el resultado de la ejecución de la función
  • La función suma que agrega a total el número que recibe pro parámetro
  • Un ciclo for que recorre una serie de número de números y los suma
  • Retorno de la función: Se devuelve la sumatoria total
Lo importante del código anterior es que entendamos que una función puede convivir dentro de otra. Ahora, será más sencillo comprender que son. Vamos a un nuevo ejemplo donde usemos uno:

Ver ejemplo en JSFiddle

incrementar es un clousure porque, usando la definición que dimos arriba, incorpora una función (sumar) y su contexto (el totalizador i). Ambos, existian cuando se llamó a crearFuncion() para instanciar la variable incrementar









Leer más...

Audio en HTML5

lunes, 20 de mayo de 2013

Audio y video son dos características sobrasalientes de HTML5 (del cual ya dimos un primer pantallazo en este post). Hoy vamos a aprender a implementar esta etiqueta y a hacerla compatible con todos los navegadores modernos (Que puedes mirarlos aquí).

Primer enfoque

El tag <audio> implementa audio en los navegadores sin necesidad de algún plugin (Flash por ejemplo). Es muy fácil de usar. Vamos a ver un ejemplo básico:

Tranquilos, estamos empezando, vamos a analizar nuestro código:
  • width y height: configuran el ancho y alto del reproductor.
  • src: indica la ruta donde está alojada la canción. Igual que con el tag <img>.
  • controls: indica al navegador que muestre los controles mínimos para el manejo visual por parte del usuario (Play/Pause, Seek bar y volúmen).
  • autoplay: indica al navegador si el audio iniciará su reproducción automáticamente cuando la página haya sido descargada.
  • preload: especifica si el audio se descarga con la página, sólo su metadata o cuando el usuario de play.

Compatibilidad

Ahora que ya conocemos la implementación básica de esta etiqueta hablemos un poco de compatibilidad entre los navegadores.

Cada navegador utiliza un motor de renderizado. Para definirlos brevemente digamos que es el encargado de dibujar en el navegador lo que especifica el código (HTML + CSS), en este caso, la implementación del control audio.

Estos son los navegadores más importantes hoy en día y los nombres de sus respectivos motores de render:

  • Chrome: webkit (Hoy en día están desarrollando Blink, su propio motor de render).
  • Mozilla: gecko.
  • Safari: webkit.
  • Opera: presto.
  • IE: trident.

Cada uno de estos motores implementa la etiqueta audio de manera distinta: los códecs que utiliza para reproducir el sonido es diferente en cada uno y cada cual apoya el que considera necesario (Es una pelea muy fuerte, tengamos en cuenta que empresas como Microsoft, Google, Apple y Mozilla Foundation están detrás de cada navegador).

Quieren que sea más claro? El ejemplo de código que vimos arriba NO FUNCIONA EN TODOS LOS NAVEGADORES (Sólo lo haría en IE9 o superior y en Chrome).

Por lo que es necesario modificar levemente nuestro código inicial para modificar el atributo src e indicarle a cada navegador que audio utilizar y con que códec reproducirlo.

implementación de audio en HTML5 compatible con todos los browsers

Con este código estamos seguros que nuestro audio podrá oirse en todos los navegadores modernos. Aquellos que no implementen esta característica del estándar simplemente mostrarán: "Tu navegador no soporta audio HTML5".

Como pueden ver no cambió mucho, solo aislamos el atributo src a un tag dentro de audio y lo configuramos de acuerdo a nuestras necesidades.


Pueden ver la documentación oficial del tag audio en HTML5 en este enlace.







Leer más...