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
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.
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.
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.
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?"
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.)
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.
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...
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.
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
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 abschalten