Subscribe

viernes, 29 de junio de 2012

File API de html5

Hasta la llegada de HTML5 era imposible realizar operaciones con los ficheros de un formulario, como por ejemplo:

  • Conocer el tamaño de un fichero y el tipo antes de ser enviado para poder realizar validaciones sin necesidad de enviarlo.
  • Poder seleccionar más de un fichero en un mismo input file.
  • Usar drag & drop para adjuntar un fichero a un formulario.
Miento, si había formas, pero todas ellas pasaban por usar otro tipo de elementos como por ejemplo, flash o applet de java

Con HTML5 disponemos de una nueva api con la que poder trabajar con los ficheros seleccionados en un formulario. En concreto disponemos de las siguientes funciones:

  • File: Nos permite acceder a información de un fichero individual como es el nombre, el tamaño, el mimetype o una referencia un manejador del fichero.
  • FileList: Nos permite las mismas acciones que File pero aplicadas a una lista de ficheros. Se utiliza cuando usamos un <input type="file" multiple>.
  • Blob: Nos permite cortar un fichero por rango de bytes. (Este todavía no lo he podido probar)
Como casi siempre en HTML5 no todos los navegadores soportan actualmente estas api, en principio las últimas versiones de Firefox, Chrome y Opera no tendremos problemas, pero si en Internet Explorer y Safari.

Para saber si el navegador del cliente soporta estas api podemos usar el código:

if (window.File && window.FileReader && window.FileList && window.Blob) {
  // Todas las APIs soportadas.
} else {
  alert('La API de FILE no es soportada en este navegador.');
}

A modo de ejemplo tenéis el siguiente código que muestra en un div la lista de todos los ficheros seleccionado y la información asociada a él.


<input type="file" id="files" name="files[]" multiple />
<output id="list"></output>

<script>
  function handleFileSelect(evt) {
    var files = evt.target.files; // FileList object

    // files is a FileList of File objects. List some properties.
    var output = [];
    for (var i = 0, f; f = files[i]; i++) {
      output.push('<li><strong>', escape(f.name), '</strong> (', f.type || 'n/a', ') - ',
                  f.size, ' bytes, last modified: ',
                  f.lastModifiedDate ? f.lastModifiedDate.toLocaleDateString() : 'n/a',
                  '</li>');
    }
    document.getElementById('list').innerHTML = '<ul>' + output.join('') + '</ul>';
  }

  document.getElementById('files').addEventListener('change', handleFileSelect, false);
</script>

Espero que os sea útil. Yo ya le he encontrado alguna funcionalidad como por ejemplo, validar un formulario antes de ser enviado y mostrar por pantalla el tamaño del formulario que se va a enviar para calcular el tiempo medio de espera.


domingo, 20 de noviembre de 2011

CSS3, el futuro. (Conclusiones de la conferencia mejorando.la)

En el siguiente artículo me gustaría mostrar a las conclusiones a las que he llegado después de ver ayer mismo (19 de Noviembre de 2011) la conferencia de Christian Van Der Henst titulada: "El camino a CSS4".

Esta claro que HTML5 ha dejado ya de ser el futuro para convertirse en el presente. Ya la gran mayoría de navegadores modernos soportan gran cantidad de los nuevos elementos del estándar lo que hace que su uso se ya posible hoy día. Pero HTML5 no es lo único que ha evolucionado, conjunto a él ha crecido CSS3 y la nueva generación de JavaScript.

La nueva versión de CSS nos va a permitir que el diseño de páginas web cambie por completo, esta nueva versión nos va a permitir hacer cosas que antes eran impensables, podremos incluso dibujar con CSS, hacer que nuestras webs cobren vida, y otras muchas cosas. Esto hará que los diseñadores que quieran mantenerse al día tenga que evolucionar, tenga que cambiar el concepto de hacer diseños web como si fueran artistas y pasar a hacer web como si fueran programadores haciendo uso de las nuevas herramientas que nos ofrece CSS3. Lo que está claro que la tecnología avanza y que todo el que se dedique al desarrollo web , ya sean programadores o diseñadores tendrán que ir de la mano de la evolución para no quedarse estancado en el pasado.

