Hallo,
ich hab als HTML-Neuling eine Vereins-Webseite übernommen. Auf der wird
ca. 4x im Jahr mal was neues hinzugefügt. So 10-20 Seiten insgesamt.
Bisherige Gestaltung ist so im 90er Jahre Geocities Design ;-) (ich
werde auf keinen Fall drauf verlinken!!)
Ich hab mir vorgestellt das ohne Skripte und aktive Inhalte machen zu
wollen (siehe auch blog.fefe.de -> "Proudly made without PHP, Java,
Perl, MySQL and Postgres")
Vom Layout würde mir sowas gefallen ("Flexbox Example"), das passt sich
automatisch an wenn der Benutzer sein Handy hochkant hält:
https://www.w3schools.com/html/html_layout.asp
Meine Frage: Gibt es eine schöne Möglichkeit, wenn bei mehreren
Webseiten die linke Spalte (London,Paris,Tokyo) und die obere Zeile
("Cities") immer gleich sein soll, und nur der Inhalt ("London is the
capital city of England...") jeweils unterschiedlich ist, dass man die
konstanten Inhalte zentral speichert so dass man sie nur 1x ändern muss
wenn man noch mit dem Layout spielt?
Einen statische-Webseiten-Generator wie Hugo will ich an sich nicht
benutzen weil es erstens overkill wäre und ich zweitens festgestellt
habe dass sowas auch Einarbeitungszeit benötigt.
https://themes.gohugo.io/
HTML per Notepad++ zu schreiben ist mir im Vergleich dazu sogar
sympathisch (wesentlich besser dokumentiert, man findet viel schneller
Beispiele und Hilfe per google, und HTML verschwindet nicht so schnell
so dass das Wissen auch in 20 Jahren noch zu was gut ist.)
Hast du den Webserver in der Hand? Kannst du ihn so konfigurieren, dass er server-side includes benutzen kann? Damit kann man sowas machen. Habe vor einiger Zeit für unsere ebenfalls sehr einfach gestrickten Vereinsseiten mal sowas gemacht. Menü links ist auf'm Handy unpraktisch, frisst zu viel Platz. Daher habe ich das Menü oben, und wenn das gesamte Display zu schmal wird, wird stattdessen ein Menü-Button eingefügt. Ich wollte auch gern ohne Javascript etc. auskommen. Wenn dich das interessiert, kann ich mal versuchen, ein minimales Beispiel dafür zusammenzurödeln.
Strato scheint das zu unterstützen, ich kann es morgen also mal ausprobieren: https://www.strato.de/faq/hosting/so-setzen-sie-server-side-includes-ssi-ein/ Selfhtml schreibt aber: "Die Unterstützung von SSI seitens der Hoster ist rückläufig." https://wiki.selfhtml.org/wiki/Webserver/SSI HTML hat offensichtlich keine schöne oder inhärente Möglichkeit sowas zu erzielen? Wie machen das professionelle Webseiten? Immer per Skript? Wenn ich sowieso eine einzige CSS Datei für alle HTML Seiten anlege, könnte ich die konstante Navigation dann in der CSS Datei unterbringen?
asd schrieb: > HTML hat offensichtlich keine schöne oder inhärente Möglichkeit sowas zu > erzielen? HTML ist eine Seitenbeschreibungssprache. Was du brauchst, bezieht sich jedoch auf den Server. > Wie machen das professionelle Webseiten? Immer per Skript? Keine Ahnung, aber sehr wahrscheinlich. > Wenn ich sowieso eine einzige CSS Datei für alle HTML Seiten anlege, > könnte ich die konstante Navigation dann in der CSS Datei unterbringen? Jein. CSS ist für die Layout-Dinge da, aber nicht für Inhalte. Man braucht also eine Kombination aus beiden. Ich bin da auch alles andere als ein Experte, habe mir das damals angelesen und zusammengekleckert. Javascript-basierte Lösungen gibt es viele, aber ich wollte es gern ohne, und es sollte auch unter Text-Browsern wie lynx oder w3m zumindest benutzbar sein.
Tom schrieb: > https://www.mediaevent.de/html/frameset.html Da steht auch nur drinnen entweder PHP (dann ist das dynamisch erzeugt) oder SSI (die eine eher geringe Unterstützung haben) benutzen soll. Framesets sollte man bei bestem Willen nicht mehr nutzen (die werden auch bei vielen Browsern nicht mehr dargestellt, wenn das Dokument als HTML5 gekennzeichnet wurde). Im Endeffekt wird es daraufhin aus laufen, die Seite dynamisch entweder im Browser (per Javascript) oder serverseitig (mit z.b. PHP) zusammenzubauen oder eben eben mithilfe eines Generatortools, deine Fragmente statisch zu HTML zu konvertieren und das dann auszuliefern.
Wenn du wirklich statische Seiten haben willst (d.h. auf dem Server wird nichts dynamisch eingebaut, auch nicht per SSI) aber auch keinen Generator irgendeiner Form für die Erzeugung dieser statischen Seiten haben willst und ebenso wenig Client Side Scripting (z.B. mit JavaScript) nehmen willst: Dann musst du das eben alles von Hand machen. Die Frage ist halt, wie statisch du die Seiten wirklich haben willst. Wenn die als statische Ressource vom Server ausgeliefert werden sollen (also mit Last-Modified, ETag etc.) so dass der Cleint sie vernünftig cachen kann, dann darfst du serverseitig nich nicht einmal SSI verwenden. Wenn es dir nur darum geht, nicht erst irgendein Framework lernen zu müssen: Selbst mit PHP (Würg) lässt sich die Funktionalität von SSIs, also das einfache Einfügen identischen Inhalts, leicht basteln (und PHP wird nicht so schnell abgekündigt werden ...).
Ich habe auch eine Webseite bei der ich sowas wollte, und habe das mit einem Shellskript gemacht. Die Seiten selbst liegen in einem git-Repo und auf dem Server ist ein Hook, der das Skript immer ausführt wenn sich was ändert. Der Inhalt wird per Platzhalter in das Template, das die Navigation etc. enthält, reinkopiert. Als Inspiration paste ich es hier mal.
1 | #!/bin/sh
|
2 | |
3 | set -e |
4 | |
5 | export PYTHONIOENCODING=utf8 |
6 | python create_translations.py |
7 | |
8 | function create_output() { |
9 | indir=$1 |
10 | outdir=$2 |
11 | lc_code=$3 |
12 | |
13 | mkdir -p $outdir |
14 | |
15 | for page in index software downloads kontakt impressum; do |
16 | echo "Generating $outdir/$page.html ..." |
17 | sed "/CONTENTS/{ |
18 | s/CONTENTS//g
|
19 | r $indir/$page.inc |
20 | }" $indir/page.tpl > $outdir/$page.html |
21 | sed -i "s/menu-link-$page/menu-link-active/g" $outdir/$page.html |
22 | sed -i "s/PAGE_LANGUAGE/$lc_code/" $outdir/$page.html |
23 | done
|
24 | }
|
25 | |
26 | create_output . output/ de
|
27 | create_output translated/en/ output/en/ en |
28 | |
29 | cp -v style.css output/style.css |
30 | cp -v imagebox.js output/imagebox.js |
31 | |
32 | for lang in en; do |
33 | for sharedfile in style.css imagebox.js files images; do |
34 | rm -f output/$lang/$sharedfile |
35 | ln -sv ../$sharedfile output/$lang/$sharedfile |
36 | done
|
37 | done
|
:
Bearbeitet durch User
Auch wenn du es hier explizit ausschließt würde ich dir doch noch einen Blick auf HTML-Generatoren werfen. Der einmalige Aufwand am Anfang wird sehr schnell durch eingesparte Arbeit eingespart. Und wenn mal jemand das Design ändern will ist auch das möglich. Bei Github kann man seine Seite dabei sogar kostenlos hosten und muss sich um nix kümmern: https://pages.github.com/ Die Seiten selber werden dabei in Markdown geschrieben, was für die meisten Menschen deutlich lesbarer als HTML ist.
Ja, eine einfach seite mit Menu, Buttons, Bildern und so ist machbar. Stichworte HTML, CSS. Falls man auch noch etwas liefern moechte benoetigt man eine Datenbank, das waere dann plus php, plus MySql. Plus Datenschutz. Falls es etwas verspieltes hergeben soll kommt noch Javascript hinzu. Fertigpackete, wie Wordpress, Jumlaa, Typo3 wuerd ich nicht empfehlen, da gibt es seltsame Effekte und wegen Sicherheit muss man dran bleiben. Frameworks wuerd ich nicht empfehlen. Die koennen Alles, benoetigen aber auch viel Zeit zur Einarbeitung.
Statisch generieren wird dann wohl die beste Variante sein. Muss ja auch kein gewaltiges Generator-Tool sein. Schätze ca. 10-20 Zeilen Python sollten reichen, um HTML- oder Markdown-Inhalte in ein HTML/CSS-Template einzusetzen.
asd schrieb: > Meine Frage: Gibt es eine schöne Möglichkeit, wenn bei mehreren > Webseiten die linke Spalte (London,Paris,Tokyo) und die obere Zeile > ("Cities") immer gleich sein soll, und nur der Inhalt ("London is the > capital city of England...") jeweils unterschiedlich ist, dass man die > konstanten Inhalte zentral speichert so dass man sie nur 1x ändern muss > wenn man noch mit dem Layout spielt? Nunja, ich weiß nicht, was du für "schön" hältst, aber früher(tm) hat man sowas z.B. mit Frames gelöst. Wobei für den inneren Frame die Wahl besteht, verschiedene Seiten zu liefern oder auch nur eine Seite mit verschiedenen Ankern.
Ist doch alles Bullshit. Eine gammelige Webseite soll durch fleißige Handarbeit aufgepimpt werden. Ja klar, wenn man sonst gar nichts zu tun hat und als der einsame Held auftreten möchte der sich für den Verein aufopfert. Wenn man bei Änderungswünschen durch die Vereinskameraden ein Leidensgesicht ziehen möchte und über die harte Arbeit jammern möchte. Mietet euch bei eurem Provider für ca. 10 Euro / Monat ein gehostetes WordPress CMS. Das kleinste Paket wird reichen. Zu teuer? Einen für WordPress geeigneten Server bekommt man auch schon für zwei oder fünf Euro/Monat. Dann muss man sich WordPress einmalig selbst installieren und leider selber warten. Nimm ein Default-Thema wie Twenty Nineteen, oder, wenn etwas wagemutiger, installiere ein für Vereine angepasstes oder populäres Webseiten-Thema (Listen kann man googeln). Das Setup ist einmal Arbeit, und dann? Dann beschäftigt ihr euch mit den Inhalten und nicht der Mechanik der Seite. Dabei kann man immer noch den Helden geben, der für den Verein diese tolle Webseite organisiert hat und betreibt. Nur mit weniger Arbeit. Man kann auch Benutzer verwalten, statt wie bei nackten Dateien Unbedarfte an die Dateien zu lassen. WordPress ist scheiße? Ja und? Ist es, aber für eine gammelige Vereinsseite mit, keine Ahnung, 10 Visits im Monat ist es völlig OK. WordPress ist unsicher? Ja und? Wenn man WordPress-Hosting kauft ist dass mehr das Problem des Hosters. Die Vereins-Inhalte sind sowieso nicht so wichtig, man braucht kein 24/7 und das Zauberwort heißt allgemein Backups. WordPress generiert Seiten mit JavaScript und dem ganzen modernen Web-Müll? Ja und? Solange man auf der Erzeuger-Seite sitzt und sich nur um die Inhalte und nicht um JavaScript Code kümmern muss kann es einem egal sein. Die 10 Besucher im Monat haben halt Pech gehabt.
:
Bearbeitet durch User
Ja, die Navigation kann man in statische Web-Seiten einbauen. Ich mache das so: - Jeder Seiteninhalt kommt in eine provisorische HTML-Datei, die keine Navigation enthält - Die Struktur der Site wird durch einen Dateibaum gebildet - die endgültige HTML-Datei - inklusive Navigation - wird per XSLT gebildet - XSLT läuft auf dem PC, nicht auf dem Web-Server - Wie die Navigation aussieht und andere "feststehenden" Teile, wird für die ganze Site durch die XSLT-Stylesheetdatei bestimmt Siehe meine Web-Site: http://web222.webclient5.de Bei Interesse könnte ich das genauer dokumentieren und die Skripte veröffentlichen.
asd schrieb: > siehe auch blog.fefe.de -> "Proudly made without PHP, Java, > Perl, MySQL and Postgres" Ich enttäusche dich nur ungern, aber die Seite ist nicht ohne aktive Inhalte: https://blog.fefe.de/faq.html > Ich habe eine Blogsoftware in C gehackt, mit dietlibc, libowfat, unter gatling > laufend und mit einem tinyldap-Backend. asd schrieb: > Ich hab mir vorgestellt das ohne Skripte und aktive Inhalte machen zu > wollen Wozu? asd schrieb: > Wie machen das professionelle Webseiten? Immer per Skript? Natürlich. c-hater schrieb: > Nunja, ich weiß nicht, was du für "schön" hältst, aber früher(tm) hat > man sowas z.B. mit Frames gelöst. Wobei für den inneren Frame die Wahl > besteht, verschiedene Seiten zu liefern oder auch nur eine Seite mit > verschiedenen Ankern. Es hat schon seinen Grund, warum Frames für sowas ausgestorben sind... Hannes J. schrieb: > Mietet euch bei eurem Provider für ca. 10 Euro / Monat ein gehostetes > WordPress CMS. Das kleinste Paket wird reichen. Zu teuer? Einen für > WordPress geeigneten Server bekommt man auch schon für zwei oder fünf > Euro/Monat. Dann muss man sich WordPress einmalig selbst installieren > und leider selber warten. Och nö, doch bitte alles nur kein Wordpress. Es gibt so viele schlange, sichere CMS da draußen. Hannes J. schrieb: > WordPress ist scheiße? > Ja und? Ist es, aber für eine gammelige Vereinsseite mit, keine Ahnung, > 10 Visits im Monat ist es völlig OK. > > WordPress ist unsicher? > Ja und? Wenn man WordPress-Hosting kauft ist dass mehr das Problem des > Hosters. Die Vereins-Inhalte sind sowieso nicht so wichtig, man braucht > kein 24/7 und das Zauberwort heißt allgemein Backups. Achso, wenn aufgrund der latenten Unsicherheit von Wordpress und seiner überbordenden Pluginlandschaft die Seite gekapert wird, und genutzt um Malware zu verbreiten, dann ist das komplett egal? Manche Leute sind einfach asozial...
vn nn schrieb: > Es hat schon seinen Grund, warum Frames für sowas ausgestorben sind... Welchen genau? Ich meine jetzt nicht, warum all die unfähigen Webdesigner das nicht mehr so machen, sondern was der Vorteil für den Anwender ist, es nicht so einfach zu machen...
Thomas R. schrieb: > Siehe meine Web-Site: > http://web222.webclient5.de Auf einem schmalen Bildschirm (Telefon, hochkant) ist das Reservieren einer Spalte links nur für ein bisschen Navigation allerdings Platzverschwendung.
Vielen Dank für die Diskussion. Das hilft mir weiter die verschiedenen Möglichkeiten zu sehen. Und vor allem macht es mich sicherer darin keine offensichtliche und gute Methode übersehen zu haben. Ich werde also mal mit SSI anfangen. Bis dass dann mal vom Hoster gestrichen werden sollte hab ich mich dann schon auf eine andere Methode eingearbeitet. Vermutlich in der Priorität: - sich doch in einen Statisches-HTML-Generator einarbeiten. Hugo o.ä. - das erwähnte XSLT scheint auch so ein Generator für statisches HTML zu sein? https://www.w3schools.com/xml/xsl_intro.asp - PHP: Quick&Dirty, wird aber die nächsten 20 Jahre auch nicht verschwinden. Lohnt also die Mühe sich anzuschauen - oder einen kleinen Generator selber schreiben. - ein richtiges CMS ist für 4 neue Inhalte pro Jahr wirklich mit Kanonen auf Spatzen geschossen - Die alte Seite ist mit Frames. Ich hatte keine eigene Meinung dazu, sondern hab die 99% Meinung des Internet übernommen - Ich will die Seite ohne Skripte schreiben, weil ich es selber hasse einer Seite Skripte erlauben zu müssen nur damit die belämmerte Nav-Leiste geht, und das obwohl es nur statische Links sind. Vielen Dank an alle!
asd schrieb: > - das erwähnte XSLT scheint auch so ein Generator für statisches HTML zu > sein? https://www.w3schools.com/xml/xsl_intro.asp XSL Transform Das macht aus einem XML ein anderes. HTML lässt sich als XML-Dialekt darstellen, wobei XML strikter ist. Beispielsweise akzeptiert jeder Browser in HTML, dass du Tags nicht beendest, ein Absatz hat dann halt nur <p> am Anfang, aber kein </p> am Ende. Wenn du das als XML interpretieren lassen willst, musst du dagegen auch auf formale Korrektheit des HTMLs achten. > - oder einen kleinen Generator selber schreiben. Du kannst auch existierende Präprozessoren benutzen, M4 sollte sich auf jeden Fall eignen, vermutlich bekommt man sogar mit dem C-Präprozessor da was hin. > - Ich will die Seite ohne Skripte schreiben, weil ich es selber hasse > einer Seite Skripte erlauben zu müssen nur damit die belämmerte > Nav-Leiste geht, und das obwohl es nur statische Links sind. +1
asd schrieb: > - Die alte Seite ist mit Frames. Ich hatte keine eigene Meinung dazu, > sondern hab die 99% Meinung des Internet übernommen wenn du die seite schon überarbeiten willst, dann hau die deppaten frames raus. die sind obsolete https://developer.mozilla.org/de/docs/Web/API/HTMLFrameSetElement > - Ich will die Seite ohne Skripte schreiben, weil ich es selber hasse > einer Seite Skripte erlauben zu müssen nur damit die belämmerte > Nav-Leiste geht, und das obwohl es nur statische Links sind. ok, deine einstellung - mir ist noscript und co zu aufwändig. wurscht, meine einstellung. zum thema: wenn du die navigation (evtl auch header und footer) z.b. aus einer eigenen datei mit php per "require" oder "include" einbettest, aber im html kein einziges "script" tag vorkommt, dann hast du: - eine zentrale datei für die navigation - das was du als "ohne scripts" bezeichnest - seiten die "statisch aussehen". ist dem browser (und besucher) eh plunswurscht (anm. komplett egal) ob die "dateien" statisch vorliegen oder durch irgendein server script gerendert sind/wurden - den lernaufwand fast auf 0 reduziert weil du nur einen oder zwei befehle "lernen" musst
Hallo, c-hater schrieb: >> Es hat schon seinen Grund, warum Frames für sowas ausgestorben sind... > > Welchen genau? Ich meine jetzt nicht, warum all die unfähigen > Webdesigner das nicht mehr so machen, sondern was der Vorteil für den > Anwender ist, es nicht so einfach zu machen... ich hatte vor Jahren meine alte Webseite im Backup wiedergefunden und einfach mal auf den (eigentlich fast ungenutzten) Webspace gelegt. Nun liegt sie schon wieder 10 Jahre lang dort... https://www.roehres-home.de/amiga_lebt/index.html Gruß aus Berlin Michael
bei statischen htmls kannst Du das menü in einer externen html auslagern und brauchst es für alle Seiten nur einmalig zu editieren, das menü lässt sich dann per json und nem kleinen javascript einbetten siehe hier : https://www.w3schools.com/howto/howto_html_include.asp wenn DU weg von statischen htmls willst (was das layouten deutlich vereinfacht IMHO) dann schau mal auf smarty.net das ist eine php template engine die recht einfach zu benutzen ist. ein template und der content wird einfach eingebettet.. (statischer content wie header und footer können natürlich auch statisch bleiben) Am ende ist das sehr aufgeräumt und leicht zu warten/ergänzen
c-hater schrieb: > vn nn schrieb: > >> Es hat schon seinen Grund, warum Frames für sowas ausgestorben sind... > > Welchen genau? Ich meine jetzt nicht, warum all die unfähigen > Webdesigner das nicht mehr so machen, sondern was der Vorteil für den > Anwender ist, es nicht so einfach zu machen... Probleme beim setzen von Lesezeichen oder weitergeben von URLs Probleme beim nutzen des "Zurück"-Buttons Probleme beim neu laden der Seite Und zu guter Letzt: deprecated since HTML5 Aber wie immer hältst du alle anderen für unfähig, nur dich selbst nicht.
Oh mein Gott was für ein Gemurkse. Wie oben schon jemand schrieb: Nimm WordPress, dann kannst später du oder irgendein Vereinskjockel der vor Computern Angst hat einfach nur noch Content reinhauen. Das ist heute die ideale Wahl für solche Seiten. Meinetwegen ein anderes CMS, jedenfalls fummelt man sich keine Seiten mehr von Hand zusammen. Ein CMS bringt einfach vieles mit das man heute haben will: Userverwaltung, eben CMS-Funktionalität, zeitgemässe Themes die auch responsive sind. Zu den restlichen Vorschlängen muss man sich ja nur noch an die Birne fassen: SSI: Das war mal ein vorübergehender Hack, das Zeug ist sowas von tot. XSLT: Thema verfehlt Jetzt kommt bestimmt noch einer angezuckelt und empfiehlt JBoss.
Sklavenvermittler schrieb: > Ein CMS bringt einfach vieles mit das man heute haben will: > Userverwaltung, Wofür braucht man das für eine Handvoll weitgehend statischer Inhalte? > eben CMS-Funktionalität, zeitgemässe Themes die auch > responsive sind. Die meisten Themen, die bei den freien CMSen so rumlungern, sind leider nicht einmal das. Ein CMS ist gut, wenn da wirklich auch immer mal wieder was passiert, und wenn diejenigen, die da was einstellen sollen/wollen, kein HTML können. Es bringt aber auch Einarbeitungsaufwand mit sich. > SSI: Das war mal ein vorübergehender Hack, das Zeug ist sowas von tot. Der führende Indianer unterstützt es, Nginx auch. Solange man auf dem Server drauf zurückgreifen kann – den Client interessiert das am Ende nicht weiter, ihm entsteht daraus kein Nachteil.
Ursel schrieb: > Statisch generieren wird dann wohl die beste Variante sein. Muss ja auch > kein gewaltiges Generator-Tool sein. Schätze ca. 10-20 Zeilen Python > sollten reichen, um HTML- oder Markdown-Inhalte in ein HTML/CSS-Template > einzusetzen. Aus Spaß an der Freude und weil ich es wissen wollte, habe ich mal etwas mit Python3 geschrieben, das etwas mehr kann als simple Variablenersetzungen. Okay, es sind 42 Zeilen geworden, dafür funktioniert das Programm rekursiv auf Verzeichnisse, nutzt die Templateengine Jinja2 mit Schleifen, Includes und Template-Vererbung, und kann Datenstrukturen aus JSON-Dateien lesen und einsetzen. Vielleicht kann ja jemand sowas brauchen, have fun. ;-)
Sklavenvermittler schrieb: > Wie oben schon jemand schrieb: Nimm WordPress, dann kannst später du > oder irgendein Vereinskjockel der vor Computern Angst hat einfach nur > noch Content reinhauen. Das ist heute die ideale Wahl für solche Seiten. > Meinetwegen ein anderes CMS, jedenfalls fummelt man sich keine Seiten > mehr von Hand zusammen. Nochmal: bitte jedes CMS, nur nicht das latent unsichere und völlig aufgeblasene Wordpress. Ja, ich hab auch schon Vereinsseiten auf Wordpress aufgezogen. Und dann bitter bereut. Mein Favorit: einer der Hoster legt automatisiert auf den Wordpress-Adminbereich (/wp-admin/*) eine zusätzliche Authentifizierung über eine .htaccess, weil sie ständig Support-Calls (zwecks Backup-Wiederherstellung) und Abusemails hatten wenn wieder mal aufgrund eines unsicheren Wordpress-Plugins die Seite eines Kunden gekapert wurde.
WordPress ist völliger Kernschrott, und wer das empfiehlt, hat entweder von Tuten und Blasen keine Ahnung, oder er ist "Webentwiggler" und will seinen Kunden einen Wartungsvertrag aufschwatzen. Schlimmstenfalls auch noch mit Bootstrap und jQuery versaut. Webseiten, die statisch sinnvoll möglich sind, macht man heute zunehmend auch wieder statisch, nämlich mit einem der unzähligen Generatoren. Bessere Performance, bessere Sicherheit, kein Zerbrechen bei allfälligen Updates. Und responsive: Eine HTML-Seite ist responsive, ganz von selber, das war schon immer so. Das wird wenn überhaupt erst durch laienhaften Einsatz von CSS wieder vergurkt.
Nop schrieb: > Eine HTML-Seite ist responsive, ganz von selber, das war schon immer so. Das HTML selbst ist es, die Navigation dagegen nicht, falls man irgendwas wie ein Menü mit dabei haben möchte (und nicht nur am Fuß einen Link zum Impressum und vielleicht der Hauptseite – das geht auch einfach so).
Jörg W. schrieb: > Das HTML selbst ist es, die Navigation dagegen nicht Ist sie, weil die Navigation im Markup lediglich eine ul ist, in der li stecken, die wiederum anchors enthalten. Bis auf das li für die aktuelle Seite natürlich, das statt des anchors nur den Seitentitel enthält. Die ul bekommt eine Klasse oder ID, mehr nicht, und alles weitere geht ins CSS.
Nop schrieb: > Ist sie, weil die Navigation im Markup lediglich eine ul ist, in der li > stecken, die wiederum anchors enthalten. Wenn man diese immer einblendet, nimmt sie auf einem kleinen Bildschirm ziemlich viel Platz weg. Auf einem großen Bildschirm (die Dinger sind ja vor allem in die Breite gewachsen in den letzten Jahren) wiederum ist es sinnvoll, die Einträge nebeneinander anzuzeigen statt untereinander. > alles weitere geht ins CSS Dass man das rein mit CSS organisieren kann, hat ja keiner bestritten.
:
Bearbeitet durch Moderator
Jörg W. schrieb: > Auf einem großen Bildschirm (die Dinger sind ja > vor allem in die Breite gewachsen in den letzten Jahren) wiederum ist es > sinnvoll, die Einträge nebeneinander anzuzeigen statt untereinander. Das Layout ist nicht Aufgabe des Markups, sondern von CSS. Ohne CSS werden die per Default zwar untereinander dargestellt, sind aber responsive. DPA schrieb: > <table> - Reines HTML, nicht Responsive. Tabellen mißbraucht man nicht fürs Layout.
Sklavenvermittler schrieb: > Oh mein Gott was für ein Gemurkse. > > Wie oben schon jemand schrieb: Nimm WordPress, ..... > Das ist heute die ideale Wahl für solche Seiten. Das ist mal echtes Gemurkse! Wordpress joomla und Co sind die schlechteste Idee die man haben kann. Nach den WYSIWYG Editoren diverser Webhostanbieter Man schleppt 99.5% Overhead mit den man nie brauchen wird. Nicht nur auf dem Server sondern vor allem innerhalb der html. Will man wissen ob eine Internetseite "schlecht gemacht ist" ist es das einfachste zu gucken ob da WP und Co laufen ohne Grund. eierlegende Wollmilchsäue sind der beste Indikator für unfähige Webdesigner. ProTipp: hat mein keine Userdatenbank, können keine userdaten geklaut werden!
Nop schrieb: > Tabellen mißbraucht man nicht fürs Layout. das stimmt so pauschal auch nicht... während divs sich in den letzten Jahren immer mehr durchsetzen, sind tabled-layouts fast ebenso effizient. Sie sind zB auch ohne externes css responsive wenn ich mich recht entsinne waren zB alle std vBulletin templates bis v4 hauptsächlich table-layouts Generell sind Forenbeträge als tabelle leichter zu handhaben als per nested divs.
sid schrieb: > Nop schrieb: >> Tabellen mißbraucht man nicht fürs Layout. > > das stimmt so pauschal auch nicht... > während divs sich in den letzten Jahren immer mehr durchsetzen, > sind tabled-layouts fast ebenso effizient. Das ist schon seit 20 Jahren "bad practice", u.a. weil man damit kein barrierefreies Webdesign schafft. Unwesentlich? Domino's hat gerade in den USA vor Gericht eine Klatsche kassiert, weil deren Webseite nicht barrierefrei ist. Tabellenbasiertes Layout ist sowas von 90er. Wer heute noch damit kommt, zeigt nur, daß er die letzten Jahrzehnte verschlafen hat. Und wer das als Webdesigner heute noch macht, soll lieber zu McD Burger braten gehen.
sid schrieb: > Nop schrieb: >> Tabellen mißbraucht man nicht fürs Layout. > > das stimmt so pauschal auch nicht... Doch. Denn Tabellen sind, wer hätte das gedacht, für tabellarische Daten gedacht. Ich kann natürlich auch einen Schraubenschlüssel zum einschlagen eines Nagels verwenden, das macht es aber nicht richtig.
in der C't wurden im laufe der Jahre mal ein oder zwei Frameworks für statische Webseiten vorgestellt. Quasi offline-CMS. Kann auch sein, dass sie selbst mal dafür was entwickelt hatten. was ich auf anhieb gefunden habe: https://www.heise.de/select/ct/2016/12/1465125783782179 https://www.heise.de/ct/ausgabe/2013-25-Jekyll-generiert-Blogs-und-andere-Webseiten-2310740.html https://www.heise.de/ct/ausgabe/2013-9-Octopress-erzeugt-und-veroeffentlicht-Blogs-mit-statischem-HTML-2324231.html hier ist auch noch ein Artikel der ein paar Sachen Offline-CMS aufführt: https://mherbst.de/de/blog-it/renaissance-der-statischen-websites/ vom kurzen drüberfliegen fand ich Hugo am attraktivsten.
Nop schrieb: > Das ist schon seit 20 Jahren "bad practice", u.a. weil man damit kein > barrierefreies Webdesign schafft. Unwesentlich? Domino's hat gerade in > den USA vor Gericht eine Klatsche kassiert, weil deren Webseite nicht > barrierefrei ist. > > Tabellenbasiertes Layout ist sowas von 90er. Wer heute noch damit kommt, > zeigt nur, daß er die letzten Jahrzehnte verschlafen hat. Und wer das > als Webdesigner heute noch macht, soll lieber zu McD Burger braten > gehen. Also barrierefreiheit hat NIX mit tabellen zu tun! Aber schon dass Du keine Ahnung hast wovon Du sprichst und es mit genau dieser Aussage auch zugibst:D vn nn schrieb: > Doch. Denn Tabellen sind, wer hätte das gedacht, für tabellarische Daten > gedacht. Ach wisster, schaut doch einfach mal in diesen Quelltext.. und dann schau mal in den Quelltext jeden anderen Forums das Du finden kannst... schaut Euch die layouts pauschal aller Internetseiten die Ihr in den nächsten 48h besucht an und zählt einfach mal die table tags bei ebay, amazon, in internetforen, nachrichtenseiten was auch immer schaut euch auch die divs oder vielmehr deren rendering javascripte bei google an... richtig die rendern es mit table markings (damit es sich wie eine tabelle verhält) dann sprechen wir nochmal.
sid schrieb: > Also barrierefreiheit hat NIX mit tabellen zu tun! Bullshit. Natürlich hat es das, wenn man Tabellen für nicht-tabellarische Daten mißbraucht. Screenreader arbeiten auf der Seitenstruktur. > Aber schon dass Du keine Ahnung hast wovon Du sprichst > und es mit genau dieser Aussage auch zugibst:D Dunning-Kruger bei Dir. Hast Du überhaupt schonmal Seiten mit Screenreadern getestet? Oder weißt Du auch nur, was Screenreader sind?!
Naja das hat eher was mit unsauberem html zu tun https://www.w3.org/WAI/tutorials/tables/ nicht mit den Tabellen selbst... ich kann Dir auch jede div vor nem screenreader 'verstecken' wenn Du magst. oder n pre tag, ne headline und im Grunde exakt genau alles. screenreader haben ja generell gerne Probleme mit interaktiven javascripten zB deswegen ist ja javascript nicht schlecht. Aber wie gesagt, quatsch Du nur weiter Blödsinn, das zeigt nur wie wenig Du davon verstehst ;)
sid schrieb: > Naja das hat eher was mit unsauberem html zu tun > https://www.w3.org/WAI/tutorials/tables/ > nicht mit den Tabellen selbst... Oje, die selbsternannten Experten sind wieder unterwegs. Tabellen sind auch in barrierefreien Designs erlaubt, aber eben nur für Daten die tabellarisch darstellbar sind. Layout mit Tabellen oder Framesets ist sowas von 90er und heute ein absolutes NoGo!! => https://www.barrierefreies-webdesign.de/knowhow/layout-tabellen/ Der TO wollte eine Webseite ohne Scripte und hat sich sich schon mit dem Flexbox Prinzip auseinandergesetzt und ihr kommt mit Wordpress, Python und solchen Zeug um die Ecke. Hat sich einer den Eröffnungspost überhaupt durchgelesen? Für eine statischen Webseite reichen HTML und CSS... Punkt. Wer diese Basics nicht beherrscht sollte aufhören Webseiten zu gestalten.
scherg schrieb: > Python Zum Generieren der finalen statischen Webseite, nicht etwa irgendwie aktiv auf dem Server. Hat schon Sinn: man kann damit genau das von ihm gewünschte (Einbindung von in allen Seiten wiederkehrenden Inhalten) erreichen. Letztlich macht SSI ungefähr das gleiche, nur zur Laufzeit auf dem Server.
scherg schrieb: > Für eine statischen Webseite reichen HTML und CSS... Punkt. Wer diese > Basics nicht beherrscht sollte aufhören Webseiten zu gestalten. Ja dann sag doch mal an wie ich damit ein Menu mit 12 Einträgen mache ohne den dafür nötigen Code auf jede Unterseite zu copy-pasten. Darum geht es ja hier mehr oder weniger.
Sven B. schrieb: > scherg schrieb: > Für eine statischen Webseite reichen HTML und CSS... Punkt. Wer diese > Basics nicht beherrscht sollte aufhören Webseiten zu gestalten. > > Ja dann sag doch mal an wie ich damit ein Menu mit 12 Einträgen mache > ohne den dafür nötigen Code auf jede Unterseite zu copy-pasten. Darum > geht es ja hier mehr oder weniger. Benutze ein offline cms und generiere mit diesen die statischen Webseiten.
Sven B. schrieb: > Ja dann sag doch mal an wie ich damit ein Menu mit 12 Einträgen mache > ohne den dafür nötigen Code auf jede Unterseite zu copy-pasten. Darum > geht es ja hier mehr oder weniger. Da muss ich dir durchaus zustimmen, gänzlich scriptfrei wird es da wohl nicht gehen. Eine durchaus gängige Lösung wäre dann ein Ein-Seiten-Layout, positioniert das Menu in den Header und verlinkt auf Anker in der Seite => HTML, CSS only. Ob das eine Variante wäre, hängt vom Inhalt ab. Allerdings sehe ich bei max. 20 Seiten ein Copy-Paste-Menu durchaus beherrschbar... wenn man sich partout allem Code verweigern will.
Jörg W. schrieb: > scherg schrieb: >> Python > > Zum Generieren der finalen statischen Webseite, nicht etwa irgendwie > aktiv auf dem Server. > > Hat schon Sinn: man kann damit genau das von ihm gewünschte (Einbindung > von in allen Seiten wiederkehrenden Inhalten) erreichen. Letztlich macht > SSI ungefähr das gleiche, nur zur Laufzeit auf dem Server. Das habe ich schon verstanden. Allerdings sehe ich dann die Lernkurve ähnlich jeder anderen Scriptsprache oder dem Hugo Webgenerator. Ich habe den TO so interpretiert, dass er dies genau ausschließen wollte.
scherg schrieb: > Ich habe den TO so interpretiert, dass er dies genau ausschließen > wollte. Er meldet sich selbst nicht mehr groß zu Wort. ;-) Ich trau ihm durchaus zu, ein bisschen Scripterei mal mit zu machen. Wobei, wenn sein Hoster SSI unterstützt, warum sollte er das nicht dann auch benutzen? Ist ja nahezu dasselbe, nur dass man selbst keinen Finger weiter rühren muss außer halt die paar SSI-Tags passend einzubauen. Kann sein, dass er das inzwischen als Weg für sich bereits angenommen hat: Beitrag "Re: Navigation in statische HTML Seiten einbauen. Wie?"
Jörg W. schrieb: > Er meldet sich selbst nicht mehr groß zu Wort. ;-) Recht du hast, Thread closed ;-)
Im grunde braucht der TO doch gar nichts kompliziertes: (PHP, alles ungetestet) renderhtml.php
1 | <?php
|
2 | readfile(__DIR__ . '/header.m.html'); |
3 | readfile(__DIR__ . $_SERVER['PATH_INFO'] . '.m.html'); |
4 | readfile(__DIR__ . '/footer.m.html'); |
.htaccess
1 | AcceptPathInfo On |
2 | HeaderName /header.m.html |
3 | ReadmeName /footer.m.html |
4 | IndexStyleSheet /css/style.css |
5 | DirectoryIndex index.m.html index.html index.php |
6 | |
7 | RewriteEngine On |
8 | RewriteBase / |
9 | |
10 | RewriteRule ^renderhtml\.php - [L] |
11 | |
12 | RewriteCond %{REQUEST_FILENAME}.m.html -f
|
13 | RewriteRule .* renderhtml.php/$0 [L,QSA] |
14 | |
15 | RewriteBase / |
16 | RewriteCond %{REQUEST_FILENAME} -f
|
17 | RewriteRule ^(.*).m.html$ renderhtml.php/$1 [L,QSA] |
header.m.html
1 | <!doctype html>
|
2 | <html>
|
3 | <head>
|
4 | <title>test</title> |
5 | <link href ="/css/style.css" rel="stylesheet" type="text/css" /> |
6 | </head>
|
7 | <body>
|
8 | <header>
|
9 | HEADER STUFF |
10 | <nav>MENU</nav> |
11 | </header>
|
12 | <main>
|
footer.h
1 | </main> |
2 | <footer> |
3 | FOOTER STUFF |
4 | </footer> |
5 | </body> |
6 | </html> |
index.m.html
1 | <h1>Hello World!</h1> |
test.m.html
1 | <h1>Test!</h1> |
Aufruf: http://<seine server addresse>/ und http://<seine server addresse>/test
DPA schrieb: > nichts kompliziertes: (PHP Genau das wollte er aber eben nicht. (Kann ich durchaus verstehen. Die hatten in der Vergangenheit so viele Sicherheitsprobleme, dass ich darum auch den größtmöglichen Bogen mache, den ich machen kann.)
Man könnte stat dem php 4zeiler auch nen renderhtml.sh, also cgi machen, ist sogar kürzer: (ungetestet)
1 | #!/bin/sh
|
2 | dir="$(dirname "$0")" |
3 | cat "$dir/header.m.html" "$dir/$PATH_INFO" "$dir/footer.m.html" |
DPA schrieb: > Man könnte stat dem php 4zeiler auch nen renderhtml.sh, also cgi machen, > ist sogar kürzer: (ungetestet) ich wette, man könnte dafür auch den C-Präprozessor benutzen.
Hatte ich auch schon mal vorgeschlagen. ;-)
Tja eine Frage 1000 richtige Antworten. Ich glaube der ist jetzt genauso schlau wie zuvor.
Vlad T. schrieb: > DPA schrieb: >> Man könnte stat dem php 4zeiler auch nen renderhtml.sh, also cgi machen, >> ist sogar kürzer: (ungetestet) > > ich wette, man könnte dafür auch den C-Präprozessor benutzen. Müsste glaub ich so gehen: (ungetestet)
1 | #!/usr/bin/cpp -P
|
2 | #include <header.m.html> |
3 | #include "main.m.html" |
4 | #include <footer.m.html> |
header.m.html und footer.m.html müsste man dann aber nach /usr/local/include packen, zumindest uter Linux ist nur ein shebang argument möglich, darum ist hier -I nicht Anwendbar. Und das #! produziert noch nen Fehler, wenn cpp es interpretieren will, ich hoffe das geht ins logfile und nicht auf die Seite...
Beitrag #6107046 wurde vom Autor gelöscht.
scherg schrieb: > Layout mit Tabellen oder > Framesets ist sowas von 90er und heute ein absolutes NoGo!! Du befindest dich auf einer Seite mit Tabellen im Layout (für das sogenannte postbit) "sowas von 90er" sagen übrigens nur Dummschwätz-Millenials, die die Neunziger nur vom hörensagen kennen ;) Und das mein ich als Tipp, daß Du Dich in der realen Welt damit nicht zum Affen machst ;) scherg schrieb: > Der TO wollte eine Webseite ohne Scripte und hat sich sich schon mit dem > Flexbox Prinzip auseinandergesetzt und ihr kommt mit Wordpress, Python > und solchen Zeug um die Ecke. Hat sich einer den Eröffnungspost > überhaupt durchgelesen? Ich ja, Du scheinbar nciht, sonst würdest Du mir nicht mit WP und Co kommen, sondern hättest meine Abneigung gegen aufgeblasene weitestgehend nutzlose CMS weiter oben schon erkannt. scherg schrieb: > Für eine statischen Webseite reichen HTML und CSS... Punkt. Wer diese > Basics nicht beherrscht sollte aufhören Webseiten zu gestalten. Korrekt! erschreckenderweise braucht es nichtmal css.. man kann auch den style direkt ins tag schreiben wenn man tippintensiv coden will ;) Dennoch macht das ein oder andere script sinn, insbesondere wenn man sich das copy und paste sparen möchte bei Änderung. wie oben gesagt kann man so zB menüs aus einer externen html laden... und während man bei PHP in der Tat in viele Fallen tappen kann ist das selbst bei semi-statischen Internetseiten unfassbar nützlich. man kann sich innerhalb von 20 minuten ein eigenes rudimentäres templatesystem basteln, was als minimal CMS fungiert. Ein Order mit Textdateien deren Dateiname im Menü angezeigt wird und deren Inhalt in ein vorgefertigtes template geschrieben wird und schon ist man fertig.. 4min mehr und die textdatei kann html mit bildern beinhalten 10min mehr und man hat eine automatische Bildergalerie für nen anderen Ordner/Unterordner... und wenn man die Order schreibschützt und den Lesezugriff ausserhalb dieser Ordner verhindert muss man sich um die Sicherheit auch nur noch ganz wenige Gedanken machen. bei themeforest oder so n schönes template gekauft oder flux selbst eins gebastelt (natürlich 100% frames, inlineframes und tabellen damit der Scherge weint ;)) kurz angepasst und schon ist man fertig... 100% portabel und je nach template auch barrierefrei und responsive für Kleingeräte. PS wer Chrome/Chromium für das mass aller Dinge hält, der ist ebenso dämlich wie derjenige der meint er müsse für sein singlepagelayout Wordpress bemühen.
Ich werfe mal PPWizard in die Runde. Die Seite sieht aus wie vor 20 Jahren aber das Tool ist aktuell. https://dennisbareis.com/ppwizard.htm
sid schrieb: > scherg schrieb: > "sowas von 90er" sagen übrigens nur Dummschwätz-Millenials, die die > Neunziger nur vom hörensagen kennen ;) Ich musste deinen Text mehrfach lesen, um deinen "Gehirnfasching" nachvollziehen zu können. Meine erste Webseite habe ich in den späten 90er erstellt, damals noch mit Tabellen als Layout. Inzwischen habe ich dazugelernt, nur soviel dazu.
sid schrieb: > Du befindest dich auf einer Seite mit Tabellen im Layout Und? Daß diese Seite in der Hinsicht schlecht gemacht ist, beweist gar nichts. Außer daß es immer noch Leute git, die sich nach dem presentational HTML 3 der 90er zurücksehnen, weil sie HTML 4 schon nicht mehr kapiert haben. > Und das mein ich als Tipp, daß Du Dich in der realen Welt damit nicht > zum Affen machst ;) Du machst Dich immer mehr zum Affen, weil offensichtlich ist, daß Du HTML/CSS schon von der Grundidee her nicht begriffen hast.
Nop schrieb: >> … daß Du Dich in der realen Welt damit nicht >> zum Affen machst ;) > > Du machst Dich immer mehr zum Affen Könntet ihr jetzt bitte wieder zur Sachlichkeit zurück finden? Die gegenseitigen Anschuldigungen helfen keinem, dem TE schon gar nicht.
> Frameset
Für eine Intranetseite (für die Jüngeren: das ist ein Webserver, der nur
intern erreichbar ist) benutze ich seit fast 20 Jahren Framesets. Und es
gab in dieser ganzen Zeit mit diversen Browsern in diversen Generationen
niemals irgendein Problem.
Allerdings muß man damit leben können, daß die Seiten very oldschool
aussehen und in verschiedenen Browser auch unterschiedlich dargestellt
werden. Für Techniker und Leute, die am Inhalt interessiert sind, ist
das okay, aber für Designer der absolute Horror.
PS: Die Seiten enthalten aber ein Script, das beim Laden des Hauptframes
das zugehörige Navigationsmenü aus dem Verzeichnis liest.
svensson schrieb: > Allerdings muß man damit leben können, daß ... Bookmarks nicht vernünftig funktionieren, und der Back-Button des Browsers auch nicht. Letzteres ist besonders auf Smartphones ärgerlich. Und dann sind da auch noch Screenreader. Deswegen verwendet man heute keine Framesets mehr wie vor 20 Jahren, und deswegen sind Framesets in HTML 5 entfallen.
Nop schrieb: > Und dann sind da auch noch Screenreader. Das ist vermutlich für ein Intranet ein überschaubares oder nicht existentes Problem. Hängt natürlich von der Größe der Organisation ab.
svensson schrieb: > PS: Die Seiten enthalten aber ein Script, das beim Laden des Hauptframes > das zugehörige Navigationsmenü aus dem Verzeichnis liest. ... ach ja, und eine Navigation, die auf Scripting angewiesen ist, ist ohnehin ein Fehldesign, insoweit hier von clientseitigem JS die Rede ist und nicht von serverseitigem PHP. Obwohl, bei einem lebenden Fossil von vor 20 Jahren wohl eher CGI mit Perl oder SSI.
Nop schrieb: > svensson schrieb: > >> Allerdings muß man damit leben können, daß > > ... Bookmarks nicht vernünftig funktionieren, Einfach mit JS zu lösen, mit den history modifikationsfunktionen. history.pushState/history.replaceState, und schon hat man ne neue url ohne haupseitenreload: https://developer.mozilla.org/en-US/docs/Web/API/History/pushState > und der Back-Button des Browsers auch nicht. Ich hab das zwar nur mit iframes ausprobiert, aber dort wird bei einem URL-Wechsel ein neues history objekt angelegt, und der zurück knopf geht. Wenn man aber selbst die URL anpasst, ist das eher kontraproduktiv, weil man dann 2 Historyeinträge hat. Kann man aber umgehen, indem man in JS ein neues Frame erstellt, url setzt, alte frame ersetzt.
DPA schrieb: > Einfach mit JS zu lösen Eine Navigation, die auf Client-JS angewiesen ist, ist ein Fehldesign, weil JS die Aufgabe von HTML übernähme. Zum Navigieren gibt's nämlich seit Anbeginn schon die anchor-Tags.
Die Navigation würde in dem fall natürlich auch ohne/deaktiviertem JS weiterhin funktionieren. Man braucht es ja nur, um die URL up-to-date und damit Bookmarkbar zu halten.
DPA schrieb: > Man braucht es ja nur, um die URL up-to-date > und damit Bookmarkbar zu halten. Das ist Teil der Navigation und geht ganz ohne Scripting, wenn man einfach mal sauberes HTML schreibt. JS, bloß um Funktionalität zu replizieren, die der Browser bereits automatisch kann, ist ein Antipattern. Neben HTML-Reproduktion sieht man übrigens sowas Ähnliches oftmals mit CSS, wo Leute Animationen und hover-Effekte allen Ernstes mit JS bewerkstelligen.
DPA schrieb: > Einfach mit JS zu lösen, mit den history modifikationsfunktionen. > history.pushState/history.replaceState, und schon hat man ne neue url > ohne haupseitenreload: > https://developer.mozilla.org/en-US/docs/Web/API/History/pushState Wenn man schon JS benutzt kann man gleich einfach die divs mit dem inhalt austauschen, dann braucht man auch kein framesets mehr. DPA schrieb: > ch hab das zwar nur mit iframes ausprobiert, aber dort wird bei einem > URL-Wechsel ein neues history objekt angelegt, und der zurück knopf geht <iframe> =/= <framesets> bzw. <frame>. Iframes sind absolut HTML5 konform. framesets sind aus HTML5 entfernt. Man könnte zwar framesets mit iFrames emulieren und so die Probleme damit fixen, aber dann kann man normalerweise direkt die DOM mit JS manipulieren (außer natürlich man will content von fremden Servern einbinden, aber das ist bei Navigationsleisten normalerweise nicht der Fall)
Ich sag ja nicht, dass man (i)frames immer verwenden sollte, aber für gewisse Anwendungen ist es einfach speziell gut geeignet, nein sogar kriminell, diese nicht zu verwenden. Max M. schrieb: > Wenn man schon JS benutzt kann man gleich einfach die divs mit dem > inhalt austauschen, dann braucht man auch kein framesets mehr. (i)frames haben einige Vorteile gegenüber dem direkten Einfügen: 1) Es zeigt eine ganze, unabhängige Seite an. Das muss nichteinmal HTML sein. Und gerade bei HTML muss man sich dan keine sorgen machen, dass nachgeladenes CSS die ganze Seite durcheinanderbringt. Es gäbe da zwar noch Shadow DOM (https://developer.mozilla.org/en-US/docs/Web/Web_Components/Using_shadow_DOM), aber da gab es in der Vergangenheit schon ein paar gröbere änderungen, nud fast keiner scheint es zu nutzen, ist also nicht Zukunftssicher, und es hat keine reine HTML Entsprechung für statische Versionen solch einer Seite. 2) Sandboxing. All die Seiten, die ADs, Maps und co. direkt einbinden (eigentlich alle, selbs diese hier), sind doch Kriminell gefährlich. Mit ner iframe könnte man skripte, zugriffe auf dinge auf der Seite, etc. verhindern. Mit srcdoc oder data urls müsste man nichteinmal irgendwas nachladen, und trotzdem binden die Seitenbetreiber einfach so alle mögliche potentielle Malware ein... 3) Der Inhalt kann ohne JS neu geladen werden, ohne den rest der Seite zu zerstören. Ich hab mal so ein Reportgenerierungstool geschrieben, welches das nutzt. Ne form, submit button mit formtarget (https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/submit#formtarget) auf die iframe fürs preview, und ein anderes target fürs den speichern knopf. So kann man die parameter weiter Anpassen, wärend das Preview lädt, ohne JS zu benötigen. Die Reports brauchen ne weile zum generieren. (das ist auch wo ich dann das JS für die History/URL anpassung genutzt habe.)
> Smartphones, Screenreader Gibt es weder noch. Es gab früher einmal einen WAP-Teil, der wegen der ganzen Inkompatibilitäten der Handys extrem nervig war, welcher aber deaktiviert wurde. Z.B. Telefonlisten aller Mitarbeiter, deren Nummern einfach vom Handy übernommen werden konnten -> heute würde sich jeder Datenschützer darüber aufregen. :) > lebenden Fossil von vor 20 Jahren wohl eher CGI mit Perl oder SSI Ich muß doch sehr bitten, meine schöne Anwendung als Fossil zu bezeichnen. ;-)) Der stammt noch aus der Zeit von SuSE 9, wo es zwischen Webseiten und Datenbanken keine einfachen Verbindungen gab. Der dynamische Teil ist aber tatsächlich in Perl programmiert (aber ohne Datenbank). Inzwischen ist das natürlich modernisiert mit Apache 2 und 64-Bit, läuft aber ohne jegliche Anpassungen. Die Navigation funktioniert über JS, das direkt in den Code der Seite eingebettet ist. Funktioniert meistens doch, aber wofür brauche ich den Back-Butten, wenn es links ein Menü gibt? >HTML5 Ist noch HTML4 und ohne CSS.
Jörg W. schrieb: > vermutlich bekommt man sogar mit dem C-Präprozessor > da was hin. Geht: https://accu.org/index.php/journals/1926 Wenn man das mit etwas define/ifdef im inkludierten Menü macht, dann kann man auch problemlos den Menü-Eintrag für die "gegenwärtige" Seite inaktiv machen. Schließlich soll eine Seite nie auf sich selbst verlinken.
svensson schrieb: >>HTML5 > > Ist noch HTML4 und ohne CSS. Also die Tags video, audio und picture waren schon ein grosser Fortschritt, auch ganz ohne die CSS und JS neuerungen.
DPA schrieb: > Also die Tags video, audio und picture waren schon ein grosser > Fortschritt, auch ganz ohne die CSS und JS neuerungen. Ja vor allem bei picture, wo man endlich webp verwenden kann, und Legacy-Browser wie IE und Safari trotzdem mit JPG versorgt werden können. Und hi-res Bilder für hochauflösende Displays, sieht echt scharf aus. Ansonsten aber auch die strukturellen Tags wie header, footer, main und nav. Mit FF+NVDA kann man damit tatsächlich sinnvoll nach Landmarks navigieren.
sid schrieb: > scherg schrieb: >> Layout mit Tabellen oder >> Framesets ist sowas von 90er und heute ein absolutes NoGo!! > Du befindest dich auf einer Seite mit Tabellen im Layout > (für das sogenannte postbit) Schön. Dass sie auf dieser Seite verwendet werden, sagt nun was genau aus? sid schrieb: > "sowas von 90er" sagen übrigens nur Dummschwätz-Millenials, die die > Neunziger nur vom hörensagen kennen ;) Als Tipp, "damit du dich in der realen Welt nicht zum Affen machst" (wie du sagen würdest: "bezeichnet die Bevölkerungskohorte bzw. Generation, die im Zeitraum der frühen 1980er bis zu den späten 1990er Jahren geboren wurde" Die kennen die 90er also durchaus noch. sid schrieb: > scherg schrieb: >> Der TO wollte eine Webseite ohne Scripte und hat sich sich schon mit dem >> Flexbox Prinzip auseinandergesetzt und ihr kommt mit Wordpress, Python >> und solchen Zeug um die Ecke. Hat sich einer den Eröffnungspost >> überhaupt durchgelesen? > > Ich ja, Du scheinbar nciht, sonst würdest Du mir nicht mit WP und Co > kommen, sondern hättest meine Abneigung gegen aufgeblasene weitestgehend > nutzlose CMS weiter oben schon erkannt. Du zitierst ein Posting von "scherg" in dem er sich gegen Wordpress ausspricht, und unterstellst ihm, Wordpress zu empfehlen? Bist du ein Satireprojekt? Das kannst du doch gar nicht ernstnehmen? Andererseits, ausdenken kann sich sowas auch keiner... DPA schrieb: > Einfach mit JS zu lösen, mit den history modifikationsfunktionen. > history.pushState/history.replaceState, und schon hat man ne neue url > ohne haupseitenreload: > https://developer.mozilla.org/en-US/docs/Web/API/History/pushState Man kann natürlich kaputtes HTML versuchen über JS zu fixen. Man kann sich auch von hinten durch die Brust ins Auge schießen. Zu empfehlen ist es halt nicht.
Drupal, Wordpress, Contao (was der Hoster halt so anbietet oder installieren lässt), oder auch Jimdo. Auch wenn 10-20 Seiten nach nicht viel klingt, muß man das doch heutzutage nicht mehr von Hand zusammenklöppeln. Broweserabhängigkeiten, Darstellung für Mobilgeräte, ..., gibts da alles ohne Aufwand nebenbei dazu. Oliver
:
Bearbeitet durch User
Oliver S. schrieb: > Drupal, Wordpress, Contao (was der Hoster halt so anbietet oder > installieren lässt), oder auch Jimdo. So ein Müll kommt dabei heraus, wenn man sich den Thread nicht durchliest, sondern einfach nur was reinbricht.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.