Saltar índice de contenido - Desplazarse al índice de navegación.
Contenido: Evolución. Elementos reemplazados. El papel del autor. En el lado del usuario. Las máquinas también opinan. Y los monitores no van a ser menos. Reflejo condicionado. Comentarios.
Hay un problema de ritmo. Siempre lo hay. Si echamos un vistazo a la primera versión de HTML, se puede constatar que la situación actual ni siquiera se soñaba, al menos no en tan poco tiempo. De lo contrario, el elemento object hubiera formado parte de esa primera especificación (o a lo sumo de HTML 2.0), los elementos img, frame, applet o iframe nunca hubieran sido formulados, y esta discusión versaría únicamente sobre problemas de accesibilidad.
La rápida generalización de Internet como medio de masas ha obligado a ir adaptando el lenguaje a las nuevas necesidades. Así es como ocurren las cosas. De otra forma estaríamos todavía agrupándonos al anochecer alrededor de un fuego, pensando que las estrellas eran hogueras que protegían a otros grupos de nómadas. Pero la evolución incluye aciertos y errores, y como las cosas no suelen ser blancas o negras, todo tiene aspectos positivos y negativos. Y los marcos no van a ser menos.
Los elementos mencionados en el primer párrafo tienen una especial peculiaridad, que pasa desapercibida en una inmensa mayoría de dispositivos, sistemas y navegadores que cuentan con las tecnologías apropiadas para sustituir una simple referencia por una imagen, un programa o por otro documento. Pero nada de esto se puede considerar una solución "global", a pesar de la proliferación de sistemas operativos gráficos con capacidad para representar contenidos de diversa índole.
Y no es algo en lo que no se haya pensado. De salida se establecen atributos como alt o elementos como noframes para incluir un contenido alternativo a mostrar en el caso de que el reemplazo no tenga éxito. El modelo de elemento object puede considerarse el más "amable" al poder incluir sucesivas soluciones alternativas (otros elementos object de diferente tipo y texto en último caso). Una página con marcos, desde el punto de vista de este párrafo, incluye únicamente dos o tres elementos reemplazados y, en el mejor de los casos, un elemento con información alternativa.
Varias son las razones que arrastran a un autor a la utilización de un conjunto de marcos, la mayoría están relacionadas con la comodidad, y en general todas siguen el mismo patrón: menú omnipresente a la izquierda y contenido cambiante a la derecha (y quizá una cabecera también constante, pero sin ninguna funcionalidad). Podemos descartar la colocación como factor a tener en cuenta, ya que no corresponde al documento HTML especificar cómo o dónde se representa el contenido (ver ejemplo en el taller nº3).
Nos queda analizar las ventajas que podemos obtener de separar en varios archivos la información que va a mostrarse. En el ámbito de la organización personal puede venirnos bien, pero los marcos no son la única salida, ni tampoco la mejor. Es preferible la elección de cualquier tecnología en el lado del servidor, alguna sorprendentemente simple, como el uso de SSI para incluir un contenido común en cualquier documento de forma transparente, independiente del cliente. Incluso si no hay posibilidades de operar en el servidor, siempre hay soluciones de andar por casa, y no se descarta dedicar un futuro taller al respecto.
Los marcos sólo tienen sentido cuando se ven. Esta perogrullada no es gratuita, ya que cuando el usuario, ya sea por problemas físicos o técnicos, no puede hacer uso de ellos, la utilidad del sitio queda reducida dramáticamente, y todas las molestias que se tomó el autor caen en saco roto. Pasando este escabroso detalle por alto, el usuario recibe una interfaz gráfica bastante clásica, que no es exclusiva del uso de marcos. Sólo notará algo raro cuando, al ir navegando por los contenidos del sitio, constate que la URL que exhibe el navegador no cambia, por más que se carguen nuevos documentos. Esto, junto con la invariabilidad del marco del menú, le puede provocar cierta desorientación.
¿Y qué lenguaje utilizan? Por ejemplo HTML, cuya funcionalidad queda bastante maltrecha cuando se utilizan marcos. El elemento característico de este lenguaje es el hipervínculo, que sirve de bien poco en una composición de marcos. Como hemos dicho antes, la URL siempre es la misma, la que contiene el conjunto de marcos. Cualquier combinación de marcos resultante de la navegación por el sitio será irreproducible por métodos normales, y los enlaces que apunten a fragmentos dentro de un documento son imposibles.
Pongámonos por un momento en el lugar de un "robot araña", de esos que trabajan para los buscadores más ilustres. Llegamos al directorio de turno y cazamos el archivo principal, junto con una descripción que, en la mayoría de los casos, alude al uso de marcos y hace una gracia sobre lo antiguo que es el navegador que está usando el usuario. No aporta gran cosa sobre el tema real del sitio, pero a nosotros, como robots obedientes que somos, nos importa un pimiento. Quizás en ese momento, o en la siguiente vuelta que nos demos por esos lugares, indexaremos el resto de documentos que componen el sitio, los cuales sí mostrarán un contenido coherente. Por tanto, es de esperar que los usuarios que utilicen el buscador accedan a estos últimos enlaces, que estarán huérfanos, al faltarles la información del conjunto de marcos. ¡Buena la hemos liado! Y es que los robots somos así.
Ya que son estos dispositivos los únicos que pueden mostrar marcos (siempre que el hardware y el software se lo permita), es razonable que también puedan aportar su granito de arena, y además la estructura de este documento pedía a gritos una última parte sin demasiado hierro. Sobre un total de trescientos monitores encuestados, a un ochenta y cinco por ciento le parecía muy raro eso de que el contenido "desapareciera" debajo de otro elemento de la propia página, unos cuantos, cuyos dueños les tienen condenados a unas resoluciones ridículas, se ven incapaces de representar las páginas de marcos con un mínimo de estética y buen gusto, y uno de ellos, muy simpático, aunque algo neurótico, nos relató que cierta vez sufrió un colapso cuando una página cargó en uno de sus marcos otra página que también contenía marcos y que a su vez llamaba dentro de otro a... Bueno, era algo así, pero él lo contaba con más gracia.
Algunos comentarios y sugerencias me han llevado a pensar que quizás algunas cosas no han quedado suficientemente claras, y aunque no sé si conseguiré enmendar esa situación no está de más intentarlo. En primer lugar, y antes de volver nuevamente a detalles más técnicos, decir que esto no tiene ninguna relación con otros debates más pintorescos, como los famosos PC vs Mac, Windows vs Linux o el manido Explorer vs Netscape. En todo caso entroncaría con la discusión sobre la utilidad real de los estándares, tema que acabará teniendo, irremisiblemente, su artículo propio dentro de estas páginas.
Es posible crear piezas de código JavaScript que eluden ciertos problemas de los marcos, como los derivados de cargar directamente un documento proyectado para formar parte de un conjunto de marcos, e incluso el de la inmutabilidad del título. Puede que estos scripts salven la situación en ciertas ocasiones. Pero en otras lo único que hacen es engordar gratuitamente la lista de problemas de accesibilidad, porque generar contenido mediante scripts en el lado del cliente es una técnica aún menos recomendable que el uso de los marcos.
En ciertas ocasiones he observado una especie de reflejo condicionado merced al cual alguien se entusiasma con los métodos de presentación gráfica utilizando elementos div posicionados mediante CSS, para preguntarse después cómo se puede cargar una página en cualquiera de esos div. Obviamente no se puede, salvo que el citado elemento fuese en realidad un iframe o un object, pero entonces volveríamos a tener los mismos problemas (o todavía más, debido a lo relativamente novedoso de estos últimos elementos). HTML no puede ni debe establecer el dónde o el cómo ocurren las cosas, porque existe un sinfín de posibilidades, que quedan reducidas a una (en el mejor de los casos) cuando se utilizan marcos o técnicas similares.
Hay algo que en un principio decidí no tocar, debido a su controversia: el tiempo de descarga. Atendiendo a este argumento, en circunstancias normales no se obtendrán resultados que permitan inclinar la balanza a favor o en contra del uso de marcos. Evidentemente, si contamos con un menú común que "pesa" 150 Kb él solito, las páginas tardan una eternidad en representarse (salvo que la mayor parte de su tonelaje derivase del uso de imágenes, con lo cual la lectura de la caché aceleraría notablemente el proceso en sucesivas peticiones). Es lógico pensar que el uso de un sistema de marcos evitaría tiempos de espera innecesarios. Pero el problema fundamental en este caso es más simple que el debate que nos ocupa, y reside en lo poco apropiado que resulta un menú de tan "generosas" proporciones.
Realmente, la gestión de un sitio mediante marcos se queda pequeña a las primeras de cambio. El más que discutible ahorro de recursos que parece ofrecer en un principio se convierte en una soga que limita el desarrollo a una inflexible distribución de contenidos. Los marcos constituyen un sistema de representación, pero más allá de opiniones acerca de su idoneidad en ese sentido o de sus evidentes problemas de accesibilidad y compatibilidad, lo cierto es que lastran sin solución el proceso previo de todo desarrollo, la fase de estructuración. Y es que una web es algo más que unos cuantos miles de píxeles incrustándose sobre la pantalla de un monitor.
Publicado por Nuwamda, 15/03/04, 10:37
Tengo una página a la que le doy un diseño en la cual el contenido tiene que estar en una div de tamaño fijo adentro del diseño (digamos como una ventanita).
Esa div la única scrollbar que puede tener es la vertical (o sea para desplazar el contenido), horizontal no es requerido (le doy propiedades al contenido de ese div de manera que no sobrepase el ancho de la div)(y no queda bien visualmente la scrollbar horizontal)
La solución sería ponerle un overflow: scroll a la div. El problema: en ie me pone perfecto sólo la scrollbar vertical, ..pero en firefox/mozilla me pone la vertical y la horizontal.
La única forma que encontré de solucionar esto es en lugar de poner una div es poner un iframe (de esta manera seguro sólo se genera la scrollbar vertical)
Sugerencias bienvenidas.
Publicado por Nuwamda, 16/03/04, 03:38
Retiro lo dicho. Con overflow: scroll pone las dos scrollbars, con auto pone la necesaria.
Publicado por ReNNoN, 08/06/04, 04:45
Podeis usar un include en php, ¿que quiere decir esto?, facil..intentale explicarlo de una forma facil y rapida
donde pongas un include, ese "hueco" (supongamos que ponemos el include dentro de una tabla), ese hueco se convierte en un "recargador de paginas" es decir, todas las secciones que agreguemos al include, podemos cargarlas en el include. Aqui va el codigo
<?php
switch ($HTTP_GET_VARS['secciones']) {
case 1: include("noticias.php"); break;
case 2: include("descargas.php"); break;
case 3: include("informacion.php"); break;
default: include("home.php"); break;
}
?>
Supongamos que ponemos ese codigo en una tabla, en una pagina llamada: index.php, solo debemos de poner la "montura" de la web y poner en medio de la tabla donde queremos que se cargue las secciones, ese codigo.
Vamos a suponer que nuestra web tiene 3 secciones y un Home, la seccion Noticias, la seccion Descargas, la Seccion informacion y la seccion: HOME.
En el codigo podemos apreciar que pone: default: include("home.php"); break;
ahí ponemos la pagina que aparecera por defecto al cargar nuestra web, en este caso, la del ejemplo se llama: Home.php
Tambien podemos ver en el codigo las otras secciones.
Para cargar el codigo de un include tenemos que ponerle al "enlace" del boton, que vaya al include y coja la pagina que tenemos y la cargue en la web,
por ejemplo, si la pagina en la que hemos puesto el include, se llama: index.php, y queremos cargar en el include la seccion: informacion, pues en el boton ponemos lo siguiente:
<a href="index.php?secciones=3"> Pincha aquí para ir a la seccion de informacion </a>
de esa forma la pagina informacion.php se carga en el include y todo sigue apareciendo, los botones y todo.
POSDATA: podemos agregar mas secciones al include, claro esta... case 4.. case 5.. case 6.. y todos los que querais, suerte.
Se que es un poco cutre y no es gran cosa la explicacion, pero tenia prisa, sorry.
Publicado por Contremo, 19/08/04, 08:57
<p>La verdad es que llevo un buen rato navegando por ahi intentando encontrar solución a un problemilla gilipollas que me pasa con overflow:scroll.</p>
<p>El asunto es que tengo una estructura de arbol generado con php y utilizando unicamente las etiquetas div y span para posicionar los elementos, y luego todo eso apoyado con CSS para darle aspecto...</p>
<p>El problema surge cuando a la hora de expandir el arbol este sobrepasa el ancho asignado en horizontal (en vertical la barra de scroll funciona perfectamente), puesto que en lugar de seguir expandiendose hacia la derecha (accediendo al contenido que queda fuera del ancho asignado a traves del scroll lateral), el texto salta a la linea inferior, lo cual hace que el aspecto visual del árbol se resienta grandemente.</p>
<p>¿Alguien tiene alguna idea de por qué sucede esto y de ser así, hay alguien que tenga una idea de como solucionarlo (o alguna página donde pueda buscar información)?</p>Gracias a todos
Publicado por jj, 22/06/06, 01:32
En todos los comentarios anteriores no he conseguido saber porqué no es recomendable utilizar marcos en las páginas web, más bien todo lo contrario. La única conclusión a la que he podido llegar esque no se debe utilizar porque las empresas de buscadores y otras, no han consiguido un algoritmo que funcione correctamente con este tipo de objetos y por eso la quieren quitar del estandar w3, es lo que yo sospecho.
Para ir de Madrid a Roma no hace falta cruzar el estrecho de Bering ni el canal de Suez a no ser que quieras y puedas justificar gastos en tu empresa, salvo que de paso puedas realizar una visita beneficiosa para ésta. La ulilización de XML,PHP,APPLET,CSS y similares están muy recomendadas para determinadas tareas específicas que no se puedan realizar con HTML, pero si se utilizan para una estructura en la que se pueda usar HTML es perder tiempo y dinero ajeno o propio; si se utiliza para investigar soluciones que superen a la sencillez de HTML, "chapeau" , pero en ese caso ¿poque no utilizar java?.
En cuanto a la utilización de marcos dentro de otro marco, que apuntais irónicamente, no veo el pecado que tiene y sí un beneficio muy importante que consiste en no perder la referencia del sitio, que es el gran pecado de los diseñadores actuales, y es por lo que los empresarios siempre quieren una cabecera fija. Estoy hasta las narices de dar vueltas a la ruleta y pinchar 14 veces, retrocer otras tantas poque por ese camino no es, que un "script" me rompe el historico y tengo que empezar de nuevo para llegar a la pagina que me interesa o que un enlace me funciona en un determinado navegador y en otro no, etc, etc....,
En cuanto a los tiempos de descarga o que es más beneficioso si un "sprip" se ejecuta en un servidor que está hechando humo o en un cliente que se usa para el Emule y ver el correo y alguna cosilla más, sería de larga discusión.
En cuanto a la conclusión de ésta reflexión que me habeis provocado, solo tengo que decir que seguiré utilizando marcos cuando
página lo requiera confeccionandolas de la manera más sencillas y ajustandome lo más posibles al "standar" w3 y dejando modas
creadas por intereses o espontaneas aparte.
Publicado por Van Damme, 28/02/07, 03:39
Dice JJ que...
> "... por eso la quieren quitar del estandar w3, es lo que yo sospecho."
¿Pruebas?
> "XML,PHP,APPLET,CSS y similares están muy recomendadas para determinadas
> tareas específicas que no se puedan realizar con HTML"
Aquí empiezo a ver parte del problema. Si eres capaz de mezclar sin el menor pudor técnicas tan dispares y decir que pueden sustituir al HTML, entonces creo que no sabes lo que es el HTML. Probablemente tu editor favorito te oculta el código y tu difusa idea del mismo te permite pensar tamaños disparates.
> "Estoy hasta las narices de dar vueltas a la ruleta y pinchar
> 14 veces, retrocer otras tantas poque por ese camino no es,
> que un "script" me rompe el historico... "
Aquí ya sí que llegamos al paroxismo. ¿Todo eso pasa por no utilizar marcos? Creo que vivmos en realidades diferentes.
> " y dejando modas creadas por intereses o espontaneas aparte."
Francamente, tiras piedras contra tu propio razonamiento. La moda fue precisamente el uso de marcos.
> "En todos los comentarios anteriores no he conseguido saber porqué
> no es recomendable utilizar marcos en las páginas web"
Yo lo que no he encontrado es una sola ventaja de los marcos dicha por alguien que realmente sepa diferenciar un lenguaje de marcas de un tarro de mermelada.
En fin... no hay peor ciego que el que no quiere ver (Voltaire)
Publicado por oezkaucvs ksrf, 19/08/07, 01:12
drihs nfrsy kipzhl exwmyitp repltm zbjmg jmtuo
Publicado por Peto, 29/10/07, 10:42
Gracias ReNNoN, espero que eso me sirva para lo que yo intento hacer (algo como un frame que no reviente al entrar en una pagina que tiene un script para no ser cargada en un marco).
A Van Damme: Le das mucha caña a JJ, y ha dicho algunas verdades muy grandes.
Si los frames no son bien seguidos por los robots es algo que los robots deberían mejorar y si no funcionan con software especializado de accesibilidad es algo que ese software deberá mejorar.
No creo que haya que cambiar todas las paginas de internet que tienen frames y en donde son útiles solo porque no les gusten a los robots o los programas de accesibilidad.
Por suerte, aunque quede muy divertido simularlo, las maquinas no opinan, se limitan a hacer lo que hacen.
Especialmente desgraciada me parece la frase: "Por ejemplo HTML, cuya funcionalidad queda bastante maltrecha cuando se utilizan marcos"... dependerá de cuándo, cómo y para qué se utilicen.
Si quiero que en mi página haya una pequeña parte en la que puedas navegar independientemente de donde estes en el principal y además mi servidor no me deja usar php, jsp ni nada ¿qué debo hacer? Creo que usar frames no es malo en si mismo.
Además no me gusta que las páginas lleven esa sentencia javascript para evitar que se carguen en un frame, es el usuario el que decide donde ver una pagina, obligar a que tu web ocupe todo el navegador es quitar libertad al usuario. Aunque entiendo que se hace para evitar que una pagina cargue otras en un frame y dejar puesto su banner, pero es como evitar los popups, solo sirve para quitar la publicidad indeseable (y algunas páginas virus sin vergüenza) y a cambio muchas veces crea molestias (como en las descargas).
Total que yo creo que los frames no son malos, tampoco los popups, lo malo es la gente que hace publicidad molestando al usuario. Antes de quitar los frames deberían prohibir las paginas que atacan al usuario, que le roban libertad para navegar como le de la gana. Quizá los robots deberían localizar estas páginas y marginarlas en los resultados de búsquedas... no sé, pero eso es un problema, y no los frames.
Publicado por comonsense, 04/12/07, 03:00
Una breve defensa al uso de los FRAMES.
A no rasgarse las vestiduras por usar marcos.(cuando se los usa bien se entiende)
Hay veces y muchas, que usar marcos es lo mejor que hay y es insuperable.
Su estructura natural permite el mejor ordenamiento y claridad de navegación fijando un
punto base de referencia.
Los marcos se inventaron hace tiempo y no por antiguos se desechan.
La lista de "desventajas" es antojadiza y rebuzcada, y además hay soluciones muy
pero muy simples para eliminar lo que se "vende" como desventajas.
10/05/2002 (actualizado el 18/12/2002). sysifus. Debate nº 2.
Estás en: tierra de nómadas > debates > A vueltas con los marcos.