El gran rival la evolución en los estándares son los navegadores antiguos, estilo IE6. Nosotros los desarrolladores web debemos luchar por la desaparición de esta "lacra de la evolución". Es significativo que hasta microsof mediante un comunicado oficial desaconsejara el uso de dicha versión de su navegador, y como la gente sigue usándolo. Menos mal que las últimas estadísticas hablan de un descenso en el uso de este tipo de navegadores y por lo tanto, menor número de usuarios que lo usan.

Es importante recordar que todos los navegadores modernos (opera, firefox, chrome, internet explorer, safari) ya dan un amplio soporte. Por lo tanto no debemos tenerle miedo a la actualización de nuestros desarrollos, abrazar estos nuevos estándares y empezar a dejar de mirar al pasado, y esas compatibilidades estúpidas que solo hacen aumentar los costes de desarrollos y que no compensa el retorno de la inversión que se obtiene con ello.

Menos mal que siempre hay programadores dispuesto a resolver muchos de los problemas que nos encontramos debido a incompatibilidades. Por ello existen productos como:

  • Modernizr: Libreria JS que nos permite conocer la compatibilidad del navegador con tecnologías HTML5 y CSS3 permitiéndonos hacer sitios web que se adapten a todos nuestros usuarios.
  • Selectivizr: Librería JS que nos simula el comportamiento de CSS en los navegadores IE6-IE8.


Recursos CSS3 interesantes:

  • zurb.com: Página donde generar botones interesantes con CSS3.
  • ecsspert.com: Herramienta para dibujar directamente en CSS3
  • Adobe CSS Shaders: Permite aplicar efectos cinematográficos solo con CSS3.
  • CSS3 secrets: Demostración sobre las principales mejoras de CSS3
  • hakim.se: Sitio web con demostraciones de HTML5 y canvas en el que podemos ver el potencial de este nuevo elemento.
  • raphaeljs.com: Libreria JS que nos simplifica el trabajo de desarrollar gráficos vectoriales en la web.
  • impact.js: Libreria JS que nos ayuda en el desarrollo de juegos en HTML5.
  • CSS3Generator: Herramienta que nos permite generar código CSS3 de una manera fácil y rápida.
  • Original Hover efects: Efectos originales basados en CSS3
  • jquerymobile.com: Libreria JQUERY para el desarrollo de páginas web para móviles con la posibilidad de crear nuestros propios temas a medida.
Prefijos CSS3

Uno de los grandes inconvenientes de CSS3 es la necesidad de usar preficos para que los estilos sean comprendidos por los distintos motores de los navegadores. Esto nos obliga a duplicar la creación de estilos y a tener que ser muy cuidadosos a la hora de desarrollar con CSS3. Pero como siempre, hay recursos para facilitarnos el trabajo de desarrollo, como por ejemplo: CSS Prefixer o Prefix-Free, que nos permiten pasar nuestro CSS con los estilos propios de CSS3 y ellos se encargan automáticamente de generar los mismos estilos con todos los prefijos necesarios.

Frameworks CSS3

En cualquier lenguaje de programación no suelen tardar mucho las herramientas que nos hacen que desarrollar en él sea una tarea mucho más simple. Para ello aparecen los frameworks de desarrollo. En CSS3 también existen frameworks que nos permiten que la tarea de desarrollar sea mucho más simple. Entre los entornos de desarrollo más importantes están:
También disponemos de otras herramientas que nos facilitan la creación de nuestros layouts:
CSS4

Por último, y para concluir la charla, Christian comentó cual es el futuro del CSS, y no es más que la próxima versión: CSS4.
Ya se está empezando a hablar de cuales son las nuevas características que nos ofrecerá la W3C con esta versión. Entre algunas de las que se comentaron están:
  • Nueva api para Vibración destinada a realizar webs para dispositivos móviles.
  • Nuevos selectores que nos permitirán elegir un elemento de nuestro DOM mucho más preciso.
  • Elemento Matches.
Pero CSS4 hoy día no es una realidad, es el futuro, y por lo tanto, tendremos que estar muy atentos para que la tecnología no nos deje atrás.

miércoles, 10 de agosto de 2011

div, section y article

