Según S.Piperoglou (1998), la implementación que se hace de las marcas en ambos navegadores no es correcta. En teoría, –y en aquellos lugares donde lo permite la implementación del estándar- omitir el final (o el comienzo) de una marca no debiera tener mayor impacto en la visibilidad del documento.
Sin embargo, en muchas ocasiones, ambos navegadores rechazan asumir implícitamente la marca complementaria. Podemos entender, no obstante, que incluir siempre ambas marcas se trata de una buena práctica, si consideramos que el modelo de objetos de los dos navegadores rechazará aquellos elementos que no se encuentren correctamente completados. Ambos, igualmente, crearan objetos para cada marca que encuentren sin preocuparse por sus categorías.
Esto sucede en las listas en las que se incluyen datos, en lugar de elementos (ítem). El soporte parcial que incluyen Explorer y Netscape de las Hojas de Estilo en Cascada (CSS1: Cascade Style Sheets), hace que estas aproximaciones sean, ahora, innecesarias. Siempre será preferible utilizar las herramientas para aquello para lo que fueron diseñadas.
Buscador
Estándares e implementaciones
Comencemos estableciendo que NO existe un estándar real para HTML. O, al menos, no en la forma de un grupo oficial de estandarización como el Instituto ISO (hay un proyecto actual de estandarización ISO-HTML, pero se encuentra en pañales y no vamos a tratarlo aquí). Lo que sí existe es el arriba citado W3C que funciona como un estándar de facto, con miembros de las principales compañías productoras de software para Internet, estableciendo recomendaciones, que no estándares.
Netscape y Microsoft son miembros destacados, por lo que resulta incorrecto afirmar que las recomendaciones no reflejan las opiniones de los fabricantes de estos navegadores. Incluso existen listas abiertas de correo, donde cualquiera puede contribuir a la discusión y desarrollo de nuevas especificaciones. En ese sentido W3C es una organización muy abierta.2 Con esto en mente, sorprende observar las diferencias de implementación entre los dos navegadores y, entre estos, con el estándar. Las razones: imagino que serán de pura mercadotecnia, en principio. Lo
cierto es que Netscape, que proviene del viejo Mosaic, fue el primero en mejorar las prestaciones permitiendo que el código HTML pudiese ofrecer prestaciones que fueron haciéndose populares, iniciando así el efecto bola de nieve que le llevó a tener una cuota de mercado incomparable. Además, Netscape estaba disponible para una gran variedad de plataformas, y las recomendaciones del W3C tenían poco eco posterior.
Pero cuando Microsoft entró en escena, las cosas cambiaron. Al principio, el Explorer se parecía mucho al Navigator, y con buen criterio, ya que así se conseguía que los usuarios perdiesen el miedo al cambio. También introdujeron nuevas características, que al igual que sucedió con Navigator, tuvieron una desigual acogida. A medida que iban creciendo en prestaciones y novedades empezaron a separarse, y, de aquellas lluvias, vinieron estos lodos en los que nos encontramos hoy.
Volvamos a las especificaciones. La que nos ocupa, es, curiosamente, la tercera, puesto que lo primero que pudo llamarse especificación fue un intento del W3C de poner orden en la situación con una especificación de compromiso que aclarase de alguna forma el caos existente y que se bautizó como HTML 2.0, entendiéndose que todo el desorden anterior a ese momento recibiría genéricamente el nombre de HTML 1.0, aunque nunca hubiera existido tal especificación.
Un tiempo después, se pudo observar que el trabajo que realizaba W3C para la normalización difería notablemente de los planes de Netscape, por lo que hubo de hacer tabla rasa del trabajo anterior y abordar el problema con seriedad, a partir de la situación real. Al conjunto de dicho trabajo se le llama de forma genérica HTML 3.0 ó HTML+. Finalmente, llegó HTML 3.2, que recogía todas las principales características de Netscape, y que es, hoy por hoy, la más estable de las implementaciones y la primera que puede llamarse estándar de facto.
Por su parte, HTML 4.0 es la última y también la mejor de las especificaciones y promete resolver muchos de los problemas que se presentan hoy en día, extendiendo las capacidades del lenguaje en muchas áreas y añadiendo posibilidades más acordes con las necesidades de mercado. Sin embargo, probablemente, será el último, tras una larga agonía. La razón, es que su sucesor, XML resuelve muchos de los problemas insolubles por HTML 3.2, prometiendo un auténtico lenguaje con elementos multimedia, tratamiento de datos, etc. Pero eso, será otra historia...
HTML 4.0: Características e implementación en Explorer y NetScape
Vamos a revisar aquí la forma en que ambas implementaciones interpretan el lenguaje HTML en su versión 4.0. Las versiones posteriores han ido mejorando su nivel de soporte, como ya hemos dicho, pero todavía puede afirmarse que –a la fecha actual, Enero/2001-, más de la mitad del parque de navegadores utiliza versiones 4.x de los navegadores.
Lo primero que debiera de decirse sobre el lenguaje (también sobre la anterior implementación, la HTML 3.2), es que la especificación completa de funcionamiento es un documento enorme y complejo, que analizado con profundidad sorprende por la gran cantidad de características que posee.
Y para mejorar las cosas, las herramientas de creación de páginas son –algunas veces- realmente pobres, o codifican un HTML incorrecto. Esto nos lleva a otra alternativa: crear las páginas con un editor de texto. Pero, también en este caso nos llevaremos sorpresas al visualizarlo si, simplemente, seguimos el estándar. Y ello debido a la interpretación del navegador. Pero veamos primero lo que entendemos por estándar.
Ejemplo de uso de un Data Source Object (DSO) (VI)
Al visualizar la página en el explorador, obtenemos la Figura 25.
Además de ésta posibilidad se puede hacer referencia a un origen de datos remoto utilizando otra de las interfaces implementadas por el DSO, que hace referencia a un origen de datos remoto. En ese caso, las propiedades del componente cambian notablemente (cada interfaz implementada, contiene su propio conjunto de propiedades, métodos y eventos). No vamos a abordar esa situación, ya que va más
allá del alcance de esta obra. Remitimos al lector a los siguientes eBooks: “Acceso a Bases de Datos con Java-JDBC 2.0”, “Programación de Aplicaciones para Internet con ASP 3” y XML: Introducción al lenguaje”, disponibles en la Librería Digital.
A continuación, para acabar éste capítulo, vamos a hacer un análisis del soporte que ofrecen los navegadores respecto a las etiquetas definidas por el estándar HTML 4.0. Como podrá apreciar el lector la situación era bastante caótica hacia el momento de la aparición de las versiones 4.x de los navegadores, si bien la progresiva adaptación a los estándares está solucionando este problema.
Además de ésta posibilidad se puede hacer referencia a un origen de datos remoto utilizando otra de las interfaces implementadas por el DSO, que hace referencia a un origen de datos remoto. En ese caso, las propiedades del componente cambian notablemente (cada interfaz implementada, contiene su propio conjunto de propiedades, métodos y eventos). No vamos a abordar esa situación, ya que va más
allá del alcance de esta obra. Remitimos al lector a los siguientes eBooks: “Acceso a Bases de Datos con Java-JDBC 2.0”, “Programación de Aplicaciones para Internet con ASP 3” y XML: Introducción al lenguaje”, disponibles en la Librería Digital.
A continuación, para acabar éste capítulo, vamos a hacer un análisis del soporte que ofrecen los navegadores respecto a las etiquetas definidas por el estándar HTML 4.0. Como podrá apreciar el lector la situación era bastante caótica hacia el momento de la aparición de las versiones 4.x de los navegadores, si bien la progresiva adaptación a los estándares está solucionando este problema.
Suscribirse a:
Entradas (Atom)