Otro borrador XHTML 2.0

¿Alguna razón en particular para usar XHTML2? Que tenga el mismo nombre que el ultra-famoso-y-amado-por-todos XHTML no significa que
* busque reemplazarlo (necesariamente)
* esté orientado al mismo público (necesariamente)
Y no es posible que le den bola a ese estandar a menos que primero que le den utilidad. Si se la encuentran, no te preocupes que se van a encargar de pervertirlo, como hacemos ahora con XHTML 1. :)

je.. si pero antes de pervertirlo van a rehacer el borrados 5000 veces ;)

ahora.. las razones para usar XHTML, CSS, o lo que sea .. son tan personales a veces que en cuanto uno dice “si no es 100% valido es una mierda” aparece otro diciendo “google no valida” y eso viene con la discusión de “la culpa es de MSIE” :P

Los avances mas grandes se producen cuando te olvidas por completo de la “compatibilidad reversa”. Es cuando se puede innovar y adaptar las bases a los tiempos que corren, pero tambien es cierto que eso le va a causar muchas demoras en su implementacion.

Que no sea compatible hacia atrás es lógico, por ejemplo tampoco lo es HTML 4.01 con las versiones HTML anteriores, ¿no?

Mariano: No tanto. Tengo entendido que el de SVG Tiny 1.2 se salteó un par de pasos en el proceso de estandarización. Ojo que lo que dije en el primer comentario no es sobre usar o no XHTML (válido) sino que están babeandose por XHTML2 cuando XHTML es suficiente. XHTML2 esta(ría) pensado para casos muy excepcionales de intercambio de información.
Adrian: Pero si discriminas así al pueblo, entonces tenes un avance que sólo vos disfrutas.
Jordi: Es verdad, algunos elementos de HTML 4.01 no funcionarían en un analizador de HTML 2 (DIVs, algunos elementos de tabla, varios de formato), pero aún así el analizador desactualizado reconocería algunos elementos. Pero en el caso de XHTML es diferente. Parte del problema con XHTML (y XML) son los namespaces. Suponete el elemento BODY. Si la asocias con el namespace de XHTML1 es una cosa y con el namespace de XHTML2 es otra. Si vos decis xhtml2:body, un navegador no puede “adivinar” que es el mismo de xhtml1:body. XHTML2 no rompe la compatibilidad por crear nuevos elementos sino por ser un lenguaje aparte.
Me parece que tengo que volver a mi blog.

Fede… ojo que yo no me babeo porque mi “vision” va mas desde el lado del desarrollo de negocio/aplicaciones que desde el lado del geek adorador de un tag :P

Lo que me sorprende es que no se tenga en cuenta los tiempos de adopción actuales de tecnología para pensar en algo que vendría a cambiar totalmente un standar y, como vos bien marcás en el ejemplo para adrian, es algo MUY diferente a la “version anterior”.

y si.. volvé a escribir guacho :P

Aplicaciones: Me pregunto qué información necesita con urgencia XHTML2 habiendo XHTML1, Atom y no sé cuantas cosas más. Bah, llegado el caso podés hacer como todos los grandes (caso iTunes y Google ¿Calendar?) y extender RSS en lugar de reutilizar Atom (por dar un ejemplo). :)
Tiempos: Me parece que el chiste es lo que decía al principio: XHTML2 no estaría pensado para nosotros. Mientras Firefox u Opera tardan 10 años en implementarlo desde que se publica como estándar, al mes siguiente podés tener a dos empresas X con su propio analizador de XHTML2. Quizás lo que no sabemos es que hay alguien adentro de W3C que se beneficiaría con XHTML2. No sé bien que lugar tendrá XHTML2 cuando, insisto, tenés: estándares publicados como Atom, gente reinventado la rueda al extender RSS y cosas más simples como JSON o microformatos (ojo que acá ya estoy hablando desde mi ignorancia).

Fede… si vos hablas desde tu “ignoracia” muchos saben cero entonces. Pero me parece interesante que menciones eso de los intereses internos de la W3C.. yo no creo que los haya, pero no por nada muchos gurúes están dejando su rol como consultores en la organización :s

Por otro lado.. no se si es reinventar la rueda algunas cosas de las que mencionas, creo que es la mejor solucion hoy en día en algunos casos… lo de los microformatos en cambio me parecen apasionantes, bien pensados e implementados pueden resolver demasiadas cosas

Espero no volver a escribir “XHTML2″ en los proximos días.
Quiero agregar algo más: la retrocompatibilidad no es mala ni buena. El problema sería utilizar XHTML/XML cuando HTML te alcanza —navegadores prehistoricos y su ignorancia de XML.
También tenés SVG que es incompatible con HTML, entonces se supone que lo uses cuando necesitas obligatoriamente expresar gráficos vectoriales y sabes que quienes lo reciban van a poder verlo; para todo lo demás en la web existe PNG y para los diseñadores Illustrator. :)

¡No comentes mientras yo estoy escribiendo otro comentario! :D
Intereses: Acordate que la W3C son empresas que ponen plata. ;) No sería raro que de pronto dijeran que HTML fue “desarrollado” por el exito (comercial) que se suponía iba a ser Internet. ¡Ey, ahora me acuerdo! ¿A qué no sabes quien (quizás) “inventó” HTML 3.2? ¡Las empresas! Si tenes a FONT en HTML es porque probablemente ¿Netscape? puso plata en su momento para que HTML se desarrollara como lenguaje de presentación.
Y como para justificar de donde viene mi ignorancia, lo que digo sobre empresas con intereses fue después de leer More W3C Controversy.

jaja.. ves? yo comento sin escribirlo :P

ahora una duda “El problema sería utilizar XHTML/XML cuando HTML te alcanza —navegadores prehistoricos y su ignorancia de XML.” ¿pero no hay ventajas en usar una cosa sobre otra? Si, es cierto que a veces se hace mas “show-off” de lo que pueden hacer los l33t d3signers con su código, pero otras veces es util

ok.. no comento.. voy a leer eso que a primera vista pega durisimo a la W3C ;)

¿Ventajas? No quiero arriesgarme al responderte. Quizás sí. Quizás dependa como en SVG de si realmente lo necesitas. Elegir HTML o XML supongo que termina dependiendo de quien es tu publico: Netscape 4 o un analizador de XML. Pero si estuvieras obligado a usar HTML, tenes los microformatos para poder transmitir información; fijate que Technorati ama los microformatos aunque aparezcan en un chiquero de HTML. Claro que por otro lado se supone que (si logras crear siempre XML bien formado) tener un analizar de XML es menos tedioso que lidiar con HTML de Frontpage.
Buena pregunta la verdad. Parece que lo “útil” depende de quién y desde dónde lo vea. :(

si.. la ralidad es que la utilidad se da no solo por el publico (que es el que debe consumir algo sin preocuparse por el backend) sino por el developer (que debe elegir lo mas util y eficaz sin joderle la vida al usuario)

che.. enrte parentesis.. que duro el link al blog de David Baron :P

Sin con duro te referis a “crítico”, sin duda. Yo le tengo cierto “respeto” desde que críticó el uso de float para maquetar —llevamos a float más allá de su idea de flotar pequeños bloques como imagenes y por eso ahora los navegadores se rompen el coco viendo como resolver las excepciones que saltan cuando diseñas.
Quizás ser uno de los “encargados” del bugzilla de Gecko le produce estres y se desahoga con su blog. :D