Cada cosa en su sitio

Un documento web consta del lenguaje de marcado (HTML), estilo (CSS) y de un comportamiento (JavaScript).

Se puede hacer un documento web con estos tres elementos incluidos en un único fichero .html pero esto es totalmente erróneo; de hecho creo que ya nadie lo hace.

CSS y JS siempre en un documento aparte para no tener el HTML infectado de <style> ni de <script> o de onclick=”” onblur=”” y así hasta llegar a todas las posibles etiquetas en HTML5 con javascript incrustado creando un código obstructivo ya sea por CSS o JavaScript

No hay nada mejor que entregar o recibir un documento web con todo separado para una mejor compresión y mantenimiento.

El desarrollo se hace más divertido con un documento limpio y ordenado.

Comprimir HTML en el servidor

La compresión del HTML es una manera sencilla para ahorrar ancho de banda y aumentar la velocidad de respuesta en tu sitio web.
La compresión consiste en responder al cliente con la respuesta comprimida en un fichero comprimido. Para hacerse una idea un fichero HTML sin comprimir que pese 100Kb puede ser entregado al cliente con un peso de 15Kb! Por lo tanto el rendimiento de nuestro sitio web aumenta considerablemente.

Para configurar o activar la compresión en el servidor (Apache en mi caso) necesitas añadir las siguiente directivas en el fichero .htaccess
<files *.html>
SetOutputFilter DEFLATE
</files>

Bueno, hay dos maneras de hacerlo, utilizando el estandar de Apache o gzip que es mas potente y puedes dar al servidor contenido ya comprimido (lo que se llama hacer un “crunch”) por lo que es más efectivo.

La manera que he dicho antes es especica para la extensión .html pero puede utilizar también la directiva AddOutputFilterByType DEFLATE text/html

Un ejemplo más claro de .htaccess


# Comprime text, html, javascript, css, xml
AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/xml
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/x-javascript

# O, Comprime ficheros según extensión
<files *.html>
SetOutputFilter DEFLATE
</files>

Recuerda cuando edites tu .htaccess que tienes que cambiar los permisos a 755 después de editarlo o editarlo como modo root.

Etiquetas según contenido

¿No sabes que etiqueta escoger en HTML5?

Siguiendo este flujo de datos puedes averiguar cual és la etiqueta adecuada dependiendo del contenido. Aunque a veces es mejor empezar por preguntarse si el contenido tiene o no tiene sentido semántico. En caso que no tenga sentido semántico, puedes usar <div>

Flujo de datos según contenido

Flujo de datos según contenido

etiqueta viewport y sus consecuencias

¿Qué es y para qué sirve?, Esta pregunta siempre me la hacía cada vez que echaba un vistazo a las etiquetas incluidas en, pero es como todo, no le das importancia hasta que realmente es necesario. viewport identifica el tamaño deseado de la pantalla y dice al dispositivo a que tamaño debe renderizar la página. Es imprescindible cuando tenemos un diseño responsive y en ella dependiendo de los parámetros podemos habilitar/inhabilitar el zoom, definir el tamaño de pantalla así como el zoom predeterminado. Curiosamente desarrollando una pequeña aplicación nativa para iPad en la que el tamaño del viewport era de 320px por 480px no renderizaba a esa medida. No podía cambiar el tamaño porque el web view (www) se que quedaba fijo y se perdía la plantilla responsive, por lo tanto para que funcionase tuve que remover width=device-width como parámetro o pasar width=100% cosa que no tiene mucho sentido.

En resumen, si estáis desarrollando una aplicación nativa que “embeba” una aplicación web responsive, hay que revisar los parámetros de la <meta> etiqueta viewport.

Empieza por entender como funciona..

<meta name=”viewport” content=”width=device-width, initial-scale=1.0″/>

Para más información siempre estarán nuestros “compañeros” de W3C.

framework o no framework

¿Framework para HTML? ¿Por qué y cuando? Utilizar un framework siempre trae ventajas pero también un coste de desarrollo y cierta curva de aprendizaje. Un buén comienzo es identificar el problema a solucionar, es decir, ¿estamos hablando de una aplicación web de un par de páginas? ¿es un aplicación dinámica con alto volumen de datos y diferentes vistas o diseños? En definitiva, el número de vistas (Llamemos las cosas por su nombre) es directamente proporcional a la posibilidad de utilizar un framework o no.

Caso práctico. Una Web personal; ¿Cuántos diseños, layouts, colores y tecnologías han pasado por tu cabeza a la hora de crear tu sitio personal? Si no sabes como de grande va a ser el problema,  mejor que no pierdas el tiempo codificando <!DOCTYPE html> y empieza a utilizar un framework.  

“No hay peor cosa que un fallo de diseño para acabar con un proyecto de software”