Etiqueta: html

  • HTML vs XHTML

    Diferencia entre HTML y XHTML

    Antecedentes

    Nosotros como Mafalda debemos ser curiosos  (Esperemos que el Sr. Quino por favor no me demande, !es por una buena causa!.)

    Esta es una de las preguntas más comunes a las que todo desarrollador web llega en sus inicios ¿cuál es la diferencia entre HTML y XHTML?, para aquellos con suficiente experiencia, la respuesta es sencilla y puede parecer obvia, pero la verdad es que para las personas que comienzan a sumergirse dentro del desarrollo web, es de hecho una muy buena pregunta ,que se ha de contestar en esta ocasión :).

    A finales de 1994 Berners-Lee fundó el World Wide Web Consortium (W3C), para desarrollar y distribuir estándares para las tecnologías web, comenzando con HTML. Las primeras versiones de HTML fueron aprobadas a lo largo de la década de los 90s.  En 1999 se aprobó la versión HTML 4.01 y más tarde en 2001 se creo su redefinición utilizando XML conocido como estádar XHTML1.0 para finalmente ser aprobado y recomendado por la W3C en Mayo de ese mismo año y conocido como el estándar XHTML1.1.

    Con peras y manzanas por favor…

    Un archivo HTML es básicamente un archivo de texto común y corriente, en el se colocan una serie de etiquetas (o tags) que tienen sentido para un servidor web y para los navegadores que interpretan su contenido para finalmente mostrarlo al usuario. Sin embargo, las reglas que utiliza un navegador para interpretar un archivo HTML no son precisamente estrictas, por lo que a veces al creador de un documento HTML se le “perdonan” algunas imprecisiones e incluso errores. Esto puede parecer una ventaja, pero en muchos casos el programador de páginas debería de darse cuenta de algunos de estos errores que pueden quedar desapercibidos gracias a la permisibilidad otorgada por HTML, o simplemente se pueden generar malos hábitos de programación junto con algunas ideas erróneas.

    Los beneficios de XHTML

    Es para corregir esta situación que se crea XHTML acrónimo en inglés de eXtensible Hypertext Markup Language, que inicialmente comenzó a tratar a HTML simplemente como un documento XML, y como tal debe cumplir reglas más estrictas en cuanto a la escritura de tags o etiquetas, es decir, se debe ser sintáctimente correcto (todo en minúsculas, elementos correctamente cerrados, etc.), como por ejemplo, una etiqueta de quiebre de línea: si escribimos <br> en el esquema permisivo de HTML no habrá  ningún problema, pero si de la misma manera se coloca dentro del formato XHTML ese código será incorrecto, por lo que se debe escribe <br />, es decir, se debe cerrar el elemento como sucede en un archivo XML.

    Esencialmente XHTML busca que los programadores creen documentos sintácticamente correctos y con esto lograr código más limpio, correcto, consistente de mejor legibilidad. Para que todo tenga sentido, adicionalmente se debe especificar el tipo MIME de documentos creados como XHTMLs, mientras que para un documento HTML el tipo MIME es text/html para un XHTML es application/xhtml+xml.

    Adicionalmente durante la evolución de XHTML se integró la validación contra un DTD, que no es más que otro documento XML que  colecciona los elementos (etiquetas) válidos en un XHTML, si algo no está bien escrito editores modernos pueden señalar el error para que el programador se dé cuenta e haga las correcciones necesarias.

    A usar todos XHTML….o no

    Hasta aquí cualquiera podría pensar: OK entonces hagamos todo en XHTML, pero durante la existencia de XHTML este siempre tuvo el problema de que varios servidores web no generaban el código escrito con el tipo MIME application/xhtml+xml  sino simplemente como text/html , o peor aun, los programadores de páginas web a pesar de respetar las reglas sintácticas de XHTML simplemente no señalaban el tipo application/xhtml+xml, lo cual causa que los documentos sigan siendo tratados con el tipo text/html. Sumado a esto, la validación con el DTD no garantiza que la página en cuestión sea corregida ya que a pesar de señalar algún error, si el programador no lo soluciona la mayoría de los navegadores simplemente interpretarán ese código permisivamente, justo como pasa con el HTML común.

    Debido a lo anterior XHTML realmente nunca funcionó como un real sustituto de HTML (que era lo que se buscaba), la W3C intentó seguir evolucionando XHTML con una versión 2 pero con la llegada de la especificación HTML5 desistió de ello, incluyendo en HTML5 muchas de los requerimiento sintácticos de XHTML.

    El futuro de XHTML

    Los que ya están en el camino de HTML5 podrán decir:  ¿pero que hay de XHTML5?, efectivamente existe XHTML5, pero este NO es exactamente una evolución del XHTML antiguo (no hubo versión 2, 3 ni 4 de XHTML), pero sí hay relación en el sentido de que XHTML5 trata al código HTML5 como un XML y lo valida como tal por lo que hay que cumplir con lo que exige un XML. Pero el real objetivo apunta a otro lado, las W3C ha hecho mucho énfasis en la semántica de HTML5 lo cuál se fortalece al serializar un archivo HTML5 como un XML, esto significa que si un archivo está serializado, facilita a aplicaciones externas (motores de búsqueda, programas de accesibilidad, etc.) la interpretación modular (o por partes) de los documentos que creamos.

    Lo anterior quizá se oye más complejo de lo que es en realidad es, pero piense lo siguiente, digamos que usted requiere crear un programa que analice solo una parte del contenido de una página web. Si analiza el código de esa página web como texto plano usted requiere hacer mucho código de manejo de cadenas para extraer la parte que le interesa. En cambio, si el documentos viene serializado como un XML usted puede hacer uso de recursos como Xpath (por ejemplo) para extraer la parte  que le interesa con mucha más facilidad. De esta forma usted puede facilitar la explotación del contenido de una página para usted o para terceros.

    Creo que por el momento esto es lo que hay en el pasado y en el horizonte de XHTML y HTML en términos generales, pero ahora que conoce la diferencia entre ambos la decisión de cual usar es totalmente suya, sin embargo recuerde que HTML5 (y XHTML5) a la fecha se sigue desarrollando y el soporte por parte de los navegadores también, de manera que siempre debemos estar atentos a cualquier cambio.

    Enlaces que pueden interesarle:

    Arrancar con HTML5 Curso de Programación (Libro gratis)

    HTML (Mozilla group)

    HTML and XHTML

    Libros que pueden ser de su interés:

    No Comment
  • Flash VS HTML5

    Flash VS HTML5 (Parte 4)

    Que se pongan de pie todas las personas que alguna vez han querido ver algún video, y repentinamente hayan comentado algo como “oye, se escucha, pero no se ve”, y después de un rato de experimentar, preguntar e indagar llegan a la conclusión de que “falta el bendito codec”.

    Situaciones como estas existen prácticamente desde que la computadoras permiten ver video, pero en estos días este tema aflora con nueva fuerza,  debido al contexto del video en la Web dentro de la nueva especificación HTML5, que incluye el nuevo elemento <video>, el cual permite añadir este tipo de contenido fácilmente sin requerir plug-ins de terceros, como lo es el Flash Player entre otros.

    Diferencia entre FORMATO DE ARCHIVO DE VIDEO y CODEC.

    Primero aclararé un punto de confusión tremendamente común, siempre que puedo lo hago porque, de verdad, existe una graaaaan confusión al respecto entre los consumidores de video.

    Los formatos de archivo de video como .mov, .avi, .rm, .flv, etc., solo son el formato contenedor de la información de un video, pero este formato ¡NO es el codec ni de imagen, ni de audio para ver el video!. Para aclarar esto me auxilio constantemente del archivo de compresión .zip, si usted desea guardar cualquier tipo de archivo en en un formato de compresión como ZIP,  simplemente incluye este contenido dentro de un archivo con extensión .zip y no se preocupa si tal contenido son imágenes, archivos .doc, archivos .pdf o cualquier otra cosa. Cuando otra persona descomprime ese archivo .zip  puede obtener los archivos guardados dentro, y dependerá de si esta otra persona cuenta con Word para ver los archivos .doc, o Adobe Reader para ver archivos .pdf, de no contar con las herramientas necesarias para ver los archivos enviados dentro del archivo .zip no será posible verlos aunque cuente con los archivos completos y correctos.

    Hablando de video, el equivalente al archivo .zip son los archivos en formato avi, mov, flv, etc., estos son solo el formato del archivo contenedor, dentro se almacena información codifica para los cuadros que forman un video, y la información codificada que corresponde al audio, para decodificar esta información requerimos del codec apropiado. Si no contamos con los codecs indicados para el video y el audio, no será posible ver el video en cuestión correctamente aunque el video persé no tenga ningún problema, así como sucedería si no contamos con Word para ver el archivo .doc en el ejemplo del archivo .zip.

    La parte más inconveniente en lo que respecta al video en HTML5 es que estamos en medio de una nueva “guerra de navegadores” y los fabricantes no se han puesto de acuerdo acerca de cual deber ser el formato estándar para desplegar video y por lo tanto tampoco de cuales codecs deberían ser usados. Por lo que debemos estar pendientes de que navegador es compatible con que codecs de video (la wikipedia cuenta con una sección que se ha actualizado recurrentemente)

    ¿Cómo funciona?

    No describiré demasiado como insertar un video flash en una página, ya que dada la longeva presencia de flash existe una gran cantidad de recursos donde se enseña como hacer esto con gran detalle. La novedad por el momento recae más en la etiqueta <video> que busca trabajar casi con la misma facilidad con que lo hace la etiqueta <img>, el elemento video cuentan con varios atributos como src, control, autoplay, width, height, poster y otros más:

    <video src="video.mp4" width="360" height="240" controls="controls">
    </video>

    ¿Qué formato utilizar?

    No se cuenta aun con un formato universal e infalible para todos los navegadores, pero podemos utilizar múltiples formatos en la misma etiqueta video, en caso de que el navegador no reconozca un formato se irá al siguiente:

    <video controls width="350" height="250">
     <source src="video.ogv" type="video/ogg" />
     <source src="video.mp4" type="video/mp4" />
    </video>

    ¿Qué hacer si el navegador no soporta ningún formato?

    Si el navegador no soporta ninguno de los formatos que se han colocado siempre se puede colocar el video en formarto Flash y verlos de esa manera:

    <video controls width="350" height="250" >
        <source src="video.ogv" type="video/ogg" />
        <source src="video.mp4" type="video/mp4" />    
        

    http://player.swf?file=video.mp4

    
    </video>

    Al momento algunos navegadores responden mejor que otros al elemento video, y muchas personas utilizan navegadores viejos, para estos casos Flash es todavía una buena alternativa, aunque la tendencia parece indicar que el elemento video se consolidará cada vez más poco a poco.

    La comparación

    Cuando se trata de video, HTML5 en general tiene mejor rendimiento en términos de consumo de recursos y más fácil de implementar cuando hablamos de código, pero por el momento la distribución de Flash es mayor y funciona igual en todos los navegadores una vez que estos tienen el plug-in instalado. Flash tiene manejo de pantalla a tamaño completo, HTML5 no por el momento, aunque se sabe que se trabaja sobre ello. Flash soporta video en streaming, HTML5 lo hará en el futuro pero por ahora no lo puede hacer.

    Todas las desventajas del video en HTML5 sobre Flash parecen ser temporales y a esto se suma que Adobe anunció recientemente (Nov 2011), que ya no habrá desarrollo de Flash para móviles, veremos que pasa!

    Ir a parte 3       Ir a parte 5

    No Comment
  • Flash VS HTML5

    Flash VS HTML5 (Parte 3)

    Por alguna razón mucha gente buscamos que haya buenos y malos en muchas situaciones, casi sin cuestionamiento el títlo de bueno se le ha dado a HTML5, los malos Flash y Silverligth y si desea agregar el feo quizá una vez más Silverlight.

    La realidad es que no hay bandos reales, lo que tenemos son más opciones y eso es lo que hay que aprovechar. Por supuesto habrá situaciones donde hay que elegir, y para tomar decisiones hay que conocer algunas características de nuestras alternativas:

    Animación.

    Flash.

    Primero hay que estar al tanto que Flash nació como una herramienta de animación en un sentido más tradicional, la primera herramienta que creaba contenido Flash era un programa con herramientas del tipo “diseño gráfico” como líneas, círculos, rectángulos, bote de pintura, etc., y con una línea de tiempo para colocar las figuras dibujadas frame a frame y manipularlas de acuerdo a lo que se deseaba.

    Flash ha evolucionado y ya no cuenta con una sola herramienta para crear contenido, Flash ya no solo está orientado a sólo a hacer animaciones “artísticas o experimentales” si no que inclinado a ser un verdadero framework para crear aplicaciones conocidas como RIAs (Rich Internet Aplications), en estas puede combinar diferentes grados de animación.

    Ventajas:

    • Hacer y animar fluidamente dibujos de trazo libre es amable y fácil.
    • Hay una amplia comunidad desarrollo.
    • Existe mucha documentación libre y de pago.
    • Adobe está constantemente mejorando esta tecnología.
    • Los resultados visuales que se pueden obtener son realmente de muy alta calidad.

    Desventajas:

    • Se require de un plug-in de tercero instalado para ver contenido Flash.
    • La versión del plug-in puede ser un factor problemático para usuarios y desarrolladores.
    • El contenido Flash no es indexable, esto dificulta que los buscadores y otras herramientas  ubiquen, interpreten y clasifiquen su contenido.
    • Además  de conocer HTML, JavaScript, CSS, etc., hay que aprender ActionScript y múltiples herramientas para explotar verdaderamente el potencial de Flash.
    • Los elementos más interesantes de la plataforma Flash son propietarios, por lo tanto tienen costo.

    HTML5

    La animación en HTML5 cuenta con varias alternativas para ser creada, puede usar solo JavaScript y CSS3, puede utilizar el elemento Canvas o la tecnología SVG. Todos estas alternativas han sido creadas desde un punto de vista programático, es decir, siempre se pensó en crear animaciones utilizando código de programación y no una  herramienta de diseño con una interfaz de usuario.

    HTML5 se encuentra evolucionando rápidamente y mucha gente está prestando atención, la misma compañía dueña de Flash ha estado experimentando con las posibilidades de este nuevo estándar y proponiendo cosas, como la importación de contenido desde la aplicación Adobe Flash a HTML5, la creación de Adobe Edge (que si me preguntan es un intento de hacer de HTML5 lo que Flash fue originalmente) , entre otras cosas.

    Ventajas:

    • Todo es libre y gratuito.
    • No existe necesidad de utilizar plug-ins.
    • Una rápidamente creciente comunidad de desarrollo y documentación.
    • La indexación de contenido combinado con la fuerte semántica de HTML5 van de la mano de gran manera.

    Desventajas:

    • HTML5 no es lo más conveniente para la animación detallada y fluida (del tipo dibujo animado) por ahora.
    • HTML5 no es una especificación terminada, por lo que hay cosas que aún no están concluidas o son experimentales.
    • No todos los navegadores soportan todas las características de HTML5 o no las soportan de igual manera.
    • HTML5 no tiene aún buenas alternativas que sean amables con diseñadores gráficos.

    Cuando hablamos de animación, el consumo de recursos es un punto donde se critica mucho a Flash, pero tengo que admitir que Adobe se está esforzando mucho en este sentido y HTML5 aunque promete en este tema, tiene sus bemoles en ciertas circunstancias, habrá que esperar un poco para definir este punto con claridad.

    Conclusiones:

    Si desea hacer animaciones con trazos libres, que no requieren demasiada programación pero si mucho trabajo gráfico y deben ser de gran fluidez, mi recomendación es Flash.

    Si desea hacer aplicaciones de escritorio con moderado grado de animación y muy  buena presentación, considere utilizar AIR , si desea importar estas aplicaciones a la web o viceversa Flex es una buena opción (estas tecnologías son parte de la plataforma Flash).

    Si desea hacer aplicaciones web con moderado grado de animación y desea familiarizarse con los estándares del futuro vale la pena dedicarle tiempo a HTML5.

    Si el presupuesto es un problema, los estándares libres siempre son una interesante opción, es claro que HTML5 brilla en este caso.

    En la siguiente parte de esta serie de posts abordaré ventajas y desventaja de estas tecnologías desde el punto de vista de video.

    Ir a parte 2         Ir a parte 4

    No Comment
  • Flash VS HTML5

    Flash VS HTML5 (Parte 2)

    En la entrada anterior hablé de la tecnología Flash y un poco de su historia, con el fin de comprender mejor de que va Flash desde su inicio. Ahora le toca el turno al famoso y esperado HTML5. De unos dos años para acá se ha hecho mucho escándalo alrededor del flamante HTML5, y con razón, ya que presenta muchas nuevas y prometedoras características.

    He observado que muchas persona caen en una impresición similar a cuando se habla de Flash, es decir se habla de HTML5 como un todo, como una especie de entidad única que merodea en la Web creando páginas interesantes. La verdad es que HTML5 es algo que viene acompañado de varías tecnologías con las cuales se complementa para poder funcionar.

    HTML5 es únicamente la especificación más nueva, publicada por la W3C para HTML, el lenguaje base para crear páginas Web. La especificación define como deberían escribirse las etiquetas o tags que instancian un elemento HTML en nuestras páginas, que atributos y eventos poseen. Eso es todo, y lo más curios de todo es que ni siquiera es una especificación completa ni terminada, pero entonces ¿por qué tanto escándalo? :

    HTML5 es más rigorista.

    Anteriormente si se escribía una página HTML podía caer en errores de escritura, combinar mayúsculas y minúsculas en el código, no cerrar etiquetas que requerían cierre, ignorar tipos MIME, entre otras cosas de mal gusto para programadores exigentes, y las páginas en muchos casos aún se veían como se esperaba, haciéndonos olvidar todos los errores cometidos y creando malos hábitos. Para intentar solucionar esto se creó XHTML, pero nunca fue ciento por ciento adoptado por todos los desarrolladores. HTML5 intenta recuperar el espíritu de precisión de XHTML, mantener la familiaridad de HTML y unificarlo todo en la nueva especificación HTML5 (en el futuro crearé un post para hablar de XHTML2 y XHTML5 que tienen su historia, pero me lo guardo para no salir de contexto).

    El énfasis en la semántica en el código HTML es realmente notable e incluso abrumador cuando se comienza a desarrollar.

    Nuevas etiquetas para formularios.

    Tengo la impresión de que este punto no es muy mencionado pero a mi me parece importante porque puede ahorrar tiempo y costos. HTML5 incluye una nueva serie de etiquetas para colocar nuevos controles para formularios, por ejemplo, barras de progreso, campos de texto que filtran números y patrones, campos de texto que validan direcciones de correo y URLs, campos de texto que muestra color pickers y calendarios, entre otros más. Este tipo de controles requerían de programación y tiempo extra o incluso de comprar controles de terceros, pero HTML5 lo incluye de entrada.

    Nuevas etiquetas para contenido multimedia.

    Este aspecto en realidad al que la mayoría de la gente se refiere cuando habla de HTML5. La nueva especificación propone nuevas etiquetas para colocar audio y video de manera nativa sin el uso de plug-ins de terceros y/o propietarios, como justamente son el Flash Player o el reproductor de contenido Silverlight.

    Pone sobre la mesa el elemento Canvas, que es justamente uno de los recursos principales para crear animaciones con gráficos vectoriales e imágenes, sin embargo esto se hace hoy por hoy principalmente de manera programática, nótese esto porque será un punto importante para el encuentro mano a mano entre Flash y HTML5 para la tercera parte de la entrega de posts.

    CSS3 y JavaScript.

    Tecnologías sin las cuales HTML5 no podría hacer algo mínimamente  interesante  y que se encuetran evolucionando paralelamente al mismo HTML5. Esto es algo sumamente importante, ya que antes de alguien pueda pensar en que aprender HTML5 solo es conocer algunas etiquetas nuevas, la realidad es que si aspira a desarrollar con HTML5 debe aprender la nueva especificación para hojas de estilo nivel 3 o CSS3 y los nuevos recurso JavaScript. Combinando etiquetas HTML5, CSS3 y JavaScript se puede lograr una mucho mejor manipulación del aspecto y comportamiento de elementos HTML que nunca antes, logrando una mejor estética en nuestras páginas y en nuestro código al separar programación estructural de programación visual.

    Web sockets y Web workers.

    No hablaré mucho de esto, solo diré que aquellos gurús adentrados en programación con sockets y la programación por hilos tienen en HTML5 algo muy interesante por revisar.

    En la próxima entrada ¡comenzarán los verdaderos golpes!

    Ir a parte 1            Ir a parte 3

    No Comment
  • Flash VS HTML5

    Flash VS HTML5 (Parte 1)

    No se trata de una guerra, ni de una pelea, de hecho consideré titular esta entrada como Flash y HTML5 pero me pareció que el “versus” sería más provocador para los “fanboys“.  Personalmente creo que Flash se ha ganado el lugar que tiene en la Web, pero esto no quiere decir que siempre estará ahí, que siempre será la mejor o la única opción.

    Últimamente de manera continua algunas personas, que comienzan a desarrollar,  me han preguntado que es mejor y al mismo tiempo me he dado cuenta de algunas confusiones en el tema, de manera que decidí hacer una serie posts abordando el asunto y  esperando despejar algunas dudas a quienes desean desarrollar con estas tecnologías.

    Flash:

    Aveces se menciona a Flash como un todo, pero en realidad hay varias partes involucradas. Flash surgió como una tecnología  propuesta por la compañía Macromedia a finales de los 90s, que permitía desplegar gráficos vectoriales en páginas Web, Flash consta básicamente de un plug-in instalado en el navegador de un usuario que permite el despliegue de contenido elaborado en este formato, a esto se le conoce como Flash Player. Al mismo tiempo que Flash Player Macromedia creó la herramienta con la que originalmente se podía crear este tipo de contenido, esta herramienta fue concebida como un software de animación para crear contenido destinado principalmente a la Web, este software se le llamaba simplemente Flash.

    El Flash y el Flash Player han ido evolucionando lo largo de los años, durante este tiempo Macromedia liberó parte de su tecnología para permitir a terceros crear contenido SWF (el formato que comprende Flash Player), e esto se agregó la posibilidad de incluir video en formato FLV el cuál también se visualiza gracias a Flash Player. Otra parte importante de Flash es su script de desarrollo conocido como ActionScript el cuál también ha tenido cambios importantes.

    En 2005 la compañía Adobe (dueños de Photoshop) adquiere a Macromedia, con esto también vinieron cambios sobre Flash, la herramienta de autoría ahora se conoce como Adobe Flash Professional y surge también la nueva versión de su script el popular ActionScript3, el cuál introduce al desarrollo con Flash verdadera programación orientada a objetos.

    Una de las mayores limitantes de Flash ha sido su pobre interacción con datos y su poco practicidad para crear aplicaciones que buscaban más productividad y un tanto menos de animación como tal, manteniéndose aún sobre la Web pero considerando  también aplicaciones de escritorio. Adobe consciente de esto crea Flex y AIR, un conjunto de tecnologías que también crean contenido Flash pero con mejores capacidades en cuanto al desarrollo con el manejo de datos, y más orientada al desarrollo tradicional de aplicaciones.

    Las  grandes desventajas de las tecnologías basadas en Flash siempre han estado relacionadas con el rendimiento en general, el consumos de recursos y algunos temas de seguridad. Factores que hay que considerar antes de crear una aplicación.

    En la siguiente parte de esta entrada abordaré al novedoso HTML5…..

    Ir a parte 2

    1 Comment