Quizás, lo más repetido desde que comenzamos a trabajar con HTML5 es que esta nueva versión nos ofrece la posibilidad de dotar de semántica a los contenidos de una web.
Para ello dos nuevos elementos han aparecido: section y article. Pero, ¿realmente conocemos como y cuando debemos usarlos? Y tenemos claro que lo diferencia del antiguo (y todavía válido) div.
Pues bien, voy a intentar explicar los posibles usos de cada uno y dar los suficientes ejemplos para que lleguéis a comprender mejor las diferencias entre estas etiquetas. 
div 
La etiqueta div sigue funcionando exactamente igual que lo hacía hasta el momento. Lo usaremos para definir bloques sin ningún tipo de significado, normalmente bloques que usaremos para maquetar correctamente la página o para agrupar elementos en principio sin querer dar un significado específico. Este etiqueta era la más usada en HTML 4 y nos servía tanto para representar un artículo como para la cabecera o el pie de la página usando tan solo el atributo id para diferenciarlos sin dar significado ninguno a los contenidos.
article 
Esta etiqueta será usada para representar un contenido específico de nuestra web. Puede representar un artículo, ya sea un artículo de opinión, un entrada en un blog, un comentario en un foro, una noticia, una descarga, o simplemente un contenido estático de una web como el típico quienes somos o a qué nos dedicamos. Para que entendáis mejor esta etiqueta, la usaremos para representar el contenido típico que se publica en una RSS. 
Por lo tanto, este tipo de contenido tiene un alto valor semántico ya que aporta información relevante dentro de nuestro documento. Este elemento debería tener principalmente un título (un header con un h1-h6) y podría tener un footer (con la fecha de publicación, el autor o cualquier otra información adicional) y un cuerpo con el detalle. 
Por ejemplo, en el caso de mostrar un listado de noticias, lo que estaremos listando será un listado de elementos article. 
section 
La etiqueta section es quizás la más difícil de comprender. En principio se usa para representar un bloque de nuestra página que tiene valor semántico, es decir, que aporta un significado a la página. Realmente si tenemos que clasificar por la importancia del significado, el ranking sería: article sería la etiqueta que contiene la información más relevante, section la que contiene información menos relevante, y div que contiene información que no aporta significado ninguno. 
Bien, vamos a intentar poner ejemplos de uso: 
  • Listado de noticias: Antes hemos comentado que un listado de noticias será un listado de elementos article, pero, ¿cómo representamos este listado? Pues la mejor forma será con la etiqueta section. Este listado quedaría aproximadamente: 
<section>
<header><h1>Listado de noticias</h1></header>
<article><header><h2>Noticia 1</h2></header></article>
<article><header><h2>Noticia 2</h2></header></article>
<article><header><h2>Noticia 3</h2></header></article>
</section>


  • Bloque principal de la página: Imaginaros por ejemplo una portada que tiene una zona destacada en la que se muestra una introducción. Este bloque de contenido podría ser perfectamente un bloque section.
  • Separar elementos dentro de un artículo: Cuando se trata de un artículo muy completo podríamos estructurar la información por secciones. Por ejemplo, un articulo separado en Introducción, Desarrollo y Conclusión estaría formado por 3 section, uno para cada bloque. Igualmente podríamos usarlo para agrupar una galería de imágenes asociada al contenido o incluso un listado de enlaces relacionados directamente con el artículo. 
<article>
<header><h1>Artículo</h1></header>
<section><header><h2>Introducción</h2></header> …TEXTO … </section>
<section><header><h2>Desarrollo</h2></header> …TEXTO … </section>
<section><header><h2>Conclusiones</h2></header> …TEXTO … </section>
<section><header><h2>Galería de imágenes</h2></header> …TEXTO … </section>
</article>


Un aspecto importante de la etiqueta section es que debe tener un título. Tal y como hemos comentado en otros artículos de este blog, la etiqueta section crea una sección de manera explícita en el outline del documento, por lo tanto debemos siempre asignarle un encabezado (h1-h6) ya que si no se le aplicará directamente untitle
Por lo tanto, una buena forma de identificar cuando es necesario usar una etiqueta section es cuando tengamos la necesidad de aplicar un encabezado. 

