Gravatar de Armonth

XHTML 2.0: El futuro de la web “y que no nos pase ná”

Publicado el Viernes 25 de Agosto del 2006 @ 10:00 por Armonth.

  • 34
  • 13

  • Comentar

Recién hemos salido del cascaron de la guerra de los navegadores, los desarrolladores empiezan a entender las ventajas de un desarrollo utilizando las recomendaciones del W3C, y ahora es cuando se empieza a tomar en serio el XHTML como sustituto del antediluviano HTML 4.01.

Pero la verdad es que el W3C no descansa: el XHTML 1.1 fue publicado el 31 de Mayo del 2001 y desde entonces han estado lanzando continuamente borradores del futuro XHTML 2.0.

A los que no les apetezca la idea de tener un nuevo estándar que revisar no se alarmen: el camino a recorrer todavía es largo y en lo personal creo que pueden pasar 3 años más hasta que sea una recomendación y no un simple borrador, los navegadores lo implementen junto a CSS 3.0, etc., (si se trata del IE cambiad 3 años por 10) y soy optimista.

También faltan mínimo 3 años más para que sesudos blogstars empiecen a hablar de las bondades del XHTML 2.0 y del CSS 3.0 para ser el blogger del universo… bromas aparte:

El último borrador es de finales de Julio del 2006 y se empiezan a notar algunas diferencias abismales respecto al XHTML 1.0/1.1. Dada su extensión, os ofrezco un índice :)

Resumen / Índice

Compatibilidad hacía atrás

HTML ha sido de los estándares más grandes y liosos: por tener que mantener una compatibilidad hacía atrás, inserción de etiquetas de determinados navegadores y también por mantener “tres ramas” (por así decirlo) del estándar:

  • Versión del estándar estricta (Strict).
  • Versión del estándar para marcos (frameset).
  • Versión para webs en transición (Transitional).

Cuando apareció XHTML 1.1 vimos una ruptura en ese tradicional esquema: XHTML 1.1 no tiene dichas ramas, XHTML 1.1 es solamente uno y es considerado Strict.

Como curiosidad decir que en el 99 y tanto % de sitios a validar el único cambio que encontré entre XHTML 1.0 Transitional y XHTML 1.1 fue que lang="" desaparece en favor de xml:lang="".

En XHTML 2.0 se rompe la compatibilidad para atrás lo cual puede ser un gran handicap para su rápida expansión (la migración a XHTML 2.0 sera lenta, eso seguro).

Con esta ruptura el estándar sera mucho más pequeño, conciso y especifico, tendrá tendencia a ser más estructurado como XML, eliminará etiquetas de navegadores y se abstrae de ellos para servir mejor en dispositivos alternativos como PDA’s.

Validación XML obligatoria

Un punto en que actualmente hay mucha polémica es que con XHTML 2.0 ya no sera trivial hacer una web: Si el XML no valida no hay tú tía.

Esto por un lado es bueno: obliga que las webs sean en formato estándar y elimina muchas barreras para el acceso a la información.

Por el otro lado, obliga a tener unos conocimientos un poco más avanzados (tampoco se crean, a simple vistazo se entiende).

Artnau comenta que desde XHTML 1.1 los navegadores si no valida se quejan y es cierto pero al poder ponerle de Content-Type: text/html y que no haya quejas (ni navegadores, ni validadores) es de poco útil y subsanar en 2.0 para que sea obligatorio “a ser posible sin trucos”…

Adiós Hx y DIV, hola SECTION y H

Los encabezados (<h1>, <h2>, <h3>, <h4>, <h5> y <h6>) son una limitación: ¿Qué pasa si necesitamos más niveles?…

Ahora mediante <section> se amplia en forma de árbol de contenidos hasta el infinito y por ello se sustituye por <h> (tal cual, sin número), por ejemplo:

 <section>
   <h>Encabezado de primer nivel</h>

     <section>
       <h>Encabezado de segundo nivel</h>
     </section>
 </section>

De la misma forma los <div> son sustituidos por <section> aunque todavía no está claro si se podrán seguir usando o no.

Role: Un presunto sustituto de ID

