Supongo que muchos de vosotros os habréis fijado en dos iconos que hay en la parte de abajo de la barra lateral izquierda, y en el texto que lo acompaña. Indican que esta página que estáis viendo cumnple los estándares XHTML 1.0 Strict y CSS del W3C. O al menos, todo el código que yo escribo lo cumple. La barra que véis arriba, que compartimos todos los blogs alojados en Blogger.com, es añadida por el servidor, agregando código HTML nuevo a la página, antes de ser enviada al navegador. De vez en cuando recibo correos electrónicos de gente que muy amablemente me sugiere trucos para quitar la barra, pero todos ellos se basan en ocultarla, no en eliminar el código que la genera.
¿Lo cualo? No me entero de nada
. Bueno, comencemos por el principio. Las páginas Web, como la que estáis leyendo ahora, están escritas en un lenguaje de marcas llamado HTML. Un lenguaje de marcas permite añadir información extra
a un texto, como por ejemplo indicar que debe ponerse en negrita, o que se trata de un enlace. Si en vuestro navegador buscáis una opción que normalmente se llama Ver código fuente
y la pulsáis, se os abrirá una ventana con un texto raro
en el que mezclado con el texto que podéis ver en la página, aparecen palabras y siglas entre los símbolos < y >. Esas palabras son las marcas, que también se llaman etiquetas. Si por ejemplo quiero poner un texto en negrita, añado la etiqueta <b> justo antes del texto que quiero que se vea en negrita, y </b> justo al final. Si quiero añadir un enlace a una frase, utilizo la pareja de etiquetas <a href="dirección del enlace"> y </a> alrededor de la frase. En este último ejemplo, veis un texto adicional en la etiqueta: href="dirección del enlace". Esto es lo que se llama atributo. Una etiqueta puede tener atributos en la forma nombre=valor. En el caso concreto de una etiqueta <a>, hay que especificar el atributo href con la dirección o URL a la que apunta el enlace.
De momento fácil ¿no? Bien, el lenguaje HTML es una particularización del está basado en SGML, que es un lenguaje genérico
, a partir del cual se puede definir otros lenguajes de marcas. En el lenguaje HTML hay definidas una serie de etiquetas y atributos, cada una de ellas con una determinada función, y en algunos casos, con la obligación de seguir determinada estructura. Así por ejemplo, una página HTML debe comenzar con la etiqueta <html> y debe ir seguida de una cabecera definida con la etiqueta <head> (donde entre otras cosas está el título que aparece en la barra superior del navegador), y tras ella debe estar el contenido de la página en sí, el llamado cuerpo, definido por la etiqueta <body>, y que contiene todo el texto que veis.
Al principio, el lenguaje HTML era, llamémoslo permisivo y caótico
. Veamos, los nombres de etiquetas y atributos, podían ir tanto en minúsculas como en mayúsculas. Así, uno podía poner <body>, <BODY> o <Body>, como más le apeteciera. El valor de los atributos podía ir entre comillas o no, incluso existían atributos sin valor, es decir, que simplemente había que declararlos y ya está (como el atributo disabled que marcaba un control como deshabilitado). Había etiquetas que necesitaban un contenido, como la mencionada <a> que debía ir acompañada siempre de su correspondiente </a>, y etiquetas que no, como <br>, que idicaban un salto de línea. Además, había navegadores aún más permisivos, de forma que si había etiquetas sin su correspondiente cierre
, intentaban deducir dónde debería ir ese cierre y mostraban la página más o menos de forma adecuada. Un ejemplo clásico es el de tablas (<table>) con filas (<tr>) y columnas (<td>) que no se cerraban correctamente. El Internet Explorer intentaba mostrar la tabla (y no lo hacía mal), y el Netscape Navigator no la mostraba si las etiquetas no estaban cerradas correctamente.
A esta situación había que añadirle el que cada compañía añadía nuevas etiquetas y atributos al lenguaje, por su cuenta y riesgo, o interpretaba de formas diferentes la función de éstos. En plena guerra de navegadores, esta situación se convirtió en una auténtica pesadilla para los creadores de páginas Web. Si uno no se andaba con cuidado, una página podía verse muy bien en un navegador, y fatal en otro. Fue una época en la que comenzaban a aparecer los famosos y odiados botones de Optimizado para...
(normalmente, para Internet Explorer), que en realidad significaba que si no veías la página con ese navegador en concreto (y en ocasiones, con una versión en concreto), la página se veía totalmente descuadrada, o incluso no se veía. Además, supongo que ante las presiones de jefes que sólo sabían de marketing o de la competencia, los diseñadores se veían obligados a estrujarse las neuronas buscando formas de maquetar una página, que estaba más allá de las posibilidades originales del HTML. Así, aprovechando la flexibilidad que ofrecían las tablas en HTML, en seguida proliferaron los diseños basados en tablas. Celdas vacías e imágenes transparentes que servían como separadores, y tablas dentro de tablas, se convirtieron en la norma de todo diseño visualmente llamativo. Y en una locura de mantener. Un pequeño cambio aparentemente sencillo, podía degenerar en horas y horas de trabajo. Frases del tipo No está mal, pero ¿y si ponemos esto un poco más a la izquierda, y de color verde?
eran aterradoras.
Hace ya algunos años, el W3C actualizó el estándar HTML y definió otros nuevos. Podemos resumir los cambios más importantes en dos: evolución del HTML original a un HTML más semántico, y redefinición del HTML en XML. ¿Lo qué? Veamos, antes he hablado de la etiqueta <b>, que ponía un texto en negrita. Existen muchas otras etiquetas para modificar la apariencia del texto, como <font>, que permite cambiar el tipo de letra, tamaño y color, <center>, que centra horizontalmente un elemento, y atributos como bgcolor que permite cambiar el color del fondo, o align que modifica la alineación horizontal de un texto. Utilizando estos elementos, y diversos trucos con tablas, se podía tener mucho control sobre la apariencia final de la página. Pero para ello, había que poner esas etiquetas y atributos en el código HTML de nuestra página. Si deseabamos (o nos encargaban) modificar la apariencia, había que modificar toda la página, en multiples lugares. Y si teníamos varias páginas similares, había que modificarlas todas. Existe un estándar llamado CSS, que define lo que se conoce como hojas de estilo
, y que nos permite modificar la apariencia de una página HTML. Podemos especificar los colores, tipos y tamaños de letras, alineación, e incluso el posicionamiento y tamaño de elementos. Y lo mejor es que puede ir en un fichero separado, de forma que en la página HTML simplemente hay que hacer referencia a él. Bien utilizadas, las hojas de estilo nos permiten eliminar todo el código de nuestra página, relacionado con la apariencia, y ponerlo en dicha hoja de estilo. De esta manera, el código HTML de nuestra página contedrá únicamente la información que deseamos mostrar, debidamente estructurada, y no cómo deseamos mostrarla.
Así, existen dos variantes (bueno, en realidad son tres, pero la tercera no viene al caso) de la última versión del lenguaje HTML: Transitional
y Strict
. En la variante Transitional, se pueden utilizar todas las etiquetas y atributos, pero en la variante Strict, estamos limitados a aquellos que no tengan nada que ver con la apariencia de la página. Ésta apariencia se debe definir en una hoja de estilo. De esta manera, en la variante Strict, no podemos utilizar etiquetas como <font> o <center>, ni atributos como bgcolor. Además, deberíamos limitarnos a utilizar tablas para mostrar tablas, es decir, una serie de datos distribuidos en filas y columnas. Otra consideración adicional es ordenar la información de forma estructurada, sin pensar en la posición final de los elementos. Un ejemplo lo tenéis en esta mismo blog. Veis que la estructura visual consta de una cabecera, dos barras laterales (una con enlaces internos al blog y otra con enlaces externos) y el contenido de los envíos en el centro. Uno puede pensar que en el código HTML está definida la cabecera primero, después la barra lateral izquierda, luego el contenido central, y finalmente la barra derecha, pero no es así. La estructura de la página es: cabecera, contenido, barra lateral izquierda y barra lateral derecha. Es decir, si no existiera una hoja de estilos, leeríais primero los envíos, y después de ellos vendrían todos los enlaces. Un día puedo decidir invertir el orden de colocación de las barras laterales, o decidir ponerlas una encima de otra, como una única barra, o una arriba de forma horizontal y otra a un lado. Y todo ello sin cambiar una coma del código HTML. Sólo debo modificar el código CSS.
Bueno, está claro eso de un HTML semántico, pero ¿qué es eso de XML? El XML es un lenguaje de marcas similar, pero mucho más estructurado, y que permite definir nuestro propio lenguaje de marcas. Concretamente, la reformulación de HTML en XML se denomina XHTML, pero es sólo uno de los muchos lenguajes basados en XML que existen. Para un XML se puede (y se debería) definir un DTD o (mejor aún) un esquema XML, donde se definen las etiquetas, atributos y estructura del lenguaje. Hay que decir que el SGML ya utilizaba DTD, y el HTML está definido en función de ellos, pero por algún motivo nunca se ha prestado demasiada atención a ello. Con el XML, en cambio, han proliferado herramientas diversas para comprobar si un fichero XML cumple la especificación definida en el DTD o en el esquema. Bien, el DTD o el esquema nos dice qué etiquetas se pueden utilizar en un lugar determinado, qué atributos tiene, cuáles son obligatorios, y un largo etc. En XHTML, los nombres de etiquetas y de atributos están definidos en letras minúsculas, con lo que no es correcto utilizar etiquetas como <A> o <TABLE>, por ejemplo. Una característica intrínseca del XML, es que el valor de un atributo debe ir siempre entrecomillado, y que los atributos deben tener siempre un valor. Así, no podemos poner sin más el atributo disabled que mencioné antes, sino que habría que escribir disabled="disabled". Otra característica intrínseca del lenguaje es que toda etiqueta debe ser cerrada. Así, no podemos utilizar la etiqueta <br> sin más, para poner un salto de línea, sino que debemos utilizar <br></br>, o mejor aún, para evitar malinterpretaciones de algunos navegadores, hacer uso de la sintaxis abreviada <br/>, que nos indica que la etiqueta no tiene contenido. Para maximizar la compatibilidad con navegadores antiguos que sólo procesan HTML, se recomienda dejar un espacio justo antes de la barra inclinada, tal que así: <br />. Pero hay que tener en cuenta que aunque un navegador lo entienda, esa expresión no sería realmente HTML correcto, sino XHTML.
En XHTML hay también tres variantes (en su versión 1.0), de las cuales nos interesan la Transitional y la Strict, que tienen las mismas consideraciones que sus homónimas en HTML. Aquí hay que tener en cuenta un detalle en la variante Strict: En HTML existe un atributo muy utilizado llamado name, que se utiliza para dar un nombre a un elemento cualquiera, y así poder ser referenciado desde JavaScript (un lenguaje de programación interpretado, que se puede añadir a una página HTML). En XHTML Strict, ese atributo ha desaparecido (salvo en determinadas etiquetas muy particulares) en favor de otro llamado id, que cumple la misma función, y cuyo valor no puede repetirse en ningún sitio de la página (cosa que no ocurría con el otro atributo, y que podía dar lugar a resultados no deseados).
Todo esto parece muy complicado ¿no? Parece fácil cometer un pequeño error. Cierto, y por eso el W3C tiene dos validadores online para HTML (o XHTML) y CSS, con los que podréis comprobar fácilmente si vuestra página cumple los estándares o no. Y si no los cumple, te dice por qué.
Bien, si habéis conseguido llegar hasta aquí, estáis en condiciones de entender el problema de Blogger. Los blogs que se alojan en Blogger están definidos por una plantilla, que no es más que código HTML con determinadas etiquetas especiales (no HTML) que son sustituidas en el servidor por el texto correspondiente. Así, por ejemplo, la etiqueta <$BlogTitle$> es sustituida por el nombre del blog (en mi caso, la palabra MalaCiencia
), y la etiqueta <$BlogItemTitle$>, por el título del envío. Durante el proceso, se incluye en el código generado, de forma automática, el código HTML correspondiente a la barra de Bogger que podéis ver en todos los blogs alojados ahí. Y resulta, que aunque se supone que el código HTML de Blogger es XHTML 1.0 Strict, y las plantillas que te ofrece por defecto cumplen el estándar, el código de la barra de navegación de Blogger tiene algunos errores. Y es algo tan simple como el hecho de incluir en un par de etiquetas, ese atributo llamado name que no se debe utilizar. Esto hace que cualquier página generada por Blogger, no importa los esfuerzos del sufrido creador, no cumplirá completamente el estándar, teniendo al menos 2 fallos. La solución es muy sencilla: en esas dos etiquetas, hay que sustituir el atributo name por un atributo id con el mismo valor. Así de fácil (para los entendidos, diré que el JavaScript seguiría funcionando, lo he comprobado). Pero eso sólo lo pueden hacer los administradores de Blogger.
Existen varias formas de ocultar la barra de Blogger. Pero fijáos bien que he dicho ocultar, no eliminar. Una de las muchas cosas que se pueden hacer con una hoja de estilo, es indicar que determinados elementos no se muestren. Pero con eso, lo único que conseguimos es que la barra no se vea. El código XHTML incorrecto sigue estando ahí.
Además, la barra de Blogger no es el único problema. Los comentarios al envío tampoco son generados como XHTML válido. Como facilidad para los usuarios, Blogger transforma automáticamente los saltos de línea introducidos en la cajita de comentario, en etiquetas <br/>. O casi, ya que por algún despiste por parte de los desarrolladores, lo que se utiliza realmente es el texto <BR/>, cuya presencia hace que no sea ni XHTML ni HTML válido. Es decir, no existe una sola versión de HTML o XHTML donde el la etiqueta <BR/> sea correcta. En este caso, se puede solventar el problema configurando el blog en Blogger para que los comentarios se muestren en una ventana diferente, en vez de en la propia página. Pero es un error importante, que irónicamente se debería resolver de forma muy sencilla.
Las hojas de estilo tampoco se libran. El código HTML de la barra de Blogger, hace referencia a unos ficheros CSS, que tampoco son del todo correctos, por lo que un blog alojado en Blogger tampoco pasaría una validación CSS.
Bueno, y ¿todo esto es importante, o se trata sólo de pajas mentales de los informáticos? Pues sí es importante. Los estándares se hacen para ser utilizados y respetados. Uno de los pilares de la Web es poder acceder a la información, independientemente del navegador, del sistema operativo, e incluso de la máquina (y no estoy pensando sólo en ordenadores). La situación de hace varios años, con diferencias abismales entre el Internet Explorer y el Netscape Navigator, degeneraba en ocasiones en tener que hacer dos versiones de cada página, o en condenar
a los usuarios de uno de los navegadores a no poder verlas. ¿Os imagináis que existieran canales de televisión que sólo pudieran ser vistos por una determinada marca de aparato? Afortunadamente, esa etapa parece haber sido superada, aunque hay quien se empeña (tal vez por desconocimiento) en hacer páginas pensando únicamente en un sólo navegador (normalmente Explorer). Si al crear nuestra página, nos ceñimos rígidamente a los estándares del W3C, tendremos bastante seguridad de que se verá en la mayoría de los navegadores. Y si no, siempre podemos excusarnos diciendo que si no se ve bien, es problema del navegador, que no cumple el estándar.
Por otro lado, separar el contenido de la forma de presentarlo, nos ayudará a modificar posteriormente la apariencia de nuestras páginas, o mejor aún, facilitará su proceso por parte de software especializado para discapacitados, como sitnetizadores de voz o lectores braile. O incluso podemos especificar diferentes hojas de estilo, de forma que el usuario escoja cuál utilizar.
Sin duda, podría declarar el código XHTML de este blog como Transitional, en vez de como Strict, y así ya sería código válido. Pero por un lado soy un firme defensor de la separación entre contenido y presentación. Y no sólo en la Web, sino en procesadores de texto como el MS Word o el OpenOffice.org Writer, en los que también puede aplicarse la misma filosofía. Os aseguro que si se hace bien, te ahorra muchos quebraderos de cabeza a la hora de modificar la apariencia de un documento. Así que quiero aportar mi granito de arena para difundir esta forma de hacer las cosas. Además, el código CSS de la barra de Blogger seguiría siendo incorrecto.
Me ha parecido una entrada muy útil, hace mucho tiempo que tengo un cacao mental con eso de las validaciones, del XHTML y todo lo demás. Me has resuelto muchas dudas.
ResponderEliminarPS. Hay una errata ortográfica enorme en el séptimo párrafo, has escrito "no biene al caso", es con v, viene.
Por cierto, las etiquetas que añade blogger al código para añadir luego los mensajes el título y todo lo demás... donde puedo encontrar para qué sirven todas ellas? Es que me gustaría reescribir el código entero de un blog y luego añadirlas, siempre tengo que ir haciendo chapuzas con el código.
ResponderEliminarQuizá sea un poco simplista, pero... resumiendo: que Google no cumple los estándares. Quizá sea un título sensacionalista, pero sin duda es con el mensaje que me he quedado yo al leer la entrada. Sinceramente, no puedo creerlo. Además, por lo que dices, la solución al error solo está en cambiar algunas etiquetas... ¿me equivoco? Me he quedado muy sorprendido (para mal), ciertamente
ResponderEliminarVaya errores mas absurdos han cometido, as probado en contactar con ellos? no se si tienen algun tipo de soporte o formulario de contacto, pero creo que un CMS de tal embergadura no puede tener estos errores.
ResponderEliminarComo a todos nos han enseñado de pequeños en el cole, "corréos" va sin tilde ("correos"). ;)
ResponderEliminarMe has aclarado algo que ya sospechaba.
ResponderEliminarPienso lo mismo que bungow.
Y sxim, no sé si google ha tocado algo desde que compró blogger. Igual sigue como lo dejaron los anteriores dueños y Google no se ha puesto a ello.
¡Ops! Dos faltas de colegio. Bueno, ya están corregidas.
ResponderEliminarSobre las etiquetas de Blogger, hay una página de ayuda de blogger, con un apartado sobre los códigos de la plantilla.
Hay una dirección de correo de soporte, y hace tiempo les mandé un email. Corrigieron un error muy sencillo (sí antes había más), pero con respecto a los demás, me contestaron que tenían otras cosas más prioritarias. No sé, tampoco es algo que lleve mucho tiempo el corregir eso, aunque supongo que querrán depurar bien todo.
Tal vez un día de estos les envíe otro correo recordándoselo.
Discrepo sobre la frase "el lenguaje HTML es una particularización del SGML". El SGML se usa para dar la descripción del HTML, lo cual no quiere decir que sea una particularización. Con SGML se pueden describir formatos que no tienen absolutamente nada que ver con HTML o XML (ni siquiera es necesario usar los "<" y ">" en el formato resultante).
ResponderEliminarY en origen, como indica la Wikipedia para SGML, el HTML simplemente se basó en la idea de las tags de SGML, pero nada más. La misma entrada dice que la reformulación 2.0 de HTML intentó ser una aplicación de SGML, pero que no está claro que sea así. Y aunque lo fuese, insisto en que sería una aplicación (es decir, HTML se podría definir mediante SGML) pero nunca una particularización. Es el XML el que es una particularización o subconjunto de SGML.
Sobre lo de que Google no cumple los estándares, es curioso el éxito del marketing de esta empresa. Parece como si Google lo hiciese todo bien por defecto, cuando lo cierto es que en cuanto a estándares web, se puede decir es que los pasa por el forro de los caprichos (que decía Jose María García :P ). No los cumple la página principal de Google, ni las páginas de resultados, ni la página principal de Blogger, y no me ha apetecido mirar más. En el caso de la página principal de Google y de las páginas de resultados, si os dedicais a mirar los errores, enseguida se nota que no son un par de chorradillas que se les ha pasado. No, se nota que simplemente pasan del tema (ni siquiera incluyen el Doctype).
Para sxim y los demás, efectivamente Google no cumple los estándares y lo hace de forma deliberada. Cumplir los estándares es engorroso, pero no imposible, y con la cantidad de mentes pensantes que hay en Google y lo automatizado que tienen todo les es más que factible conseguirlo, pero recordad, si de algo alardea Google es de velocidad, y hacen todo lo imposible para aumentarla.
ResponderEliminarPor ejemplo, la cabecera de la página de resultados no aporta más información sobre la página que el tipo de codificación, las clases CSS están declaradas mediante una sola letra, tres como mucho, las funciones JavaScript mediante dos o tres (y me extraña la cantidad de CSS y JavaScript que lleva la página), por supuesto, han suprimido prácticamente todos los saltos de línea en los resultados (al navegador le resultan superfluos)
Otra curiosidad; en lo que respecta a encerrar los valores de los atributos entre comillas, por ejemplo, la página de bienvenida del Sito suele "pesar" alrededor de 50 K's. Sin comillas (no todas se pueden quitar, no obstante) se queda en 48 un 4% de "reducción" de peso. En cuanto a los cierres de los saltos de línea (ahorraríamos dos caracteres) idem del anterior, con bastante menos incidencia pero también es un ahorro.
Calculo que entre unas cosas y otras la página de resultados de Google puede pesar del orden del 10% menos que cumpliendo los estándares a rajatabla. No parece mucho, pero imagina la cantidad de páginas envía Google al día, ese 10% de ahorro supone un ancho de banda bestial... además de que tienes la página en tu navegador una décima de segundo (o proporción) antes.
Además sospecho que hay otras cuestiones de índole comercial, no resulta extraño que terceros aprovechen las búsquedas de Google para implementar sus propios servicios de devolución de resultados; cuanto más caótico sea el código de las páginas de resultados, más engorroso será analizarlas y aprovecharse de ellas por la cara.
Si te molesta la barra de Blogger y no te hacen caso para hacer que cumpla los estándares deberías cambiar el blog a algún otro sitio que los cumpla mejor. Se me ocurre wordpress (creo que en algún sitio daban alojamiento gratuito para blogs en wordpress). Hay otro blog que suelo leer y la propietaria creo que ofrece hosting gratuito (tal vez puedas hablar con ella, su blog es campanilla.info). Y como última opción siempre puedes montarte tu propio servidor.
ResponderEliminarMuy interesante tu blog. Me gusta la astronomía y he leído tus post divulgativos. Felicidades!
ResponderEliminarLo seguiré leyendo!
Saludos desde Madrid
Qué quieres, los que no tenemos para montarnos un megaservidor como a mí me gustaría tenemos que quedarnos con blogger, que es de los menos malos (mira MSN Spaces, qué horror). Así que aunque ya me sepa la estupenda lección sobre diseño web que nos has dado, hago lo posible para tener un diseño cuidado en mis blogs.
ResponderEliminarSerlio, tienes razón. Tal vez la palabra "particularización" no sea la más adecuada. Pero era para dar a entender que el SGML (al igual que el XML) es un metalenguaje para definir otros lenguajes, pero sin tener que ponerme a explicar lo que es un metalenguaje. Puede que con "particularización" se de a enteder que es un caso especial de SGML, o que sus etiquetas son un subconjunto de estas. Y no es el caso. Mmmm ¿concretización, tal vez? Naaa... creo que va a ser mejor "basado en SGML".
ResponderEliminarSobre cambiar el alojamiento del blog, hay dos problemas, nada tiviales: por un lado, migrar todos los envíos y sus comentarios. Por otro, encontrar un alojamiento gratuito y con los mismos servicios. La publicación en Blogger, es muy cómoda. Tiene una página con pequeño editor HTML que no está mal. Y uno tiene la tranquilidad de que al estar Google detrás y haber miles de blogs alojados, se romperán los cuernos para que todo funcione. Sería muy raro que el servidor (servidores, más bien, que deben ser bastantes) esté caído varios días, o que el servicio se cerrara indefinidamente.
A cambio tiene otros inconvenientes, como el no tener un control total sobre el código, o la carencia de características presentes en otros sitios, como un calendario o una categorización por temas de los envíos. Otro inconveniente es que no puedes alojar ficheros adicionales (varias CSS, por ejemplo, para poder tener estilos distintos). Pero es un pequeño precio a pagar.
un detalle importante q ha hecho lo q es la web hasta hoy: el layout de sitios con tablas se inicio cuando a éstas se les permitió dar border="0". antes recuerdo se usaban para darle ese efecto de 'marcos' a las fotos, con bordes de 10 o más pixeles, y con javascript podías darle diferentes colores a los bordes.
ResponderEliminarsaludos, excelente articulo, lo linkee al mio.
Un articulo excelente Alf.
ResponderEliminarMuchas gracias por aclararme porque mi blog no pasa por los validadores. Ahora me quedo más tranquilo.
Un breve comentario... El 99% de las páginas en XHTML son identificadas por los servidores que las hospedan como HTML (text/html), lo cual es tan correcto como enviar un JPEG marcado como image/gif. Si esto se hiciera bien (application/xhtml+xml), el más minúsculo error en las etiquetas debería provocar obligatoriamente que el navegador mostrase *únicamente* un mensaje de error, en lugar del contenido de la página. Naturalmente, nadie lo hace. Pero entonces, ¿para qué usas XML si no vas a seguir sus reglas?
ResponderEliminarYo no estoy nada seguro de que sea una buena idea usar XML para hacer una página web.
El problema es que el navegador más utilizado, no soporta el tipo application/xhtml+xml (¿adivináis cuál es?). Por otro lado, la inmensa mayoría de servicios de alojamiento de páginas (al menos los gratuitos), tampoco parecen ofrecerlo. Supongo que por el dichoso Explorer.
ResponderEliminarPienso que sí es una buena idea usar XHTML, pero usándolo bien, cosa que no se hace en muchos sitios (este blog incluido, por culpa de ese código generado automáticamente). No sólo en la mayoría de los sitios no se sirve con el MIME-type adecuado, sino que no se encierra el código JavaScript en secciones CDATA, se utilizan atributos no permitidos, o se ponen símbolos "&" tal cual en URLs, en vez de "&".
Tal y como lo veo, estamos en una época de transición. Estaremos durante muchos meses (tal vez unos pocos años), conviviendo con una especie de XHTML "bastardo", hasta que su uso como Dios manda se extienda. O al menos eso espero.
Buenas
ResponderEliminarUn blog muy interesante, si señor.
Yo tengo un error en mi blog que no se subsanar, pero no se si es culpa de Blogger o mia :S
http://www.avistadeperro.blogspot.com/
esta es la dirección, si alguien se aburre un poco y cree que podría echarme una mano, GRACIAS
P.D. Sigues así!
Sobre el salto de linea:
ResponderEliminarYa veo que los últimos comentarios de este post son antiguos y que seguro se debe a un cambio o mejora en blogger, pero decirte que las entradas de comentarios ahora al poner un salto de linea te lo codifica como br lo cual si es conforme estandares.
nota: gracias por tu artículo que es muy interesante.