Si os dedicáis a investigar un poco por ahí veréis como hay opiniones para todos los gustos. Hay quien dice que el elemento section debería ser quien contiene al article, y otros dicen todo lo contrario, que article es quien debe contener a section. Lo cierto es que la documentación oficial no aclara mucho sobre el tema y lo deja abierto a posibles interpretaciones. Solo el tiempo dirá como lo acaba utilizando la gente, pero desde luego, yo creo que realmente ambos están en lo cierto. La etiqueta section abre un gran abanico de posibilidades y nos permite usarlo de muchas maneras, en algunos casos será el padre de article (como por ejemplo en el caso del listado de noticias) y en otros será el hijo de article (como en el caso del articulo fraccionado en bloques). Por lo tanto, pensad antes de usar una etiqueta u otra que tiene más sentido usar en base a la información que estamos representando. 

Espero en un futuro aportar más ejemplos conforme se me vayan ocurriendo. Si queréis aportar vuestra experiencia no dudéis en comentar lo que queráis.

viernes, 5 de agosto de 2011

Header y Footer

Bueno, va siendo hora de seguir repasando alguno de los nuevos elementos introducidos por HTML5.
En este caso le toca el turno a las etiquetas header y footer.

Header

La etiqueta header sirve para mostrar información de cabecera útil para un documento u otras secciones principales. Típicamente se utiliza para agregar encabezados, es decir, h1-h6 que definen el título y subtítulos de la sección, aunque también se puede utilizar para dar información sobre fechas de publicación, versiones del contenido mostrado, o enlaces de navegación dentro del documento (por ejemplo, enlaces a la home, información de contacto, o al mapa web de una página). A pesar del nombre de la etiqueta, ésta no tiene porque ir situado al principio del HTML, sino que puede estar posicionado en cualquier posición dentro de nuestro documento.
Ej:
<header>
<h1>Blog: HTML5 Paso a paso</h1>
<p>Mi nombre es Sergio Raposo Vargas</p>
</header>


Footer

La etiqueta footer representa el pie de un documento o sección. La información que se suele añadir en este bloque es el autor del documento, enlaces a contenido relacionado, información de copyright, avisos legales, etc.
Igualmente podremos agregar al pie información de contacto. Recordar que para ello disponemos de otra etiqueta llamada address. Al igual que en la etiqueta anterior, a pesar de su nombre, este elemento no tiene porque ir al final del documento o sección aunque suele ser lo más normal.
Ej:
<footer>Este documento fue escrito en 2011.</footer>

domingo, 27 de marzo de 2011

Analizando una web. Parte I

En este post voy a intentar analizar una web construida en 3 columnas que existe actualmente y está programada en HTML4 y como se haría pensando en el nuevo estándar.
El ejemplo que vamos a tomar como base es la web de una comunidad de la cual soy administrador: www.opencmshispano.com. Para empezar con el análisis vamos a tomar como base la portada de la web.
A continuación podéis ver como es actualmente:

Lo primero que debemos pensar es buscar los distintos bloques a nivel semántico definidos por HTML5 en la web, para ello en la siguiente imagen he señalado los bloques de distintos colores . En rojo tenéis la cabecera y el pie, en naranja los bloques de navegación "nav" y en verde las distintas secciones "section".

Como podéis ver, en esta pantalla principal del portal tenemos numerosas secciones, digamos que serían como las secciones principal del portal. Cada una de ellas tiene un significado y todas ellas podrían tener un título de encabezado. En ningún caso ninguna de ellas se encuentran relacionadas. Las secciones detectadas son:
  • Listado de noticias principal
  • Listado de articulos de Technology For Solutions
  • 2 bloques de listado de banners
  • Un bloque de las últimas entradas en el blog
  • Un bloque de enlaces de interés relacionados con la comunidad.
Igualmente podemos ver como hemos detectados 4 bloques de navegación:
  • Menú principal situado en la columna de la izquierda.
  • Menú de acceso rápido a las herramientas adicionales a la web como son el foro, el blog y las FAQ
  • Menú de navegación a otras secciones de la web basadas en iconos, como son el link a la home, al mapa web, al formulario de contacto y las RSS
  • Enlaces en el pie a los textos legales que suelen acompañar a todas las web con las normas de uso y la política de privacidad.