Cuando tengamos una parte de la web que no pertenece al contenido — por ejemplo: una lista de enlaces de navegación — podremos utilizar el atributo role:

 <ul role="EnlacesNavegacion">
   <li>...</li>
 </ul>

Aquí hay una diferencia y si lo he entendido bien es que se usara como si fuera un selector de CSS2, por lo que el CSS sería:

 ul [role="EnlacesNavegacion"] {
   list-style: none;
 }

Los ID de momento siguen dando guerra pero es otro elemento que se desconoce si desaparecerá o se desaconsejará su uso.

Artnau comenta que role más que un sustituto de ID (ya tenía mis dudas, por eso lo de presunto) role es un sustituto de rel.

XFrames: Vuelven los marcos (¡¡arghh!!)

Malas noticias, vuelven los frames, por lo que parece está nueva implementación soluciona el problema de las URLs inconsistentes pero aun así me parece que ahí se equivocan y he leído muchas criticas hacía este tema, solamente el tiempo lo dirá.

Toda la información de los Xframes está disponible en el W3C (en inglés).

HREF extendido: Todo puede ser un enlace

El atributo href ya no forma parte únicamente de la etiqueta <a> por lo que puede usarse en cualquier etiqueta, las posibilidades que se me ocurren son muchas por ejemplo las listas de enlaces, de:

 <ul>
   <li><a href="link-1">texto del enlace</a></li>
   <li><a href="link-2">texto del enlace</a></li>
 </ul>

Podemos pasar a:

 <ul>
   <li href="link-1">texto del enlace</li>
   <li href="link-2">texto del enlace</li>
 </ul>

XML includes

Está me gusta: Se puede incluir contenido mediante ficheros XML sin necesidad de usar el include() de PHP, SSI (Server Site Includes ¿todavía alguien usa esto?), ASP o similares.

Un ejemplo es la web de w3future.com donde podemos ver una web con estructura simple en XHTML 2.0, el código de esa web es muy corto y en él se ve:

 <section id="navigation">
   <xi:include href="http://w3future.com/w3f/sections.xml" />
 </section>

Con la segunda línea (xi:include) podemos añadir includes XML sin necesidad de usar un lenguaje de programación del lado servidor.

OBJECT a la palestra

Actualmente es un poco lioso la puesta en escena de distintos contenidos “multimedia”:

  • <style> se usa para mostrar ficheros CSS.
  • <img> se usa para mostrar imágenes.
  • <applet> para applets (y dios sabe qué más).
  • <object> para mostrar objetos (habitualmente Flash).

Pues bien, podemos tachar los tres primeros, object se utilizará para todo aunque yo encuentro un poco coñazo la posibilidad de tener que especificar el “MIME”.

Veamos un par de ejemplos de distintos elementos a mostrar, el código ha sido simplificado ya que por ejemplo al CSS le falta el media="screen":

 <object src="screen.css" srctype="text/css"></object>
 <object src="foto.jpg" srctype="image/jpeg"></object>
 <object src="peli.avi" srctype="video/x-msvideo"></object>

Esperemos pues que el MIME no sea obligatorio y por lo tanto se encarguen los navegadores (o el servidor web) de detectarlo.

Por cierto, el atributo ALT de las imágenes desaparece y se puede especificar dentro del contenido ya que cualquier etiqueta puede tener el atributo “src=”, por ejemplo:

 <p src="mifoto.jpg" type="image/jpeg">Está es mi foto.</p>
 <object src="mifoto.jpg">Mi foto <em>salgo horrible</em></object>

Poder relacionar una imagen a un texto directamente nos ahorra el atributo ALT, el LONGDESC y añade semantica a la imagen, supongo que esto también ayudara a los motores de búsqueda a darle una mejor relevancía a las imagenes.

Cambios en HR y BR

El salto de línea <br /> parece que va a desaparecer en favor de <line /> y <hr> en favor de <separator />.

Referencias

Hay otras novedades cómo blockcode para mostrar código (tal y cómo ahora usamos PRE), los XForms sustitutos de los antiguos formularios y eventos en XML para los formularios (me suena a AJAX ¿casualidad o son imaginaciones mías?) pero para ser un resumen no está mal

,

