nicht angemeldet
HTML Imports: Wie umsetzen?
0 
Gunnar Bittersmann
0 
Henry
0 
Rolf B
0 
JürgenB
0 -2 Linuchs
0 0 Gunnar Bittersmann
0 
Auge
HTML Imports: Wie umsetzen?
Ich möchte eine statische Website erstellen. Jede Seite soll den gleichen Footer haben und dessen Quelltext aus einer footer.html importieren. Damit spätere Änderungen am Footer nur an einer Stelle vorzunehmen sind.
<link rel="import" href="footer.html"> wird leider von namenhaften Browsern nicht unterstützt. Diese Option fällt für mich daher weg.
Könnt Ihr Stichworte nennen wie ich das Problem per HTML oder JavaScript löse? PHP möchte ich nicht nutzen.
-
@@Oli
Jede Seite soll den gleichen Footer haben und dessen Quelltext aus einer
footer.htmlimportieren. […]
Könnt Ihr Stichworte nennen wie ich das Problem per HTML oder JavaScript löse?Per HTML gar nicht. Wenn sowas mal in reinem HTML vorgesehen war, wurde es nie browserübergreifend implementiert.
Clientseitiges JavaScript ist auch keine gute Option, da nicht immer verfügbar.
PHP möchte ich nicht nutzen.
Warum nicht?
Dann nimm eine andere serverseitige Technik: SSI, JavaScript (Node.js), …
LLAP 🖖
--
„Man kann sich halt nicht sicher sein“, sagt der Mann auf der Straße, „dass in einer Gruppe Flüchtlinge nicht auch Arschlöcher sind.“
„Stimmt wohl“, sagt das Känguru, „aber immerhin kann man sich sicher sein, dass in einer Gruppe Rassisten nur Arschlöcher sind.“
—Marc-Uwe Kling -
Hallo Oli,
Könnt Ihr Stichworte nennen wie ich das Problem per HTML oder JavaScript löse? PHP möchte ich nicht nutzen.
PHP wäre aber besser dafür geeignet und ist zumindest für solche Dinge auch schnell erlernbar. Aber gut, es geht natürlich auch mit HTML, da fallen mir dann Frames, insbesondere Iframes ein. Empfehlenswert ist das für diesen Fall aber nicht, weil du in Wirklichkeit immer noch mehrere Seiten hast, die nicht unbedingt miteinander gut kommunizieren können und alle ihre eigenen Metaangaben haben müssen.
Dann gäbe es noch JS um das zu realisieren, doch dich da einzuarbeiten und dann am Ende doch kein perfektes Ergebnis zu haben, wäre die Zeit besser in PHP investiert.
Andere Möglichkeiten, wie zb. SSI lasse ich mal ganz außen vor.
Gruss
Henry--
Meine Meinung zu DSGVO & Co:
„Principiis obsta. Sero medicina parata, cum mala per longas convaluere moras.“ -
Hallo Oli,
PHP möchte ich nicht nutzen.
Dann wären eigentlich Server Side Includes das Mittel der Wahl - sofern vom Serverbetreiber erlaubt.
Rolf
--
sumpsi - posui - clusi -
Hallo Oli,
wieviele Seiten hat deine Site und wie oft ändert sich der Footer?
Ich würde bei einer kleinen statischen Site Copy & Paste nehmen.
Gruß
Jürgen -
Hallo Oli,
ich würde bei einer statischen Seite einen Static Site Generator wie Hugo verwenden.
LG,
CK -
Könnt Ihr Stichworte nennen wie ich das Problem per HTML oder JavaScript löse? PHP möchte ich nicht nutzen.
Ich verstehe die Abneigung gegen iframes nicht. Selbstverständlich kannst du in einem HTML-Code ein iframe einbinden, der ein eigenständiges HTML-Dokument lädt. Sogar von einer fremden Domain.
<iframe src="http://example.com/footer.html" style="width:100%;height:1em;"></iframe>Ebenso kannst du von deiner oder einer fremden Domain eine *.js-Datei laden, die etwas in deine Webseite schreibt. Ich arbeite mit *.js-Dateien von Leaflet. Bedingung, um Landkarten zu zeigen.
Ich hatte gerade so eine Diskussion um Javascript. SelfHTML-Mitglieder behaupten, dass so eine Datei besonders zögerlich oder gar nicht geladen werden könnte. Warum das ausgerechnet *.js-Dateien, aber nicht CSS-Dateien betreffen sollte, haben sie nicht verraten.
Ich meine, dann wird auch die Rumpf-Datei nicht richtig geladen und angezeigt.
Seit Webseiten keine reinen ASCII-Textdateien mehr sind, laden sie in grafischen Benutzeroberflächen zahlreiche Dateien nach. Das kann verzögert passieren, aber nicht NICHT.
Gruß. Linuchs
-
Hallo Linuchs,
Ich hatte gerade so eine Diskussion um Javascript. SelfHTML-Mitglieder behaupten, dass so eine Datei besonders zögerlich oder gar nicht geladen werden könnte. Warum das ausgerechnet *.js-Dateien, aber nicht CSS-Dateien betreffen sollte, haben sie nicht verraten.
Das ist ein Missverständnis oder eine Missinterpretation. Natürlich kann das auch mit CSS passieren.
Seit Webseiten keine reinen ASCII-Textdateien mehr sind, laden sie in grafischen Benutzeroberflächen zahlreiche Dateien nach. Das kann verzögert passieren, aber nicht NICHT.
Das ist ein Irrtum. Beispiel-Szenarien, in denen das passieren kann, sind im verlinkten Thread aufgeführt.
LG,
CK -
@@Linuchs
<iframe src="http://example.com/footer.html" style="width:100%;height:1em;"></iframe>Das ist Unsinn.
Genauer gesagt:
height:1emist Unsinn. Du kannst die benötigte Höhe nicht kennen. Und deshalb ist die Idee mit dem Iframe Unsinn.Ich hatte gerade so eine Diskussion um Javascript.
Auf ebendiesen Thread hatte ich auch schon verwiesen.
Seit Webseiten keine reinen ASCII-Textdateien mehr sind, laden sie in grafischen Benutzeroberflächen zahlreiche Dateien nach. Das kann verzögert passieren, aber nicht NICHT.
Das ist Unsinn.
LLAP 🖖
--
„Man kann sich halt nicht sicher sein“, sagt der Mann auf der Straße, „dass in einer Gruppe Flüchtlinge nicht auch Arschlöcher sind.“
„Stimmt wohl“, sagt das Känguru, „aber immerhin kann man sich sicher sein, dass in einer Gruppe Rassisten nur Arschlöcher sind.“
—Marc-Uwe Kling-
Hallo Gunnar,
Das ist Unsinn.
Genauer gesagt:
height:1emist Unsinn. Du kannst die benötigte Höhe nicht kennen. Und deshalb ist die Idee mit dem Iframe Unsinn.Ist sie nicht, nur eben nicht empfehlenswert, aber nicht wegen der Höhe. Wieso sollte man die Höhe nicht kennen, wenn man oben einen Balken und unten einen Balken haben möchte? Das Mittelteil ist dann enstprechen kleiner. Wie gesagt nicht empfehlenswert, aber auch nicht "Unsinn". Manchmal nutze auch ich das so, für kleine Adminseiten, wo es dann sogar richtig Sinn machen kann, wenn ich asynchrone Sachen vermeiden möchte.
Gruss
Henry--
Meine Meinung zu DSGVO & Co:
„Principiis obsta. Sero medicina parata, cum mala per longas convaluere moras.“-
@@Henry
Ist sie nicht, nur eben nicht empfehlenswert, aber nicht wegen der Höhe. Wieso sollte man die Höhe nicht kennen, wenn man oben einen Balken und unten einen Balken haben möchte?
Ein Balken macht noch keinen Footer. Da sollte auch noch Inhalt drin sein.
Und wenn der Inhalt nicht gerade nur aus einem Wort besteht, kannst du nicht sicher sein, wieviele Zeilen – also welche Höhe – der Inhalt beansprucht.
Wie gesagt nicht empfehlenswert, aber auch nicht "Unsinn".
Ein Footer mit eigenem Scrollbalken würde ich schon Unsinn nennen.
Manchmal nutze auch ich das so, für kleine Adminseiten
Betonung auf „ich“. Die Adminseiten benutzt du in einer bestimmten Umgebung: großer Monitor, festgelegte Schriftart und -größe.
Für Webseiten gilt das nicht.
LLAP 🖖
--
„Man kann sich halt nicht sicher sein“, sagt der Mann auf der Straße, „dass in einer Gruppe Flüchtlinge nicht auch Arschlöcher sind.“
„Stimmt wohl“, sagt das Känguru, „aber immerhin kann man sich sicher sein, dass in einer Gruppe Rassisten nur Arschlöcher sind.“
—Marc-Uwe Kling
-
-
Genauer gesagt: height:1em ist Unsinn. Du kannst die benötigte Höhe nicht kennen. Und deshalb ist die Idee mit dem Iframe Unsinn.
Es gibt besonders in der Wissenschaft so viele unsinnige Ideen. Manche helfen aber erstmal, ein Problem erträglich zu machen, zu umschiffen, notdürftig zu flicken.
In meinen Füßen habe ich einen Einzeiler, deshalb 1em Höhe. Wenn jemand daherkommt und die Seite in eine Briefmarke quetscht, sieht man von der Seite nichts. Da kommt es auf den verkorksten footer auch nicht mehr an.
Seit meinen HTML Kinderschuhen 1995 habe ich immer irgendwelche Flicken hinbekommen, die später mit einem Federstrich zu lösen waren. Ich denke an abgerundete Ecken (heute border-radius), an Tabellen-Köpfe, die beim Scrollen oben stehen blieben (heute sticky) und den in der Höhe angepassten iframe habe ich auch gelöst.
Vermutlich wird der starre Käfig für bissige Fremdseiten eines Tages mit ein, zwei Simsalabims anschmiegsam werden.
So eine Diskussion wie diese gehört in die Comedy-Szene. So merkwürdig wie die Schwimmwesten in Flugzeugen. Wieviele Passagiere haben wegen angelegter Schwimmwesten bei Abstürzen auf See überlebt?
-
-
Hallo
Ich hatte gerade so eine Diskussion um Javascript. SelfHTML-Mitglieder behaupten, dass so eine Datei besonders zögerlich oder gar nicht geladen werden könnte. Warum das ausgerechnet *.js-Dateien, aber nicht CSS-Dateien betreffen sollte, haben sie nicht verraten.
Niemand hat behaupotet, dass nicht auch CSS-Dateien nicht geladen werden könnten. Das war halt nicht Thema des Threads, also hat es niemand erwähnt.
Ich meine, dann wird auch die Rumpf-Datei nicht richtig geladen und angezeigt.
Wenn das passiert, dann wird die Seiten halt mit dem Browser-Stylesheet angezeigt, wenn das HTML-Dokument selbst denn überhaupt (vollständig) geladen wird. Deshalb ist eine sinnvolle HTML-Struktur ja auch so wichtig. Gibt es sie, kann jeder Browser eine sinnvolle, wenn auch nicht unbedingt schöne Ausgabe erzeugen. Wenn die Dokumentstruktur, a.k.a. das HTML, nicht sinnvoll aufgebaut ist, kann die Anzeige ohne CSS in Müll enden.
Seit Webseiten keine reinen ASCII-Textdateien mehr sind, laden sie in grafischen Benutzeroberflächen zahlreiche Dateien nach. Das kann verzögert passieren, aber nicht NICHT.
Das kann sehr wohl passieren. Das ist mir am heutigen Vormittag mehrfach mit Github, dem SelfHTML-Forum und zwei weiteren Foren, die ich auf Arbeit immer im Hintergrund offen habe und, das gilt für die Foren, regelmäßig neu laden lasse. Keine Ahnung, ob das an unserem Internetanschluss lag oder am Netz unseres ISP, jedenfalls luden die Seiten immer wieder mal unvollständig oder überhaupt nicht und im Falle irgendwelcher Unterseiten eines Github-Projekts gelegentlich auch ohne CSS (vielleicht auch ohne JS, aber das bemerke ich ohne Interaktion nicht; keine Ahnung, warum das zu dem Zeitpunkt nicht aus dem Cache kam).
Tschö, Auge
--
Ein echtes Alchimistenlabor musste voll mit Glasgefäßen sein, die so aussahen, als wären sie beim öffentlichen Schluckaufwettbewerb der Glasbläsergilde entstanden.
Hohle Köpfe von Terry Pratchett
-