Por último, los dos bloques quizás más claros de todos, la cabecera y el pie, comunes en todas las páginas y donde introduciremos información relevante del portal como el nombre de la comundiad, la publicidad principal del portal o los agradecimientos situados en el pie.
Hasta el momento hemos comentado la división "semántica" del portal, pero evidentemente existe otro tipo de división, la visual. Como vemos la web está estructurada en 3 columnas, para ellos, y salvo que se me escape, tenemos que seguir usando los divs para la creación de este tipo de bloques visuales. Para ello tendremos un div general que englobará a toda la zona del centro, y un div por cada columna. Si fuera necesario añadir más div por temas de maquetación no tendremos problemas ya que este elemento lo podemos seguir usando como hasta ahora. Por lo tanto la división visual de la web sería:


Bueno hasta aquí hemos visto como se organiza de forma esquematizada una web siguiendo el nuevo estandar HTML5, para próximos post analizaremos con detalle cada uno de los sectores detectados y las páginas interiores como el detalle de una noticia, o el listado de artículos y tutoriales.
Espero vuestros comentarios al respecto, si creéis que mi interpretación y separación no es del todo correcta podemos comentarla para que entre todos lleguemos a sacar unas conclusiones definitivas.

lunes, 21 de marzo de 2011

Para que nos sirve HTML5!!

Que de tiempo sin escribir ...
Bueno, espero recuperar la dinámica de actualizar este blog, es una iniciativa que la verdad que me gustaría mantener.
Hoy quería escribir sobre una pregunta que se me ha ocurrido, y es: ¿Para que nos sirve HTML5?
Supongo que cualquiera que haya visto algo del nuevo estándar de HTML podrá darme algunas respuestas. Sinceramente cuando empecé a leer información la ilusión era tremenda, parecía que HTML5 iba a dar un vuelco al concepto de web que tenemos hoy día. Conforme seguí avanzando me di cuenta que, efectivamente HTML5 era un gran cambio, pero quizás no era el cambio definitivo (quizás el que necesitábamos realmente).
Aun así, y tras recuperar un poco del bajón sufrido, creo que HTML5 va a traer multitud de cosas buenas, y la principal de todas es la desaparición paulatina de los navegadores antiguos, principalmente de IE6. Nada más que por eso se merece un aplauso y un seguimiento incondicional.
Pero nos va a ofrecer mucho más, la caída del flash, el fin de los div (para organizar la estructura de nuestras páginas), el fin de las cookies como las conocemos, más posibilidades multimedia, más semántica a nuestros contenidos, ....
Poco a poco iré comentando aquellos elementos que me vayan llamando la atención, principalmente los nuevos elementos creados y los que han pasado a mejor vida.

domingo, 14 de noviembre de 2010

Character Encoding en HTML

La codificación en la web ha sido uno de los grandes problemas que todo programador web se habrá encontrado en algún punto de su carrera. Sobre todo cuando los contenidos de la web son gestionados por gestores de contenido la codificación todavía es más complicada, dependerá de la codificación con la que se guarda la información, y con la que se muestra posteriormente.
En HTML existe 2 caminos de definir el encoding del documento:

  • Configuración en la cabecera HTTP: Content-Type: text/html; charset="utf-8". Esta configuración se realiza a nivel del servidor, el principal problema de esta opción es que no todo el mundo tiene libertad para manipular esta configuración, imaginaros por ejemplo los blogs como el mío que está instalado en los servidores de blogger (google) donde no tenemos esta posibilidad.
  • Configuración con metatags: <meta http-equiv="Content-Type" content="text/html; charset=utf-8">. Esta configuración va directamente en el document HTML de la página, el cual ya si es gestionado por nosotros mismos y tenemos la opción de modificar.
Ambos caminos dan el mismo resultado y la finalidad es la misma, pero es muy importante usar uno u otro sistema, pero nunca dejar sin definir el character encoding de nuestros documentos html ya que sino puede traer bastantes problemas de seguridad.
Una buena práctica es definir por defecto un encoding en las cabecera HTTP, es decir, una codificación estándar en nuestros servidores web y en los casos que sea necesaria redefinirla usando el metatags. Siempre va a prevalecer el metatags por encima de la cabecera HTTP.
HTML5 no ha cambiado nada respecto a la configuración del encoding, y todo lo comentado hasta ahora es válido para la nueva versión del estándar. Lo único que se ha modificado ha sido la forma de especificarlo con el metatags, donde se ha comprimido y simplificada la linea, de forma que ahora tan solo debemos poner:
<meta charset="utf-8" />
Para otro día comentaré otros problemas derivado del encoding más orientado a la gestión de los contenidos y la forma de presentar la información.