34 Comentarios (feed)

  1. Gravatar de Com Com nos comenta:

    El HREF extendido puede volver locos a los bots de los buscadores, que dan especial importancia a los enlaces.

    Viernes, 25 de Agosto/2006 @ 12:14

  2. Gravatar de sergio sergio nos comenta:

    Mira tu post esta super bueno, para todos los que trabajamos con web, debemos estar unidos, voy a tener que estudiar mucho.

    oye, vas a aescribir algo sobre Css3 ara ir entrando en ambiente.

    gracias!!

    Viernes, 25 de Agosto/2006 @ 16:52

  3. Gravatar de Armonth Armonth nos comenta:

    Com: Al principio sí, más que nada por que empezaran a dejar de “entender” muchos enlaces pero en cuanto corrijan eso, como toda la vida…

    Sergio: ¿CSS3? quizá aunque si XHTML 2.0 es todavía un borrador CSS 3.0 ya ni digamos… es más actualmente no hay mucho orden en cuanto al CSS: Se usa indistintamente cosas de CSS 1.0, 2.0, 2.1 y 3.0 poniendolos en una balanza respecto a la compatibilidad de los navegadores…

    Es más… es todavía precipitado hablar de un CSS 3.0 “estándar” cuando actualmente se usa CSS 2.1 y todavía es un borrador (última revisión publicada: Abril del 2006).

    Viernes, 25 de Agosto/2006 @ 18:38

  4. Gravatar de eee eee nos comenta:

    Fantástico resumen,

    Aunque aún quedan unos años para su implementación, no va mal saber como suena el río, gracias por tu resumen.

    Salu2

    Viernes, 25 de Agosto/2006 @ 22:01

  5. Gravatar de Lii Xan Lii Xan nos comenta:

    ¿Y que pasa con SVG?

    Viernes, 25 de Agosto/2006 @ 22:24

  6. Gravatar de Armonth Armonth nos comenta:

    Lii: SVG se puede especificar con <object> y siempre que incluye su MIME el navegador deberá encargarse de renderizarlo y así se contempla en el estándar.

    Sábado, 26 de Agosto/2006 @ 1:16

  7. Gravatar de delaPipol delaPipol nos comenta:

    Pues a mi me gusta mucho lo que hay de borrador (er… bueno, comparto la opinión negativa de los frames, teniendo includes no necesito más, y esos includes podrían resultar dinámicos y tal para no recargar toda la página por completo por ejemplo, que tuviera algún sistema de cacheo sin necesidad de recargar todos los componentes incluidos…)

    También me choca alguna utilidad como permitir src extendido en todas las etiquetas, si bien el código puede ser más compacto pero a su vez más ilegible/ofuscado y permitiendo muchos estilos de código entre codificadores. Para “parsear” eso con editores WYSIWYG será una pega y aparte que si no se adapta a nuestras convenciones de estilo.

    Por otra parte será una buena forma de presión para el fomento de los estándares y meterle mucha caña a M$IE y favorecer a los navegadores que las cumplan.

    Lo de validación obligatoria hace llorar de alegría y lo de los tipos MIME también se echaba en falta. Es horrible cuando es culpa del servidor y no tuya cuando la cabecera HTTP está mal formada y obtienes el fichero en el navegador de la forma no deseada. Lo de los includes XML será la revolución.

    A ver si todo esto ayuda a despegar el formato SVG. ¡¡Que llegue a recomendación lo antes posible!!

    Sábado, 26 de Agosto/2006 @ 3:58

  8. Gravatar de Armonth Armonth nos comenta:

    Lo de los includes puede dar mucho juego: Por un momento imaginad WordPress (y quién dice WordPress dice cualquier CMS) con PHP y una BBDD para introducir datos de forma “tradicional” (añadir comentarios, introducir nuevas entradas, editar, borrar, etc)…

    Y ahora imaginadlo generando cada comentario en un pequeño fichero xml y a la hora de listarlos hacer includes…

    Cada entrada un include y una vez generado solamente se toca a la hora de modificar un XML (por ejemplo insertar un comentario: se filtra y si es aprobado se guarda el fichero XML y se añade a la entrada el correspondiente include)…

    Con los include XML veo a los CMS relegados a simples motores de edición y entonces se crea un intermedio entre el contenido generado dinámicamente y el estático, como el cacheo que se usa ahora para que no te fusilen por exceso de CPU…

    delaPipol sobre los MIME: yo lo único que espero es que no sea obligatorio es decir en el caso de que el servidor no funcione bien pues lo especificas y en caso de no coincidir el MIME del servidor y del atributo pues se usa éste último.

    Sábado, 26 de Agosto/2006 @ 5:13

  9. Gravatar de Marc Palau Marc Palau nos comenta:

    Armonth, para eso está el AJAX ahora mismo. Aunque suene a publicidad barata es principalmente para lo que se usa, mírate mi web que durante esta semana colgaré una pequeña conferencia para explicar funcionalidades de ajax y verás que se parece a lo que tu dices :)

    saludos

    Lunes, 28 de Agosto/2006 @ 1:07

  10. Gravatar de Armonth Armonth nos comenta:

    Hombre Marc entiendeme, no soy programador pero entiendo el “concepto”, precisamente una de las pequeñas cosas para la que sirve (por poner un ejemplo) es que al insertar comentarios el comentario se vea insertado: Con eso ahorras recargar toda la página…

    A lo que venía es que XHTML 2.0 incluye “eventos xml” para xForms… parece que quieren volver más dinámicos los formularios…

    Y sobre las conferencias que sepas que cuando publiques si me gustan pienso promocionarlas por aquí :)

    Lunes, 28 de Agosto/2006 @ 3:25

  11. Gravatar de mariano mariano nos comenta:

    armonth.. excelente resúmen… pero la ausencia de backward compatibility va a frenar el nacimiento de este estandar…

    Miércoles, 30 de Agosto/2006 @ 6:41

  12. Gravatar de Fede Fede nos comenta:

    Muy buena tu nota… la verdad que el xhtml 2.0 se las trae…

    Hay que ver cuanto tarde en ser adoptado por los desarrolladores… (pensar q muchos aun usan html…)

    Saludos

    Miércoles, 30 de Agosto/2006 @ 15:08

  13. Gravatar de Federico Federico nos comenta:

    En XHTML 2.0 se rompe la compatibilidad para atrás lo cual puede ser un gran handicap para su rápida expansión

    O para no usarlo para no perder visitantes.

    Validación XML obligatoria

    Los analizadores no son validadores. Fijate de cerrar bien cada etiqueta, no hagas lios con los namespaces y ya tenes resuelto gran parte del problema. :)

    Esperemos pues que el MIME no sea obligatorio y por lo tanto se encarguen los navegadores (o el servidor web) de detectarlo.

    Sería raro. Pensá lo que es actualmente el autodiscovery de feeds. Si sólo agregaras link[rel=alternate] sin el MIME, no podés adivinar si se trata de una versión en otro idioma o de un feed.

    <object src=”screen.css” srctype=”text/css”>

    Sería raro cuando tenés las PI de Associating Style Sheets with XML documents.

    Jueves, 31 de Agosto/2006 @ 8:05

  14. Gravatar de Armonth Armonth nos comenta:

    Poco más que añadir Federico, solamente un apunte: sobre lo del código de CSS… y es que no me extrañaría que el CSS se le tratara como al XSLT para asociar actualmente a los XML…

    No sé si es por ese motivo pero he visto alguna web “en XHTML 2.0″ que lo que hace es ser un fichero XML con una línea llamando al XSLT y dentro de esté el CSS… es raro pero tiene cierto sentido…

    Jueves, 31 de Agosto/2006 @ 9:55

  15. Gravatar de are are nos comenta:

    ¿Con Validación XML obligatoria quieres decir que si es un XML mal formado no renderizará la página? XHTML 1.1 ya obliga ha eso puesto que és obligatorio servirlo como application/xhtml+xml.

    El atributo role aparentemente no es un sustituto de id ya que tiene valores cerrados aunque se podrá añadir valores propios siempre que estén asociados a un namespace:

    It is possible to define additional role values. Such values MUST be defined in their own namespace

    y pone el ejemplo de role="wai:sitemap" (que no es un valor definido en el listado basico).
    Vaya, me parece más parecido a rel que, teoricamente pide definir un profile para añadir valores nuevos (cosa que pocos usan)

    Luego cuando hablas del selector [role=EnlaceNavegacion] dices que es de CSS3 y creo que es un selector de atributo, definido en CSS2 :)

    Jueves, 31 de Agosto/2006 @ 23:30

  16. Gravatar de Armonth Armonth nos comenta:

    Are buenos apuntes, paso a comentarte:

    Sobre XHTML 1.1, es obligatorio servirlo como application/xhtml+xml pero en la práctica la gente (y los CMS como WordPress por defecto) lo envían text/html y valida perfectamente (los navegadores/validadores no se quejan) y aunque no lo recuerdo juraría que no es obligatorio para los navegadores el “no previsualizar en quirks mode” a lo mejor lo pone explicitamente pero creo que no…

    Con XHTML 2.0 se ponen más duros: Las intenciones pasan por que los navegadores al encontrarse el DOCTYPE XHTML 2.0 directamente se pongan en modo estricto y no dejen pasar nada (aunque pongas en el MIME un text/html)…

    Sobre ID/Role: Puse presunto por que parece sustituir a ID (en elementos de navegación, en contenido se sigue usando ID) pero sí: parece ser más un sustituto de rel que no de id…

    Y sobre CSS3/CSS2 + selectores aunque es un “gazapo” no tengo perdon de dios :)

    Jueves, 31 de Agosto/2006 @ 23:54

  17. Gravatar de Federico Federico nos comenta:

    WP usa plantillas con XHTML1.0 ;)
    text/html es HTML no importa el DTD. Como mucho el navegador pensará que el desarrollador se fumó algo e interpretará todo en standars pero sólo porque los navegadores deberían hacerlo cuando se encuentran con un DTD que no conocen.
    Asumir XHTML por el DTD (o HTML porque haya cosas parecidas a tags) es “content-sniffing”, un no-no de seguridad.
    role e ID: Es verdad que no podría reemplazarlo. Si no, ¿para qué se molestarían en desarrollar xml:id? :)

    Viernes, 1 de Septiembre/2006 @ 1:42

  18. Gravatar de Armonth Armonth nos comenta:

    Federico ahí está la gracia: el DTD sobresale en los navegadores por encima del header, sobre lo del no-no de seguridad no lo pillo ¿a qué te refieres? :)

    Cierto lo del xml:id parece que lo que quieren es que usemos role para navegación e ID para contenido si se hiciese caso se podrían hacer cosas como “ignorar todo lo que venga con role” y entonces solamente quedaba el contenido sin elementos de navegación…

    Paranoias mías :)

    Viernes, 1 de Septiembre/2006 @ 1:59

  19. Gravatar de Federico Federico nos comenta:

    Imaginate que mando un archivo foo.jpg que en realidad es un ejecutable (un virus). Vos le haces doble click, Windows lo sniffea y lo ejecuta. Ejemplo muy tonto del problema de seguridad de content sniffing. :)

    Viernes, 1 de Septiembre/2006 @ 4:41

  20. Gravatar de ricardo ricardo nos comenta:

    Se está hablando de que xhtml 2.0 no será “backwards compatible” como si desde el momento en que lo utilizaras tu página dejaría de verla todo el mundo, y me parece un poco exageración.

    La arquitectura de XHTML2.0 *SÍ* tiene compatibilidad hacia atrás, es la parte de nuevas funcionalidades lo que no la mantiene (XForms…- que, por cierto, no es xhtml2.0, es un módulo independiente, aunque relacionado). Esta falta de compatibilidad en lo referente a funcionalidades es exactamente lo mismo que pasó cuando al HTML se le añadieron los formularios o las tablas (en definitiva, algo necesario siempre que un cambio conlleva evolución en ese aspecto).

    Esa compatibilidad estructural quiere decir que, ya que los navegadores actuales son parsers XML, cualquier elemento XHTML2.0 nuevo podrá ser tratado igual que ahora con hojas de estilo CSS, y además también será más fácil tratarlo con XSLT para conseguir el efecto deseado (fija y da esplendor).

    El ‘role’ es mucho más que un atributo para definir navegación. Se trata de un elemento que nos permitirá añadir muchos más metadatos a los documentos, con lo que podrá empezar a hablarse de “marcado semántico” más en serio.

    En definitiva, que si nos paramos a mirar por nosotros mismos XHTML 2.0, veremos que es un lenguaje mejor diseñado que las anteriores versiones, con unas carácterísticas de accesibilidad y unas posibilidades de estructuración y semántica muy superiores, y que, evidentemente, como toda evolución sustancial, conlleva un cambio importante. Y lo que no debemos hacer es dejarnos llevar por el miedo.

    Cuando se empezó a hablar de CSS, los diseñadores de aquel entonces también habrán dicho: “y que no nos pase ná” (y cosas peores).

    Un saludo.

    Viernes, 1 de Septiembre/2006 @ 18:14

  21. Gravatar de Armonth Armonth nos comenta:

    Ricardo, suelo usar la irónia para estas cosas (la parte entrecomillada del título es eso: ironía), a mi personalmente que sea compatible hacía atrás o no e incluso (en un hipotético caso) que obligaran los navegadores a usar XHTML 2.0 sin posibilidad de “mantenerse” en XHTML 1.1 o inferiores me daría igual…

    Suelo ser bastante adaptable asi que los cambios no me dan miedo y menos cuando son a mejor…

    Sobre xForms… yo no he dicho que pertenezcan a XHTML 2.0 si no que éste hará uso de ellos…

    Y por último sobre compatibilidad hacía atrás no he dicho (o querido dar a entender) que no pueda ser compatible si no que han decidido romper la compatibilidad hacía atrás para que está no suponga una carga a la hora de aplicar novedades por lo que no está garantizada quizá cuando sea definitivo decidan cambiarlo pero ahora mismo la compatibilidad está rota y todo cambio que hagan no tendrán en cuenta a “como estaba antes”, ya veremos en qué queda (yo ya tengo ganas) en el borrador final :)

    Por dar una analogía esto es como cuando en un software libre cambian una API (o una biblioteca de funciones, por decir algo) y rompen compatibilidad hacía atrás: Si usabas funciones que siguen estando en la nueva API pues en un principio sigue funcionando…

    Un saludo

    Viernes, 1 de Septiembre/2006 @ 19:38

  22. Gravatar de are are nos comenta:

    Ricardo creo que da en el clavo cuando dice Se trata de un elemento que nos permitirá añadir muchos más metadatos a los documentos respecto al atributo role.
    Me ha hecho recordar RDFa que ilustra como se mezclará XHTML con RDF.

    Viernes, 1 de Septiembre/2006 @ 20:00

  23. Gravatar de ricardo ricardo nos comenta:

    Ya supuse que habrías escrito en tono irónico, y de hecho la intención de mi comentario no era ni ofenderte ni atacarte ni nada por estilo. Al contrario, simplemente ví que por ese tono irónico y por una serie de imprecisiones en el post quedaba cierta ambigüedad en el aire que podía hacer llegar a conclusiones erróneas a alguien que lea el post y sus comentarios sin pararse demasiado. Si me decidí a hacer el comentario fué porque últimamente se está empezando a crear un hype “maléfico” sobre el w3c y todo lo que toca, y me pareció que este post (pese a no ser tu intención, que queda claro que es simplemente hacer un resumen de la especificación) podía alimentar en cierta manera ese hype por culpa de esas imprecisiones.

    Y por supuesto lo de “tener miedo” era una generalicación a lo que no tenemos que hacer *nosotros* como desarrolladores, no tú en concreto.

    Y sobre lo de la compatibilidad, creo que no has entendido bien lo que dije, o que no me he sabido explicar. Tú puedes ahora mismo utilizar el elemento “section” si quieres en tu documento xhtml. Y tú puedes coger una css y hacer section {color: #ff0000;} con lo que tu documento xhtml2.0 sí que se podría visualizar correctamente en un navegador actual, ya que éstos parsean “a la xml”. Y al igual que con ésto, pasaría con los atributos role, etc. Lo que no mantendría esa compatibilidad son elementos que aporten nuevas funcionalidades, por la sencilla razón de que es imposible implementar ahora navegadores que tengan funcionalidades que aún no se han inventado. Por eso digo que esa “incompatibilidad” (la que se verá con XForms, por ejemplo)es la incompatibilidad lógica que hay siempre que se introduce un elemento funcional nuevo.

    En resumen, que no me refería a que si cuando exista XHTML2 podamos utilizar elementos actuales, sino al revés: que sí podremos utilizar muchos de los elementos estructurales de xhtml2 en navegdores actuales.

    Y, de nuevo, siento si te ha molestado mi anterior comentario, no era mi intención.

    Viernes, 1 de Septiembre/2006 @ 20:32

  24. Gravatar de Armonth Armonth nos comenta:

    Buenas Ricardo, sobre lo del miedo te he entendido: solamente aclaraba mi postura por si alguien no la hubiera captado…

    Sobre section… es que los navegadores ahora soportan buena parte de XHTML 2.0 al soportar XML :D

    Sobre compatibilidad, sí, te he entendido y precisamente estamos diciendo lo mismo con distintas palabras…

    ¿Molestar? ¡que va! bienvenido y gracias por aportar, ojalá todos fueran tan civilizados como tú :D

    Viernes, 1 de Septiembre/2006 @ 20:48

  25. Gravatar de Federico Federico nos comenta:

    XHTML2 no es compatible hacía atras:
    * Porque Netscape 4 no entiende application/xhtml+xml
    * Los navegadores de hoy —1 de septiembre de 2006— no conocen el namespace de XHTML2. xhtml1:body no es lo mismo que xhtml2:body. Si escribis un XHTML2 tan básico que use nombres que aparecen en XHTML1, aún así no sería compatible.

    Sábado, 2 de Septiembre/2006 @ 0:37

  26. Gravatar de Juanjo Juanjo nos comenta:

    Hombre, los cambios son siempre traumáticos, pero hay algunas características que se presentan bastante interesantes.

    Ahora… lo que tiene que llegar primero es un soporte adecuado en los principales navegadores (la E azul, miedo me da).

    Martes, 5 de Septiembre/2006 @ 19:37

  27. Gravatar de Romero Romero nos comenta:

    Malo si siguieramos con el XHTML 1, a pesar de que el XHTML 2 en mi país solo lo tienen muy pocas instituciones… sip así es.

    Miércoles, 6 de Septiembre/2006 @ 0:21

  28. Gravatar de Retropcode Retropcode nos comenta:

    ¿Puedo hacer una propuesta al W3C?

    Como en los viejos tiempos en los que apareció C++, se podría implementar algo parecido a C-Front que era el interprete que convertía el código C++ a C para luego pasarselo al compilador “de toda la vida”.

    Sería hacer un HTML-Front, para que cuando el servidor detectara un explorador no-XHTML2, reconstruyera la página en XHTML1.0 antes de enviarla al cliente.

    Miércoles, 6 de Septiembre/2006 @ 14:52

  29. Gravatar de are are nos comenta:

    Retropcode, usa negociación de contenido y sirve lo que prefiera el navegador: xhtml 2, xhtml 1, html 4.01…

    Viernes, 8 de Septiembre/2006 @ 1:02

  30. Gravatar de Marc Palau Marc Palau nos comenta:

    Armonth, aquí te va el link a los archivos de la conferencia.
    La verdad es que no hay apenas texto, solo son los ejemplo que utilicé y lo que dije fué basado en el archivo swf.

    http://www.nbsp.es/2006/09/08/contenido-de-la-conferencia-ajax-en-talleres-subflash/

    saludos!

    Domingo, 10 de Septiembre/2006 @ 18:39

  31. Gravatar de Pancho Pancho nos comenta:

    y yo acá craneándome con xhtml 1.1 y css para el puto IE

    Sábado, 28 de Octubre/2006 @ 20:53

  32. Gravatar de andres andres nos comenta:

    esta pagina es super checvere me arece de loams brabaza

    Jueves, 2 de Noviembre/2006 @ 22:40

  33. Gravatar de Fukurou Fukurou nos comenta:

    Yo en esto de escribir páginas web, soy medio nuevo, algún documento como para empezar a leer sobre estandares??

    PD: la vdd el blog es muy bueno y se nota que tenes experiencia en esto. Saludos

    Jueves, 4 de Enero/2007 @ 13:59

  34. Gravatar de Armonth Armonth nos comenta:

    Fukurou quizá te sirva esto.

    Jueves, 4 de Enero/2007 @ 17:10

Comentarios cerrados