Cita:
Iniciado por buzu Programeitor, ninguno de los ejemplos que dices es prueba de que el XHTML strict sea prolelmático. Simplemente que es diferente y mas, ejem, baya, estricto.
Ese es el problema, la extricticidad deberia centrarse en hacer documentos que el parser pueda interpretar, y no en modificar un lenguaje de marcas anterior, ponerle una X delante y cambiar varias reglas de edicion tenidas hasta ahora por buenas.
Cita:
Iniciado por Dalvenjha Programeitor, si quieres poner tildes y ñs sin cansarte usa la docificaciòn UTF-8.
Cita:
Iniciado por Mikmoro En referencia a target
Es tan usado como desaconsejado. Ya hemos debatido sobre esto alguna vez.
No ,no. ,no te equivoques, es mas usado que desaconsejado. No compares la comunidad de desarrolladores con un consorcio que se ha conferido la potestad de dar recomendaciones, somos muy libres de no seguirlas, y perderemos nosotros cuanto mas apoyo le demos a ese organismo, que esta operando al margen de las nesesidades y usos de la comunidad, esto es muy importante y si no sabemos verlo estamos perdidos, porque al legitimar los estandares estrictos y ofrecerlos como calidad del producto, nosotros mismos nos estamos complicando la vida. Me echo a temblar cada vez que veo en una pagina las etiquetitas de validacion, o al enterarme que los clientes, ya aleccionados por los desarroladores mas "in" piden que sus pedidos cumplan con todos estos requesitos. Esto no lleva a una mejora del lenguaje, sino a una carrera de estandares sin sentido, cuando no hay una pagina XHTML que no se pueda hacer con HTML.
Cita:
Iniciado por Mikmoro referente a &
Pero esto es muy lógico: el amp es un caracter que es inicio de las entidades HTML, por lo que cada vez que se encuentra uno el parser de la DTD strict cree que comienza una entidad, y por eso es recomendable cambiarlo por su propia entidad &. Lo mismo ocurre con < y > que cualquier parser pensaría que son ángulos de comienzo o fin de una etiqueta. Y no te preocupes por la longitud de la frase, ya que en la url el navegador traducirá "&" por "&"
No es de recibo que un parser mas avanzado sea "tonto", el & en la URL ha sido siempre el separador de variables, hasta ahora, bueno ,sigue siendolo, pero hay que codificarlo. ,absurdo.
Cita:
Iniciado por Mikmoro Esto también es muy lógico. En primer lugar, un documento HTML o XML debe ser "bien formado" antes de válido. De hecho los navegadores admitían infinidad de errores, pero los documentos siempre debían haber sido "bien formados", es decir, las etiquetas correctamente cerradas y anidadas, etc.
La barra al final es sólo para las etiqutas vacías no pareadas, y eso es obligatorio por ser XML (XHTML), y porque si no quedarían abiertas sin parear, lo que sería un error de sintáxis.
Los humanos deben aprender a hacer bien las cosas, no a hacer el trabajo de los navegadores. Es como no usar punto y coma en javascript y esperar que el navegador te dé cancha suficiente como para que todo funcione bien, y si no lo hace, decir que tú no tienes por qué preocuparte de hacer todo el milímetro.
otro "retraso" del parser "mas avanzado" totalmente innecesario, en los DTD se especifica cual etiqueta es unica y cual no.
En referencia a lo que me comentais de las ñs y los acentos, problema compartido con responseText de AJAX, he hecho muchas pruebas y no consigo el resultados esperado. Utilizo iso-8859-1 como content-type y guardo los documentos como texto simple.
En defintiva yo pienso que los desarrolladores deben barrer par casa, y no adherirse a estas extravagancias del w3c, al menos no tan bisceralmente.
Salud