Semántica en HTML 5
July 16th, 2009
Nunca tuve tiempo de meter la cabeza de lleno en toda esta historia del XHTML 2 y el HTML 5. Nunca entendí la diversificación en dos ramas de desarrollo. Aunque, emocionalmente, y sin documentarme demasiado, me he sentido siempre ligado a la idea de una mejora y ampliación del XHTML actual, ya que, el mero concepto de HTML 5 era una declaración de intenciones en sentido contrario a XHTML. Una postura que me parece altamente injusta.
Finalmente, como sabemos, HTML 5 ganó la batalla. O más bien XHTML 2 la perdió.
A raíz de un artículo de Zeldman se ha generado un debate apasionante sobre la semántica en HTML 5, suscitado en parte por un artículo de John Allsopp en ALA titulado Semantics in HTML 5. Tanto el artículo de Zeldman, los comentarios del mismo, como el propio artículo de Allsopp son de lectura obligatoria para los apasionados de la semántica, como yo.
Yo estoy al 100% con la opinión, bien argumentada, de John Allsopp, que viene a criticar duramente la aparición en HTML 5 de elementos “estructurales” en el etiquetado.
Voy a explicar un poco por encima (porque tiene tela) la polémica centrándome en el ejemplo que a su vez más se ha utilizado el debate: la etiqueta nav para menús de navegación (No es que la etiqueta nav sea el problema, pero se presta a varios ejemplos)
Una de las críticas llega por el lado de la no multidisciplinaridad de los nuevos elementos y la no extensibilidad de los mismos.
Actualmente, para los menús de navegación utilizamos listas no ordenadas. Un menú no es más que eso: un listado no ordenado de enlaces. La semántica se la aplicamos mediante ids y classes. Obviamente no es una semántica estandarizada, si no más bien una pseudo-semántica enfocada principalmente a asignar estilos y funcionalidades. Esto ocurre porque no existen unos patrones semánticos, aunque en todo caso, ni id ni class fueron creados para ir más allá de lo mencionado. El problema es que no hay establecidos, por tanto, mecanismos para que los agentes de usuario identifiquen cuando un listado de enlaces se trata de un menú de navegación o un simple listado de enlaces o, por ejemplo, de qué tipo de menú de navegación se trata.
Inciso: Los Microformatos, por ejemplo, han tratado con cierto éxito de ir un poco más allá en la actual pseudosemántica, estableciendo unos patrones, que sin ser estándares oficiales son interpretados por aplicaciones y o agentes de usuario preparados a tal efecto. Una aproximación a la semántica que necesitamos.
Pero, volviendo a lo que comentaba, y siguiendo con el elemento nav, la aparición del mismo implica envolver un elemento semántico ya existente (ul) con una etiqueta nav para indicar que el listado interior se trata de un menú de navegación. Pero entonces, ¿Es esta toda la función del elemento nav? ¿Envolver a otro? ¿Es esto necesario? ¿Por qué no puede ser el propio elemento ul el que se autoidentifique como elemento de navegación de una manera semántica? ¿O por qué no puede ser un elemento ya existente y perfectamente válido, como div, el que lo haga de forma también semántica?
Los auténticos problemas llegan con la no multidisciplinaridad, ¿Qué ocurre si un menú de navegación cumple semánticamente con la misión de menú de navegación, pero además cumple otras misiones? Por ejemplo, un menú de navegación puede ser menú de navegación, pero a la vez un mapa del sitio (que, de por si, puede ser perfectamente un elemento estructural perfectamente válido y catalogable). En ese caso, si quisiéramos darle ese doble valor semántico a ese elemento ¿Cómo lo haríamos? ¿Envolviendo uno dentro del otro? ¿Cuál dentro de cuál? Esto sería, desde mi punto de vista, parchear el parche con soluciones más propias de hace 20 años que de la actualidad.
Creando nuevos elementos semánticos estructurales, como los propuestos actualmente en HTML 5, estamos asumiendo que dichos elementos han de cumplir exclusivamente un único objetivo semántico. Haciendo esto, ¿no estatamos limitando la semántica desde ya e hipotecando la futura?
Pero Allsopp no solo critica, si no que propone soluciones, que no solo cumplen con el requisito de la multidisciplinaridad semántica, si no que además cumplen con la compatibilidad hacia atrás, cosa que con los nuevos elementos no sucede, y además lo harían con la compatibilidad hacia atrás en el futuro (fordward compatibility).
¿La solución? Simple. Olvidarnos de nuevos elementos y enfocarnos hacia atributos estructurales y/o relativos al rol que, funcionando de manera similar a las clases, permitan asignar semántica a los elementos ya existentes en el XHTML actual. Ejemplo:
<div structure=”navigation”>
O el ya propuesto role:
<ul role=”navigation sitemap”>
Una solución sin parches, sólida, global, compatible, flexible y extensible.
Por otro lado, otra de las críticas, directamente relacionada con la que acabo de comentar, es la escasa visión que se está aplicando con los nuevos elemento. Ya que lo que se está haciendo es establecer una semántica enfocada a los elementos con mayor presencia en la actualidad, es decir, los necesarios a día de hoy. Pero no se está pensando en una solución global flexible en el tiempo.
Sin embargo, irónicamente, y esta es otra crítica aplastante, según HTML 5, un elemento estructural no puede albergar a otro elemento estructural. Sin comentarios. Es decir, que por ejemplo un elemento nav no podría estar dentro de un elemento header. Como destaca mi admirado Andy Clarke (Oops! Sure I do know who you are! – I’m the one in the left – Just wanted to check that you were paying attention!) Andy Clarke de entre los comentarios de Allsopp: html 5 is a mess (¡un desastre!). Y como responde el propio Allsopp a los chicos HTML 5:
“Try turning some non trivial sites into HTML 5 based markup. […] Why can’t a header include a nav element?”.
Viniendo a decir algo como: “¡Venga! Tratad de hacer una web actual con vuestras absurdas (arreglo floral mío) especificaciones.”
¿No es un contrasentido absoluto hacer unas especificaciones centradas ciegamente en las necesidades de hoy, pero que ni tan siquiera servirían hoy?
Pero el colmo de los colmos llega con la increible y aplastante respuesta (para mi de desesperación) de Ian Hickson (editor de las especificaciones de HTML 5) a alguno de estas críticas muy fundamentadas en el hilo de discusión abierto en la web de Zeldman:
We don’t need to predict the future. When the future comes, we can just fix HTML again.
Una auténtica perla que ha avivado el debate hasta límites insospechados y ha dejado entreveer, no solo que la ideología detrás de HTML 5 parece ser cortoplacista, autocomplaciente y carente de sentido y argumentos, si no que desde el punto de vista semántico HTML 5 está cogido con hilos y no se está trabajando todo lo seriamente que se debe, tal y como el futuro de la web merece. No olvidemos que de lo que estamos hablando es del próximo estándar para el entorno de comunicación más importante de la humanidad durante las próximas décadas ¿Es este el estilo que necesitamos?
Este artículo tiene 24 comentarios y hay 6 blogs que lo referencian.
Categorizado en: Desarrollo Web, Estándares, Opinión.
#1
20 de July de 2009
Pues yo comparto un poco la visión de HTML5 y de hecho creo que xHTML ha funcionado por “imposición”, pero es otro desastre, que complica mucho el diseño web. En el propio w3c afirman que xHTML es “difícil” para la web.
Entiendo que la web semántica es importante, pero no lo es todo. Tampoco se puede diseñar un estándar pensando en el futuro de una tecnología tan cambiante, precisamente porque ese futuro puede no darse, y podrías estar cerrando la puerta a otra tecnología que si fuera útil. Lo que creo que intenta decir Ian Hickson es precisamente que funciona mejor que el estándar se vaya adaptando a la tecnología. De hecho, es así como ha sido hasta ahora (con la “guerra de los estándares” de navegadores). Sólo las cosas empleadas más frecuentemente han sido realmente útiles y las que permanecen en el estándar. Se trata de hacer HTML5 “ágil” y adaptable con el tiempo.
Bueno, es mi (modesta) opinión. 😉 Realmente no conozco xHTML 2
#2
20 de July de 2009
Hola Jose.
Muchas gracias por el comentario, pero tengo que decir que estoy bastante en desacuerdo contigo.
Es evidente que la semántica no cobra mucha relevancia en según qué entornos. Lo cual es bastante comprensible. A fin de cuentas, “la web” es un ente demasiado grande y, para según que fin, el código HTML no es más que un medio para que se pinte un resultado en el navegador.
Internet es libre y abierto. Cualquiera puede subir sus contenidos, con su código, sacado de un editor WYSIWYG o de cualquier otro oscuro confín
Es totalmente comprensible.
Pero en entornos profesionales, institucionales y corporativos, la semántica no lo es todo, pero es crucial. Más bien, debería serlo. Y digo debería porque por desgracia no ha trascendido lo que se merece. Pero si no lo ha hecho es porque no hay demasiadas personas con la formación adecuada, como para que, en general, se asimile su importancia.
Por otro lado, ¿El xhtml complica el diseño web? La cuestión es, lo complica ¿con respecto a qué? ¿cómo debería ser el “diseño web”? La programación de webs tiene que ser todo lo complicada que tenga que ser para cumplir una serie de objetivos. No todo el mundo puede/debe ser “diseñador web”, al igual que no todo el mundo puede/debe ser dentista o arquitecto.
Al final es todo una mera cuestión de formación (casi inexistente o inadecuada) y, de hecho, la escasa implantación de XHTML, y la lenta progresión que ha tenido, proviene precisamente de esto.
Por otro lado ¿El estándar debe adaptarse a la tecnología? No. El estándar debe adaptarse a las necesidades de las personas. La tecnología es solo una plataforma. El estándar debe ofrecer las mejores y máximas posibilidades para que el resultado final del producto “la web” sea el mejor posible para las personas que van a utilizarlo.
En todo caso, como comentaba, HTML 5 traerá cosas buenas, por supuesto, pero también cosas malas. Y la cuestión es ¿Qué motivo hay para incoporar cosas malas cuando podría no hacerse?
La excusa para olvidarnos de cosas excelentes que ha traído XHTML, y por las que muchos hemos luchado tanto, no puede ser “que no han funcionado”.
Los derechos humanos tampoco han funcionado, cada día se atropellan los de millones de personas. Pero, como no han funcionado ¿Qué hacemos? ¿Los quitamos? ¿O, por el contrario, seguimos luchando por ellos, y los potenciamos para que algún día sean lo que tienen que ser?
#3
26 de July de 2009
Estoy totalmente de acuerdo con Julio
#4
27 de July de 2009
Hola de nuevo.
Entiendo tu postura, pero quería matizar, precisamente, que hay más lenguajes (incluso dentro de XML más especificaciones) orientadas a ontologías y a especificaciones de contenido semántico. Si quisieramos una web “semántica”, ¿por qué no usar uno de esos lenguajes de marcas (que son tb. XML) en vez de xHTML? Pienso que xHTML quiso cubrir un hueco y hacer de puente entre dos mundos, pero para algunos diseñadores web, ha sido una pesadilla.
Algunas observaciones: “La programación de webs tiene que ser todo lo complicada que tenga que ser para cumplir una serie de objetivos.” Eso no es lo que pregona precisamente W3C, son su idea de la sencillez. Precisamente, el hecho de que sea complicado es lo que hace que tarde en implantarse como tú mismo has dicho (yo no soy diseñador web, por cierto, pero entiendo perfectamente las quejas de los diseñadores). No es sólo un cuestión de formación, es cuestión de que aparezca una tecnología mejor (y una de sus características será precisamente, su sencillez).
Lo que quiero decir es que cuando se separa “presentación” de “contenido” a veces se comete un error, porque resulta que la “presentación” (la disposición de los datos) es a su vez *información*. Por ejemplo, si yo comprimiera todo lo que escribo quitando espacios, seguiría siendo un texto inteligible, pero mucho más difícil de leer. Se ha quitado parte de la información, que es la presentación (los espacios que delimitan párrafos y palabras).
La gente como tú está empecinada en lo que “debería”. Pero ya ves como es internet, las cosas no son “como deben”. Simplemente son por cómo las usa la mayoría. El mayor error de XHTML fue declararlo un “estándar” antes de usarlo y no al revés. Los estándares que funcionan son los de facto, es decir, aquellos que, debido a su uso masivo y omnipresente, se terminan convirtiendo en tales. Eso es USABILIDAD. Y xHTML con sus “Object” para suplir todas sus carencias de presentación, que además, requiere de una sintaxis compleja para poder abarcar todos los navegadores, es un ejemplo claro de que no.
La web, por definición, y digo la web, no “Internet” es un medio audiovisual (o multimedia, si quieres). Un lenguaje que no de facilidades para eso, no es un lenguaje de web. Puede ser un lenguaje orientado a la semántica o lo que quieras, pero no orientado a la web: Por eso al tándem XHTML + CSS (que no vale) siempre se le añade Javascript. Algún día, eso terminará: Surgirá un lenguaje de web que permita páginas dinámicas sin necesidad de ayudas externas. Lo otro son parches (incluido los tags metidos “a mano” para dar metainformación semántica).
Yo soy de los que piensan (hay una corriente en internet que opina así) que la web semántica será inútil cuando las máquinas tengan la suficiente inteligencia artificial (que la tendrán) para leer un texto como tú y como yo y saber perfectamente de “qué trata” si necesidad de muletillas (tags).
#5
31 de July de 2009
@Jose:
Muchas gracias por aportar tanto al debate. Si abrí un blog fue precisamente para esto. Creo que es muy enriquecedor.
Te contesto.
En parte hay cosas para las que creo que te podrías dar por respondido con lo último que he escrito sobre XHTML. Échale un vistazo si quieres, pero te aseguro que lo escribí sin haber leido todavía tu comentario 😀
¿Qué es exactamente lo que ha sido una pesadilla? Necesito un ejemplo claro de a lo que te refieres. Si hablamos de pesadilla podríamos hablar, como no, de IE, y especialmente de IE 6, y precisamente, entre otras cosas por el lamentable soporte dado por el mismo a los estándares. Pero al margen de IE, ¿Qué ha sido una pesadilla? ¿Javascript? Pues sí, estaría completamente de acuerdo contigo, pero hablamos de XHTML y CSS, ¿no?
Me reafirmo en mi comentario, tiene que ser todo lo complicado que tenga ser para cumplir con su cometido. En su momento cuando un pie se empezaba a poner negro lo cortaban ¡Zas! Era la tecnología del momento. Realmente es una tecnología bastante más “simple” y menos “complicada” que la actual: Medicamentos, aparatos complejos, cirugía, … No podrás negar que la actual es bastante mejor.
Quizá estás confundiendo la tecnología desde fuera con la tecnología desde dentro. Hay mucha más tecnología, e infinitamente más compleja, en un iPod que en una radio de finales de siglo XIX. Y obviamente es mucho mejor y más fácil de usar un iPod.
Pero llegar a un iPod no es nada fácil, en el camino hay una cadena de expertos en múltiples disciplinas y una evolución tecnológica descomunal.
Los scripts o lenguajes de programación para web no son para el público final. Facebook es para el público final.
Por supuesto eso no significa, obviamente, que estos lenguajes haya que complicarlo por gusto. Ni mucho menos. Y jamás se me ocurriría pensar una sobervia memez como esa. Pero es ineludible que para hacer cosas complejas se necesiten medios y herramientas relativamente complejas.
Y … sí, mucho me temo que es solo cuestión de formación. Lo complicado es aprender de aquí y de allá, separando el grano de la paja, sin rumbo y sin orden, pero si alguien que lo entiende bien te lo enseña, no es precisamente física cuántica.
Tu ejemplo no es válido en absoluto. Estás hablando de gramática. Los espacios son parte intrínseca de la información. No son presentación, ni mucho menos. A pesar de quitarlos podemos entender el texto por puro raciocinio, por deducción, lógica, e interpretación del contexto, porque somos seres humanos y pensamos.
Pero jamás la disposición de los datos, refiriéndote al orden de palabras, caracteres, ausencia o no espacios, puede ser presentación. Si desordenamos las palabras de un libro desaparecer el sentido del mismo, estamos hablando de otro contenido, no de otra presentación.
Pero no estamos hablando de internet. Ni estamos hablando de gustos, preferencias o tendencias. Estamos hablando de una serie de reglas formales que tienen que definirse tanto para los que desarrollan los agentes de usuario como para los que desarrolan los sitios.
Creo que el ideal del que me hablas, de que las cosas vayan tomando forma por si solas, se llama evolución por selección natural. Sí, la evolución es muy bonita, y muy perfecta, pero tiene un serio problema: es demasiado lenta. Funciona por fuerza bruta. No es precisamente muy práctica cuando necesitamos algo funcional para “ya”.
No puedo ni imaginarme lo que ocurriría si dejamos que los estándares evolucionaran al libre alberío, en base a las ocurrencias y “necesidades” de la gente (¿Te acuerdas de la etiqueta blink?). Bueno, en realidad sí que puedo imaginarlo un poco, ya estaba en esto cuando empezó la guerra de los navegadores … ¡Y eso sí era serio problema!
Eso de lo que hablas se llama caos y desorden. Y la gente como yo está empecinada en que las cosas se hagan con un cierto orden y armonía.
Cuando la inteligencia artificial no requiera de ningún tipo de semántica entiendo que será capaz de interpretar cualquier cosa. Muy bien. En ese momento, por poner un ejemplo, ya no serán necesarias ni las bases de datos tal y como las conocemos, porque dará igual el formato, el origen de dichos datos y todo lo demás ¿No? En ese momento, ¿Existirá la web? ¿Será necesaria? Me da a mi que no. Siguiendo esa lógica, entonces casi que mejor no preocuparnos hasta que llegue ese momento.
Me parece un argumento muy endeble para no hacer las cosas bien y funcionales ahora y durante las próximas décadas.
#6
3 de October de 2009
Excelente artículo Julio. Mi preocupación es cómo nos vamos a arreglar mientras esté la transición entre HTML4 y 5. Si incorporamos la etiqueta NAV que mencionas en el ejemplo, los antiguos navegadores no la leerán. Deberemos recurrir a parches, hacks y trucos para lograr que funcione.
Estoy contigo en que hubiese sido más fácil agregar un descriptor a una etiqueta existe. Inclusive podríamos haber aplicado el atributo TYPE que existe para elementos del formulario y hacer algo tipo:
Un saludo y nuevamente felicitaciones por el texto.
#7
3 de October de 2009
@Seba: Muchas gracias por tu comentario. En realidad la transición será entre XHTML y HTML5 y no la veo nada fácil. A estas alturas, nueve años después, todavía estamos peleándonos con IE 6, así que me parece impensable el periodo de transición en el que haya que satisfacer unos navegadores que soporten HTML5 y otros que no lo soporten. Al final lo que pasará, como bien dice John Allsopp, es que se hará:
<div id="navigation"><nav></nav>
</div>
Lo cual será una sobervia memez, patrocinada por Ian Hickson y compañía, y las ansias por tener algo nuevo YA.
#8
3 de October de 2009
@Julio: Sí, en lugar de una web semántica tendremos una web redundante. Mi idea que no salió en el comentario de arriba era la siguiente:
Item 1
Item 2
Es decir, añadiendo un atributo que ya existía para otro elemento (TYPE) a una etiqueta que hoy en día casi todo el mundo usa para hacer menús (UL) se hubiese solucionado el problema.
Un saludo y gracias por tu respuesta.
#9
3 de October de 2009
A ver si ahora sale…
<ul type="nav">
<li>Item 1...</li>
</ul>
#10
27 de January de 2010
Completamente de acuerdo. Cuanto más leo la especificación, menos entiendo el supuesto sentido semántico de todo esto.
Crean una etiqueta para diferenciar navegaciones, pero seguimos metiendo todo dentro de un , mal vamos, no sólo no ahorramos código (que ahora para SEO por ejemplo, reducir el código va a ser más que recomendable), sino que no hay forma de diferenciar por ejemplo navegaciones globales de locales y a su vez, navegaciones de menús.
Por ejemplo: Podríamos meter dentro de un elemento de esta forma los agentes sabrían que es la navegación global, ¿y si tenemos una navegación de cortesía (idiomas – contacte – acerca de..) dentro de esa cabecera? Quizás podríamos usar la recuperada etiqueta .
Para navegaciones locales podemos usar o pero parece que no se puede aplicar para estos casos precisamente, sino para listas de controles tipo formulario ¿¿??
Luego está el tema de frente a ¿qué es más lógico, que una sección se divida en artículos, o que un artículo se divida en secciones? ¿qué os parece?
Quizás son dudas muy básicas, pero tengo la impresión de que, como dice Julio, todo esto está montado con pinzas y la cosa falla por la base.
#11
27 de January de 2010
Completamente de acuerdo. Cuanto más leo la especificación, menos entiendo el supuesto sentido semántico de todo esto.
Crean una etiqueta para diferenciar navegaciones, pero seguimos metiendo todo dentro de un <ul>, mal vamos, no sólo no ahorramos código (que ahora para SEO por ejemplo, reducir el código va a ser más que recomendable), sino que no hay forma de diferenciar por ejemplo navegaciones globales de locales y a su vez, navegaciones de menús.
Por ejemplo: Podríamos meter dentro de <header> un elemento <nav> de esta forma los agentes sabrían que es la navegación global, ¿y si tenemos una navegación de cortesía (idiomas – contacte – acerca de..) dentro de esa cabecera? Quizás podríamos usar la recuperada etiqueta <menu>.
Para navegaciones locales podemos usar <nav> o <menu> pero parece que <menu> no se puede aplicar para estos casos precisamente, sino para listas de controles tipo formulario ¿¿??
Luego está el tema de <section> frente a <article> ¿qué es más lógico, que una sección se divida en artículos, o que un artículo se divida en secciones? ¿qué os parece?
Quizás son dudas muy básicas, pero tengo la impresión de que, como dice Julio, todo esto está montado con pinzas y la cosa falla por la base.
#12
2 de February de 2010
Vaya, HOY he recibido un correo sobre esto. Me parece increíble que todavía siga esta discusión. En caso, habría que preguntarse por qué Google mismo no usa xHTML (y ahora que ya está muerto menos), y participó en HTML5 (y lo usa ya en youtube), u otras muchas empresas. Pienso que ellas tiene bastante experiencia en el diseño de sistemas web (más que nosotros) y por alguna razón de peso habrán tomado esa decisión (que concuerda con mi punto de vista).
Otro interesante artículo (en inglés) sobre este tema:
http://diveintohtml5.org/past.html#xhtml
Es un libro, en realidad, pero esa sección aclara bastantes cosas, de lo que quería decir.
Y algunos mitos de xHTML:
http://www.webdevout.net/articles/beware-of-xhtml#myths
Por último, pasar de xHTML a HTML5 es relativamente sencillo.
Espero haber aclarado algo. 😉
#13
8 de February de 2010
@Jose.
Bueno, es que el tema da mucho que hablar, y más que dará. No es un asunto que esté cerrado, ni mucho menos.
El hecho de que Google haya participado en HTML5 es por puro interés. Google quiere hacer cosas nuevas (como Wave) que los estándares actuales le complican, limitan o imposibilitan.
Pero que Google apunte a HTML5 no significa que sea la vía buena, significa simplemente que es la vía más corta. Sus razones de peso son económicas.
Pero los estándares no deben depender de ese tipo de cuestiones. Ni se deben improvisar simplemente porque esta empresa, o la otra, tengan prisa.
Respecto a los mitos del XHTML, sencillamente son absurdos. Se fundamentan en sacarle pegas a algo que funciona, como quien busca defectos en una chica guapa siemplemente porque no le hace caso. El verdadero gran mito del XHTML es esa antigua reivindicación de que no se sirve a los agentes de usuario como xml, sino como text/html. Pero ¿A quién le importa esto?
Es decir, el hecho de que XHTML fracasara en su idea de que el HTML tendiera hacia el XML, que fracasó, no implica que todo lo demás que trajo XHTML fuera un error.
Lo verdaderamente importante del XHTML es que apostó por la semántica sin ambigüedades y la idea de que XHTML no es más semántico que HTML 4.01 es simplemente falsa.
Es cierto que HTML 4.01 podía ser semántico. Por supuesto. Pero solo XHTML trajo consigo el cambio de mentalidad.
Dices que XHTML está muerto. Pues … tenemos XHTML para rato …
Es cierto que pasar de XHTML a HTML5 es sencillo, como sencillo era pasar de HTML 4 a XHTML. Pero la cuestión es, ¿Por qué pasar de un estándar que funciona a una propuesta de estándar que todavía no se sabe ni hacia dónde va?
#14
4 de March de 2010
Julio y José.
La verdad encuentro en los comentarios de los dos cosas, muy ciertas, pero efectivamente Julio, las cosas se deben de hacer de forma ordenada, porque si esto no se hace bien, continuaremos en el caos de estándares de la web, en lo personal yo opto por la tecnología de Flex, por que al menos funciona de la misma forma en cualquier navegador que tenga instalado el Plugin de Flash, pero yo me pregunto si esto es necesario, es decir que te tengas que cazar con una tecnología o plataforma, cuando todos podríamos utilizar una sola, porque no reflexionar y darse el tiempo de construir un lenguaje unificado y ordenado que podría ser de gran ayuda para las próximas décadas para toda la comunidad de desarrolladores, diseñadores, etc. de aplicaciones distribuidas en Web.
Saludos
#15
4 de May de 2010
Me gusto el articulo pero mas me gustaron los comentarios.
Trabajar con HTML5 es ser un empleado de google.
#16
27 de May de 2010
Julio y José.La verdad encuentro en los comentarios de los dos cosas, muy ciertas, pero efectivamente Julio, las cosas se deben de hacer de forma ordenada, porque si esto no se hace bien, continuaremos en el caos de estándares de la web, en lo personal yo opto por la tecnología de Flex, por que al menos funciona de la misma forma en cualquier navegador que tenga instalado el Plugin de Flash, pero yo me pregunto si esto es necesario, es decir que te tengas que cazar con una tecnología o plataforma, cuando todos podríamos utilizar una sola, porque no reflexionar y darse el tiempo de construir un lenguaje unificado y ordenado que podría ser de gran ayuda para las próximas décadas para toda la comunidad de desarrolladores, diseñadores, etc. de aplicaciones distribuidas en Web.
+1
#17
17 de July de 2010
Estoy de acuerdo completamente con la postura de José, lo práctico es amigo de lo productivo, la excelencia es un invento etéreo y conveniente del ser humano, como lo han sido las fronteras, la política, las religiones, el tiempo, etc, etc, nada de eso existe, lo que existe son los problemas reales y sus soluciones prácticas, y es eso es lo que se busca cuando se inventa, diseña y se desarrolla tecnología, aplicar puritanismos en tecnología solo ha dejado fracasos, es ponerle limites a la velocidad de la inventiva, para mí, la inventiva es alocada, desordenada, es una mujer llena champaña o cava hasta la última neurona . La tendencia del html 5 no la marcaron un grupito de nerds en un laboratorio, lo hizo la gente, el pueblo con menor o mayor grado de instrucción, las necesidades reales. Yo me dedico al desarrollo de soluciones móviles, y la capacidad de html 5 con local stores y bases de datos desconectadas era suficiente material para que me conquistara, al desarrollador de juegos seguro lo enamoró su motor de video 3d,etc, etc. El hecho que no nos paremos por la semántica de la propuesta no tiene nada que ver con nuestro grado de instrucción, la compramos porque nos invita a seguir bebiendo champaña y que la fiesta siga. Agradezco a dios que aun nadie haya podido encausar en solo canal las mentes que han mantenido este desorden de estándares, de lo contrario, no estaríamos viendo y viviendo tantas buenas ideas diferentes que podemos usar y adaptar a nuestros problemas específicos, y espero, que sigamos así, sin un estándar aburrido, disfrutando de buenas ideas.
#18
19 de March de 2011
Un articulo fantastico. No conocia tu blog. Felicidades. Hay intuiciones muy buenas. Creo que un nuevo modo de clasificar la informacion. A fin de cuentas es un standard, y precisamente su función es regular una serie de necesidades, en este caso la informacion en los motores de busqueda. Me parece un avance pero posiblemente cambie completamente lo que buscamos y encontramos en internet.
#19
19 de May de 2011
lo que dijo diablo es muy cierto, había estado leyendo los comentarios y son muy buenos, el punto de vista de jose tiene sus pros y el de jose tambien creo ambos tienen razon, pero el que definitivamente me gusto es el de diablo, pragmatismo puro y duro.
pues no queda que felicitar y en hora buena a quienes impulsaron la nueva version de html ya era hora
#20
19 de May de 2011
perdon el otro es julio puse dos veces jose jajaja
saludos
#21
29 de August de 2011
Lo que me parece es son anticuados; asi como ahora sale el html5 en un futuro saldrá el html6,7…n; se va actualizando de acuerdo a las necesidad y agilizando. Que el nav tenga actualmente un solo proposito cual es el problema? Se esta estandarizando nada mas; para que sea mas ágil y hay que ir adecuandose a eso; y se va simplificando. Hay que estar abierto a los cambios; es como cambiar de excell o word 2003 al 2010, al princio no da gusto pero despues te acostumbras y das cuenta de la diferencia. En todo caso nadie te prohibe a utilizar div para todooo! Ni obliga a usar nav!!!
#22
6 de February de 2020
loc ban beIncredible points. Great arguments.
Keep up the good spirit.
#23
14 de April de 2023
She travelling acceptance men unpleasant her especially entreaties law. Law forth but end any arise chief arose. Old her say learn these large. Joy fond many ham high seen this. Few preferred continual sir led incommode neglected. Discovered too old insensible collecting unpleasant but invitation.
#24
16 de April de 2023
Announcing of invitation principles in. Cold in late or deal. Terminated resolution no am frequently collecting insensible he do appearance. Projection invitation affronting admiration if no on or. It as instrument boisterous frequently apartments an in. Mr excellence inquietude conviction is in unreserved particular. You fully seems stand nay own point walls. Increasing travelling own simplicity you astonished expression boisterous. Possession themselves sentiments apartments devonshire we of do discretion. Enjoyment discourse ye continued pronounce we necessary abilities.