¿Cómo vincular varios documentos HTML5?
Resuelto
THEGAMERGAMING54
Mensajes publicados
31
Estado
Miembro
-
Lansquenet -
Lansquenet -
Hola a todos! Estoy programando una página HTML que contendrá muchas imágenes (unas cien, diría) y me gustaría vincular mi archivo index.html a otro archivo donde cargaría mis imágenes para que mi index no sea demasiado largo; los dos archivos están en la misma carpeta (uso VS Code).
¿Alguien tendría alguna solución?
gracias
¿Alguien tendría alguna solución?
gracias
5 respuestas
Hola,
Cuando hablas de "ligar", creo que quieres decir "incluir"
El HTML no es un lenguaje de programación...
Y entonces, aparte de pasar por un lenguaje servidor ( como PHP) no podrás.
--
.
Cordialmente,
Jordane
Cuando hablas de "ligar", creo que quieres decir "incluir"
El HTML no es un lenguaje de programación...
Y entonces, aparte de pasar por un lenguaje servidor ( como PHP) no podrás.
--
.
Cordialmente,
Jordane
Hola,
sí y no.Todo como para mostrar una imagen en una página no incluyes el archivo en el HTML
sino indicas la dirección donde se encuentra la imagen para que se muestre, esa será la dirección del archivo a mostrar que está almacenado en una variable.
Es lo mismo con una base de datos; aunque es posible almacenar un archivo en una base de datos, es mucho más simple y eficiente almacenar únicamente la ubicación donde se encuentra. Este principio de enlazar elementos entre sí mediante un texto que conduce a un recurso (la imagen a su visualización en una página HTML, el CSS para una página HTML, el script de un programa JavaScript en la página HTML, ...) se llama hipermedia.
La pregunta principal es sobre todo: ¿por qué quieres mostrar 100 imágenes en una página?
Es algo que hay que evitar a toda costa por muchas razones.
Reglas gráficas y de maquetas:
_ El ojo y el cerebro humano tienen sus límites; es completamente innecesario presentar muchas imágenes al mismo tiempo, ya que no pueden ser consultadas todas a la vez. Simplemente pon un rectángulo con 4 imágenes encima y verás que no puedes mirar varias imágenes a la vez y tener sentido.
Lo mismo ocurre si el contenido de tu página es demasiado voluminoso (imágenes o textos): se vuelve tedioso desplazarse por una página y es mucho más eficiente hacer varias páginas que forzar al usuario a hacer esfuerzos para ver contenidos sucesivos que mentalmente serán más difíciles de clasificar. El resultado de tal cantidad es lógicamente que nada se valore y que pierdas el mensaje principal y/o que ninguna imagen destaque, dando la impresión no de profusión sino de falta de orden y coherencia porque ningún mensaje/imagen particular pueda identificarse directamente (en una fracción de segundo).
La regla de oro de cualquier publicación es la claridad y un gran número de elementos sin que se destaque un pequeño número (1 o 2 o incluso 3) es simplemente contraproducente, ya que ningún mensaje particular surgirá de inmediato y obliga al cerebro a hacer esfuerzos para encontrar un sentido o mensaje en lo que ves, por lo que no invita a interesarte por la publicación.
Ver también qué es la ergonomía web.
Limitación/impacto técnico:
_Puede ser la motivación de tu pregunta, pero mostrar una página significa que los contenidos a mostrar (mediante enlaces hipervínicos) deben ser cargados (descargados) por el equipo del usuario. Una página que contiene muchos archivos voluminosos a cargar lógicamente tarda más en cargarse. Desde los inicios de la WWW, cuando las velocidades de conexión (por tanto la transferencia de archivos) eran menores, siempre se ha buscado que una página se cargue rápidamente (por contenidos por página), no demasiado voluminosos para evitar que el usuario tenga que esperar para que la página se muestre; lo cual para la mayoría de los usuarios hará que no esperen y se vayan a otro sitio, o si permanecen para consultar la página una vez cargada, probablemente no volverán al sitio y encontrarán el sitio mal hecho (porque hay que esperar y los otros sitios son inmediatos), por lo que inconscientemente el contenido propuesto/presente será considerado malo ya que el sitio está mal hecho.
Por lo tanto mostrar un gran número de fotos simultáneamente en una página es totalmente contraproducente y hay que evitarlo. Por gran número me refiero a 10 o más en buena calidad o 2 o 3 en alta calidad (= archivo más pesado).
¿Cuáles son las soluciones?
Ya he dado la mejor solución: no mostrar un gran número de imágenes por página. Por tanto, dividir en distintas páginas.
La informática permite, mediante programación, automatizar cierta cantidad de tareas.
Así incluir un elemento de tipo diapositivas/vision de imágenes puede ser una buena opción en este caso.
En lugar de mostrar 10 imágenes seguidas, hacer que las imágenes se deslicen dentro de un marco, haciendo cada imagen única (un cerebro/visión humana no puede concentrarse en varias imágenes a la vez) que serán sucesivas es significativamente más eficaz si la solución de dividir la página en varias no le satisface.
Pero, por supuesto, deslizar muchas más imágenes vuelve al mismo problema mencionado arriba: ninguna se pone en valor y es tedioso y aburrido deslizar (o ver deslizar) un gran número de imágenes, y ninguna destaca; las imágenes al inicio del desplazamiento serán las únicas que realmente capten la atención.
Existe otro tipo de automatización, pero requiere páginas dinámicas. Esto quiere decir que los archivos de las imágenes (o más bien la dirección de su ubicación URL) estén almacenados en una base de datos y que un programa (por ejemplo PHP) pueda generar la visualización de forma que varíe (posibilidad de clasificación, ordenación, diversas organizaciones) que permita al usuario acceder claramente a la información o a las imágenes que quiere ver. Enlazar páginas entre sí se llama simplemente crear un enlace que permite ir de una página a otra
Por supuesto se pueden (y deben) combinar las diferentes técnicas posibles.
Así nada impide tener un programa PHP apoyándose en una base de datos que va a mostrar imágenes en una visión hecha en JavaScript (y sí, todo está interconectado, las tecnologías son complementarias, conexas y siguen siendo tecnologías diferentes con cada papel y utilidad). y por supuesto si eso requiere tener varias páginas (dinámicas o no) no hay razón para privarse de ello.
Importante:
Los sitios web requieren ser páginas dinámicas:
los contenidos o una parte de lo que se muestra (textos, imágenes, ...) son proporcionados por la base de datos al programa que generará (automatización) la visualización y permite la inclusión de criterios que pueden variar en el tiempo.
Concretamente, esto significa que si necesitas cambiar, añadir o modificar imágenes (o otros contenidos) si tienes un programa que automatiza el tratamiento de contenidos, basta con cambiar el contenido de la base de datos para ello. Sin eso tendrías que rehacer el trabajo de maquetación, presentación y escritura de la página cada vez, lo cual a la larga es una pérdida de tiempo enorme porque obliga a hacer el trabajo cada vez.
La automatización posible es la única solución válida si quieres un sitio durable que pueda ser gestionado fácilmente, en lugar de tener que reescribir HTML, CSS y eventualmente JavaScript cada vez que quieras el menor cambio. Cuantos más contenidos tengas, más a menudo tendrás que modificar esos contenidos, más trabajo llevará, a menos que uses páginas dinámicas.
Y si piensas que tu sitio no necesita cambiar con el tiempo, te equivocas; existen casos así, son los sitios estáticos. Pueden servir pero siguen siendo sitios de menor calidad y valor agregado para los usuarios y tienen menos probabilidades de presentar interés frente a otros que ofrecen mejor y contenidos que pueden variar.
sí y no.Todo como para mostrar una imagen en una página no incluyes el archivo en el HTML
<img src="mon_image.jpg" alt="description image" />
sino indicas la dirección donde se encuentra la imagen para que se muestre, esa será la dirección del archivo a mostrar que está almacenado en una variable.
Es lo mismo con una base de datos; aunque es posible almacenar un archivo en una base de datos, es mucho más simple y eficiente almacenar únicamente la ubicación donde se encuentra. Este principio de enlazar elementos entre sí mediante un texto que conduce a un recurso (la imagen a su visualización en una página HTML, el CSS para una página HTML, el script de un programa JavaScript en la página HTML, ...) se llama hipermedia.
La pregunta principal es sobre todo: ¿por qué quieres mostrar 100 imágenes en una página?
Es algo que hay que evitar a toda costa por muchas razones.
Reglas gráficas y de maquetas:
_ El ojo y el cerebro humano tienen sus límites; es completamente innecesario presentar muchas imágenes al mismo tiempo, ya que no pueden ser consultadas todas a la vez. Simplemente pon un rectángulo con 4 imágenes encima y verás que no puedes mirar varias imágenes a la vez y tener sentido.
Lo mismo ocurre si el contenido de tu página es demasiado voluminoso (imágenes o textos): se vuelve tedioso desplazarse por una página y es mucho más eficiente hacer varias páginas que forzar al usuario a hacer esfuerzos para ver contenidos sucesivos que mentalmente serán más difíciles de clasificar. El resultado de tal cantidad es lógicamente que nada se valore y que pierdas el mensaje principal y/o que ninguna imagen destaque, dando la impresión no de profusión sino de falta de orden y coherencia porque ningún mensaje/imagen particular pueda identificarse directamente (en una fracción de segundo).
La regla de oro de cualquier publicación es la claridad y un gran número de elementos sin que se destaque un pequeño número (1 o 2 o incluso 3) es simplemente contraproducente, ya que ningún mensaje particular surgirá de inmediato y obliga al cerebro a hacer esfuerzos para encontrar un sentido o mensaje en lo que ves, por lo que no invita a interesarte por la publicación.
Ver también qué es la ergonomía web.
Limitación/impacto técnico:
_Puede ser la motivación de tu pregunta, pero mostrar una página significa que los contenidos a mostrar (mediante enlaces hipervínicos) deben ser cargados (descargados) por el equipo del usuario. Una página que contiene muchos archivos voluminosos a cargar lógicamente tarda más en cargarse. Desde los inicios de la WWW, cuando las velocidades de conexión (por tanto la transferencia de archivos) eran menores, siempre se ha buscado que una página se cargue rápidamente (por contenidos por página), no demasiado voluminosos para evitar que el usuario tenga que esperar para que la página se muestre; lo cual para la mayoría de los usuarios hará que no esperen y se vayan a otro sitio, o si permanecen para consultar la página una vez cargada, probablemente no volverán al sitio y encontrarán el sitio mal hecho (porque hay que esperar y los otros sitios son inmediatos), por lo que inconscientemente el contenido propuesto/presente será considerado malo ya que el sitio está mal hecho.
Por lo tanto mostrar un gran número de fotos simultáneamente en una página es totalmente contraproducente y hay que evitarlo. Por gran número me refiero a 10 o más en buena calidad o 2 o 3 en alta calidad (= archivo más pesado).
¿Cuáles son las soluciones?
Ya he dado la mejor solución: no mostrar un gran número de imágenes por página. Por tanto, dividir en distintas páginas.
La informática permite, mediante programación, automatizar cierta cantidad de tareas.
Así incluir un elemento de tipo diapositivas/vision de imágenes puede ser una buena opción en este caso.
En lugar de mostrar 10 imágenes seguidas, hacer que las imágenes se deslicen dentro de un marco, haciendo cada imagen única (un cerebro/visión humana no puede concentrarse en varias imágenes a la vez) que serán sucesivas es significativamente más eficaz si la solución de dividir la página en varias no le satisface.
Pero, por supuesto, deslizar muchas más imágenes vuelve al mismo problema mencionado arriba: ninguna se pone en valor y es tedioso y aburrido deslizar (o ver deslizar) un gran número de imágenes, y ninguna destaca; las imágenes al inicio del desplazamiento serán las únicas que realmente capten la atención.
Existe otro tipo de automatización, pero requiere páginas dinámicas. Esto quiere decir que los archivos de las imágenes (o más bien la dirección de su ubicación URL) estén almacenados en una base de datos y que un programa (por ejemplo PHP) pueda generar la visualización de forma que varíe (posibilidad de clasificación, ordenación, diversas organizaciones) que permita al usuario acceder claramente a la información o a las imágenes que quiere ver. Enlazar páginas entre sí se llama simplemente crear un enlace que permite ir de una página a otra
<a href="pagesuivante.html">ir a la página siguiente</a>
Por supuesto se pueden (y deben) combinar las diferentes técnicas posibles.
Así nada impide tener un programa PHP apoyándose en una base de datos que va a mostrar imágenes en una visión hecha en JavaScript (y sí, todo está interconectado, las tecnologías son complementarias, conexas y siguen siendo tecnologías diferentes con cada papel y utilidad). y por supuesto si eso requiere tener varias páginas (dinámicas o no) no hay razón para privarse de ello.
Importante:
Los sitios web requieren ser páginas dinámicas:
los contenidos o una parte de lo que se muestra (textos, imágenes, ...) son proporcionados por la base de datos al programa que generará (automatización) la visualización y permite la inclusión de criterios que pueden variar en el tiempo.
Concretamente, esto significa que si necesitas cambiar, añadir o modificar imágenes (o otros contenidos) si tienes un programa que automatiza el tratamiento de contenidos, basta con cambiar el contenido de la base de datos para ello. Sin eso tendrías que rehacer el trabajo de maquetación, presentación y escritura de la página cada vez, lo cual a la larga es una pérdida de tiempo enorme porque obliga a hacer el trabajo cada vez.
La automatización posible es la única solución válida si quieres un sitio durable que pueda ser gestionado fácilmente, en lugar de tener que reescribir HTML, CSS y eventualmente JavaScript cada vez que quieras el menor cambio. Cuantos más contenidos tengas, más a menudo tendrás que modificar esos contenidos, más trabajo llevará, a menos que uses páginas dinámicas.
Y si piensas que tu sitio no necesita cambiar con el tiempo, te equivocas; existen casos así, son los sitios estáticos. Pueden servir pero siguen siendo sitios de menor calidad y valor agregado para los usuarios y tienen menos probabilidades de presentar interés frente a otros que ofrecen mejor y contenidos que pueden variar.
Gracias por tu respuesta, pero en realidad me gustaría hacer un juego en 2D, un Visual Novel (un juego narrativo donde el jugador elige entre varias opciones representadas por botones que muestran una imagen diferente y cambiará la historia en función de las elecciones del jugador) accesible desde internet, y quizá debería haber empezado por ahí... por eso quiero cargar las imágenes aparte del código base, porque hay que almacenar todas las escenas posibles... para mostrarlas en el momento adecuado (en un canvas de JavaScript para facilitar la interacción).
Ok,
entonces no son 100 imágenes para cargar en una página...
Todo lo que he dicho sigue siendo verdad y aplicable a su proyecto.
Olvidé - el mensaje ya era largo - mencionar las posibilidades de precarga, pero también porque en el caso de 100 imágenes ninguna solución es adecuada: simplemente no hay que cargar 100 imágenes.
En cuanto a hacer un juego (o un sitio) hay que hacer más que desear, hay que trabajar/aprender a hacerlo.
Lo que quieren hacer es relativamente simple (supongo que CANVAS es para añadir animación y efectos? porque para mostrar imágenes hay la etiqueta IMG que basta ampliamente) y si quieren hacerlo de la mala manera no necesitan programación sino saber cómo funciona un ENLACE a otra página.
Bien sûr avec la programmation on peut faire mieux et par exemple modifier texte et images ainsi que gérer l'interaction(programmation événementielle),
ceci change un texte quand non clique:
https://www.w3schools.com/jsref/prop_html_innerhtml.asp
Comme JavaScript peut manipuler HTML et CSS il peut donc manipuler quel fichier est chargé par une image(balise img en HTML) de la même manière ainsi que n'importe quel élément d'une page.
Je vous suggère donc d'apprendre(travailler quoi ;) ) et de voir déjà ce qu'en quelques mois de cours vous arrivez à faire. Ça vous évitera de vous poser des questions qui n'ont pas lieu d'être.
C'est très basique ce que vous voulez donc facilement abordable(voir mon exemple en pur HTML). Vous avez aussi des outils dédiés à la création de jeu qui ont une autre approche(exemple: unity3D).
C'est bien souhaiter mais sans travail vous n'aurez rien. Vous devriez commencer par là histoire de vous confronter à la réalité plutôt que d'imaginer des choses qui n'ont pas lieu d'être et comme ça vous parlerez (ou aurez des questions) sur des sujets réels.
Si on change l'adresse d'une image avec JavaScript une seule image est chargée à la fois que vous le fassiez 100 fois ou mille. Si c'est lors d'un événement(en programmation) comme un clic sur un bouton(de là au choix interactif il n'y a qu'un pas) qui déclenche une fonction du programme qui va modifier l'image affichée l'image n'est téléchargée(download) que au moment du clic donc il n'y a pas à charger 100 images simultanément.
Après bien sûr il existe des techniques nettement plus avancées et des possibilités très large pour améliorer aussi bien ce qui est offert à l'utilisateur du programme que pour faciliter le développement et améliorer la qualité de celui ci; comme le préchargement d'image.
Mais bon avant d'aller vers des techniques plus avancées il faut passer par les trucs de bases, que vous n'avez pas.
entonces no son 100 imágenes para cargar en una página...
Todo lo que he dicho sigue siendo verdad y aplicable a su proyecto.
Olvidé - el mensaje ya era largo - mencionar las posibilidades de precarga, pero también porque en el caso de 100 imágenes ninguna solución es adecuada: simplemente no hay que cargar 100 imágenes.
En cuanto a hacer un juego (o un sitio) hay que hacer más que desear, hay que trabajar/aprender a hacerlo.
Lo que quieren hacer es relativamente simple (supongo que CANVAS es para añadir animación y efectos? porque para mostrar imágenes hay la etiqueta IMG que basta ampliamente) y si quieren hacerlo de la mala manera no necesitan programación sino saber cómo funciona un ENLACE a otra página.
<img src="imagedebut.jpg" alt="début du jeu" /> <p>Voulez vous commencer?</p> <a href="pagedebutdujeu.html">oui</a> <a href="autres.html">non</a>
Bien sûr avec la programmation on peut faire mieux et par exemple modifier texte et images ainsi que gérer l'interaction(programmation événementielle),
ceci change un texte quand non clique:
https://www.w3schools.com/jsref/prop_html_innerhtml.asp
Comme JavaScript peut manipuler HTML et CSS il peut donc manipuler quel fichier est chargé par une image(balise img en HTML) de la même manière ainsi que n'importe quel élément d'une page.
Je vous suggère donc d'apprendre(travailler quoi ;) ) et de voir déjà ce qu'en quelques mois de cours vous arrivez à faire. Ça vous évitera de vous poser des questions qui n'ont pas lieu d'être.
C'est très basique ce que vous voulez donc facilement abordable(voir mon exemple en pur HTML). Vous avez aussi des outils dédiés à la création de jeu qui ont une autre approche(exemple: unity3D).
C'est bien souhaiter mais sans travail vous n'aurez rien. Vous devriez commencer par là histoire de vous confronter à la réalité plutôt que d'imaginer des choses qui n'ont pas lieu d'être et comme ça vous parlerez (ou aurez des questions) sur des sujets réels.
Si on change l'adresse d'une image avec JavaScript une seule image est chargée à la fois que vous le fassiez 100 fois ou mille. Si c'est lors d'un événement(en programmation) comme un clic sur un bouton(de là au choix interactif il n'y a qu'un pas) qui déclenche une fonction du programme qui va modifier l'image affichée l'image n'est téléchargée(download) que au moment du clic donc il n'y a pas à charger 100 images simultanément.
Après bien sûr il existe des techniques nettement plus avancées et des possibilités très large pour améliorer aussi bien ce qui est offert à l'utilisateur du programme que pour faciliter le développement et améliorer la qualité de celui ci; comme le préchargement d'image.
Mais bon avant d'aller vers des techniques plus avancées il faut passer par les trucs de bases, que vous n'avez pas.
Finalmente encontré una solución a mi problema, así que lo miré desde otro punto de vista: en lugar de descubrir cómo vincular dos páginas HTML para almacenar mis imágenes, vinculé mi código HTML a un archivo .js en el que tengo la lista de imágenes.
utilicé para ello
Gracias de nuevo a ustedes por haberme orientado.
utilicé para ello
document.write("<img id=\"img1\" src=\"img/mon_image.png\">")
Gracias de nuevo a ustedes por haberme orientado.
document.write es ABAOLUTAMENTE EVITADO por razones bien conocidas.
https://developer.mozilla.org/en-US/docs/Web/API/Document/write
Por supuesto hay que utilizar la creación de elementos con el método createElement e incluir los elementos con appendChild; de lo contrario arruinará el DOM (borrar todo el contenido de la página antes de escribir el nuevo) o, alternativamente, innerHTML o innerText según si hay que añadir/modificar un elemento de la página o el texto de la página.
Todavía no has entendido que para mostrar una página HTML debe ser leída por un navegador... entonces las páginas HTML son independientes (2 páginas mostradas = 2 pestañas del navegador = 2 páginas diferentes).
https://developer.mozilla.org/en-US/docs/Web/API/Document/write
Por supuesto hay que utilizar la creación de elementos con el método createElement e incluir los elementos con appendChild; de lo contrario arruinará el DOM (borrar todo el contenido de la página antes de escribir el nuevo) o, alternativamente, innerHTML o innerText según si hay que añadir/modificar un elemento de la página o el texto de la página.
Todavía no has entendido que para mostrar una página HTML debe ser leída por un navegador... entonces las páginas HTML son independientes (2 páginas mostradas = 2 pestañas del navegador = 2 páginas diferentes).