HTML/CSS Webdesign zukunftssicheres Programmieren

M

McMoneysack91

Gast
Liebe Freunde,

vor nicht all zu langer Zeit lernte ich als Hobby HTML, CSS und etwas PHP. Vermutlich wird demnächst auch ein wenig JavaScript dazukommen. Ich lerne einfach quasi on-the-go, je nachdem was für mein Projekt gerade benötigt wird.

Mit diesen Basic-Tools habe ich eine Website geschrieben und tobe mich mit möglichst vielen Funktionen an dieser aus. Als ich anfing, war HTML5 der Standard. Gelernt habe ich auf diversen Seiten, hauptsächlich aber w3 Schools.

Insbesondere hier wurde deutlich darauf hingewiesen, sich an geltende Standards zu halten. Zwar seien moderne Browser mit allerlei Compilern und sich dazudenkenden Elementen ausgestattet, aber hier läge auch die Gefahr, dass Programmierer sich darauf verlassen und schlampig arbeiten. Okay, einleuchtend. Ich überprüfe meinen Quellcode in der Regel akribisch und teste ihn auch auf mehreren Browsern unter unterschiedlichen Bedingungen, bevor ich den Content rausrolle.

Doch was, wenn sich Standards ändern?

Alleine schon die erste Zeile, da gehts los. <!DOCTYPE html> Diese Dokumentdeklaration ist unter HTML5 gängig. Vorgänger kannte ich nicht, aber da W3Schools das abgrenzt gehe ich von einer Änderung aus.

Was mir als Neuling fehlt, ist die Einschätzung, wie schnell sich Dinge wie Standards ändern. Eher Kontinentalplattenverschiebung oder eher doch so, dass man kaum hinterherkommt, wenn man kurz einen Moment pennt?

Bei einer Website mit rund 20 handgeschriebenen Seiten eigentlich noch überschaubar, aber was ist, wenn man wirklich eine Mega-Site mit hunderten Seiten baut und es dann irgendwann heißt: "jetzt heißt der TAG so und so und der muss jetzt immer vor dem so und so stehen." Beginnt dann eine Baustelle wie auf deutschen Autobahnen? Bist du mit einer fertig, haben sich schon 3 neue aufgetan?

Oder sind das immer nur ganz kleine Veränderungen die auch nur alle paar Schaltjahre stattfinden?


Ich weiß natürlich, dass ich mir bei Jimdo und Co. einfach eine Website zusammenschustern kann und Jimdo und Co. müssen dann zusehen, dass der darunterliegende HTML Code allen Standards entspricht. Aber wo bleibt da der Spaß?^^


Abschließende Frage also: Die jetzt geltenden Standards zu Dingen wie HTML5, CSS, PHP, JavaScript etc. wie langlebig sind sie, in welchen Abständen kommen Veränderungen und wie gravierend sind diese Veränderungen?
 
Ohne dass ich jetzt Profi bin:

Aber:
Selbst wenn Standards erneuert werden, heißt das nicht, dass jeder Browser sofort dafür Support verliert.
Das wäre ja eine mittelschwere Katastrophe wenn alle Webseiten auf einmal nicht mehr funktionieren würden.

Dein Browser wird also immer einen gewissen Grad an abwärtskompatibilität haben. (und der ist schon ziemlich groß)

Manchemal wenn sich einiges geändert hat, dann muss man tatsächlich einiges an Code in die Hand nehmen um wieder auf dem neusten Stand und die neusten (Tools) zu nutzen.
Aber hier hilft auch sehr gut die Suchen Ersetzen Funktion jedes vernünftigen Editors.

Alternativ kann man ja auch selbst HTML schreiben sich aber einige Tools zu nutze machen.
z.B. liegt ein Default <head> in einer Datei ab und dieser wird "dynamisch" in alle Dateien eingebunden.
Dann muss die Änderung nur noch in einer Datei und nicht mehr in allen selbstgeschriebenen Dateien erfolgen.

Was ich damit sagen will: Selbst wenn du deine Seite händisch schreiben willst, heißt das ja nicht, dass du auf einem Blatt Papier (oder analg dazu) arbeiten musst.
Nutze doch einfach einige Dev Tools um dir das Leben leichter zu machen.

Alternativ kannst du auch eine Platform /Framwork verwenden, was dir schonmal einiges abnimmt und du konzentrierst dich nur auf deine eigene Funktionen/Programme.

Denn ein großes Projekt baut selten von 0 auf. In der Regel wird auf diverse Frameworks zurückgegriffen.
 
Schaue, dass du Valides HTML schreibst und wenn das HTML generiert wird auch valide generiert wird.
https://validator.w3.org/

Zu den Standards und Langlebigkeit - kommt darauf an was du machst/verwendet - es kann sein das gewisse Tags/Attribute später depricated/not supported werden, die früher mal "standard" gewesen sind. z.B.
http://www-db.deis.unibo.it/courses/TW/DOCS/w3schools/tags/att_a_name.asp.html

oder solche Änderungen: https://www.w3schools.com/howto/howto_css_style_header.asp vs https://www.w3schools.com/tags/tag_header.asp
 
  • Gefällt mir
Reaktionen: Piktogramm
Bin gespannt, was andere schreiben.
Meine Wahrnehmung ist, dass der Web-Bereich ein sich vergleichsweise schnell ändernder Markt ist, wobei es da (afaik) weniger um die Standards, sondern um die Technologien geht. Solange du es aber als Hobby betreibst kann es dir egal sein, dass Framework X angeblich aus der Mode gekommen ist oder jetzt "alle" Y einsetzen. Diese Technologien werden in aller Regel dann immernoch dauerhaft gepflegt und verfügbar.

Echte 'breaking changes' würde ich in dem Bereich als eher selten verorten, da sowas dann globale Auswirkungen auf Milliarden von Menschen hat. Sprachen wie PHP oder JS werden eher erweitert und nur einzelne Aspekte werden mit viel Vorlauf entfernt und meist sind das Dinge die sowieso 'weird' waren und man von Anfang an nicht hätte machen sollen (ohne jetzt konkret die Situation bei PHP/JS an sich zu kennen).

Sieh dir als Fallbeispiel mal Python 2 vs. Python 3 an. Das war so ein Fall, da haben sie viel umgebaut von einer Versionsnummer zur nächsten. Das ist aber schon recht selten.
 
  • Gefällt mir
Reaktionen: tomgit
McMoneysack91 schrieb:
Alleine schon die erste Zeile, da gehts los. <!DOCTYPE html> Diese Dokumentdeklaration ist unter HTML5 gängig.
Deine Seite ist als HTML5 deklariert und wird immer HTML5 bleiben...bis du es selbst umstellst.

HTML4 funktioniert heute auch noch. Also kein Stress :-)
 
  • Gefällt mir
Reaktionen: RalphS und BeBur
Sieh das saubere Programmieren (also Nicht-Verbiegen deiner Seite an ungültige Standards) als Protest. Ich weigere mich immer gegen den Standard zu coden. Die Browser die diesen nicht unterstützen, können sich sonst wohin schleichen und ich werd ganz sicher nicht für die paar Exoten da zig Ausnahmen in meinen Code schreiben. Es gab Zeiten, da war es notwendig, aber inzwischen sind wir hier auf einem echt gutem Pfad und jetzt wieder damit anzufangen wäre grauenvoll.
 
  • Gefällt mir
Reaktionen: Boa-P und McMoneysack91
Janush schrieb:
Deine Seite ist als HTML5 deklariert und wird immer HTML5 bleiben...bis du es selbst umstellst.
Dass die Seite HTML5 bleibt ist klar. Das ist die Macht des handgeschriebenen Codes. Aber ob die Browser kompatibel bleiben, wenn es mal weiter geht, das war meine Sorge :D

@p4cx Damit hast du eigentlich auch meine parallel gelagerte Frage eines anderen Threads beantwortet, ob es meine Unzulänglichkeit als Programmierer ist, wenn nicht nicht jeden Browser bedienen und zufriedenstellen kann. :D

@|RaBtEr| ich verwende zwar keine IDEs oder sonst ausgeklügelte Systeme. Schreibe in FeatherPad oder Geany. Aber die Architektur meiner Seite habe ich so gestaltet, dass eigentlich der gesamte Aufbau zentral an einem Ort (im Ordner der Architekturen) gelagert ist.

Dieser Ordner enthält massig Dateien mit nur wenigen Zeilen, die bestimmte Dinge wie <header> <div> <nav> etc beinhalten.

Die Seiten selbst haben lediglich einen PHP Befehl, via include diese Elemente aus dem Architekturordner an die richtige Stelle der Seite zu ziehen.

Der Text der jeweiligen Felder ist wiederum in eigenen Textdateien in einem separaten Ordner abgelegt. Quasi alles von einander losgelöst und zentralisiert.

Sprich, angenommen ich hätte eine Website mit 10000 Seiten und wollte bei allen irgendwelche Veränderungen vornehmen, dann bearbeite ich nur eine einzige Datei im Architekturordner und alle Seiten importieren sich das korrigierte schon automatisch.

Ich weiß, ich mache es mir selbst "schwieriger" aber das mache ich mit Absicht, weil ich so die absoluten Grundlagen kennenlerne und solche spaßigen Funktionen entdecke.
 
Zuletzt bearbeitet von einem Moderator:
Wie definierst du "Zukunftssicherheit"? So, dass der Kram überhaupt funktioniert? Das ist kein sonderlich großes Problem.
Ich definier's so, dass man " konkurrenzfähig" bleibt, das ist das größere Problem.
Diese Zukunftssicherheit kannst du beim Programmieren knicken, die hast du am ehesten bei Embedded-Systems, aber auch da bewegt sich was.
Das ist ein ständiger Lernprozess, um auf dem Laufenden zu bleiben.

Dass HTML-Tags irgendwann deprecated sind, kommt vor. Da reicht's aber eigentlich, den Kram ab und zu mal durch nen Validator laufen zu lassen. Die funktionieren dan oft trotzdem noch eine ganze Weile, man hat also eine großzügige Übergangszeit.

PHP ist im Großen und Ganzen recht unkritisch, wird auch nicht im Browser ausgeführt. Aber auch da bewegt sich einiges, moderne PHP-Projekte sehen anders aus als vor 10 Jahren.
 
Hi @McMoneysack91 ,
wenn du sehen willst was in den nächsten Jahren kommen wird, lohnt sich immer ein Blick ins GitHub vom W3C . Hier beispielsweise findest du die kommenden CSS Updates. Man ist da auch herzlichst eingeladen, mitzumachen ;)

Das sich Tags mal ändern, sehe ich fast als ausgeschlossen, eher werden die deprecated oder es kommen neue dazu. Hier ist wohl die bekannteste Quelle MDN. Wie bereits erwähnt, ändern sich Dinge im Web, im Vergleich zu anderen Indutrien, relativ schnell. Aber die Browser unterstützen meist lange, noch die "alten" DInge.

Generell finde ich persönlich es wichtig, semantisch korrektes Markup zu schreiben. Man kann zwar alles aus <div> bauen, tun sollten man es aber nicht ;)
 
Macht man das heutzutage noch? Plain HTML und CSS? Selbst als Hobbyprojekt macht es doch Sinn ein Framework wie Bootstrap zu verwendet oder nicht? Alleine weil man sich dann ein einem gewissen "Standard" hält. Klar fürs lernen und die ersten Stunden ist es sicherlich das beste.
 
Ich kann nur aus eigener Erfahrung sprechen.
Für Layout Dinge würde ich heutezutage nicht mehr auf ein Framework gehen. Dafür sind Dinge wie CSS Grid zu mächtig und einfach zu bedienen.
Bei Plain HTML bi ich bei dir, da würde ich zumindest irgendein Tooling drauf werfen das ich nicht immer alles wiederholen muss.

Schlussendlich ist aber alles was im Browser endet und dargestellt wird plain HTML und CSS. Von daher denke ich ist es wichtig dort immer gut Bescheid zu wissen. Semantisch korrekt, erschlägt halt auch einige A11Y Probleme.
Vorallem was in den letzten Jahren in CSS passiert ist und was dort noch in den kommenden Jahren kommen wird. Alles sehr interessant und wird einem neue Möglichkeiten bieten.

Bspw. neue Color Funktionen, rückwärts-schauende Selectoren, Container-Querys, Sub-Grid...:)
 
Boa-P schrieb:
Für Layout Dinge würde ich heutezutage nicht mehr auf ein Framework gehen. Dafür sind Dinge wie CSS Grid zu mächtig und einfach zu bedienen.
Machst du denn berufsmäßig kontinuierlich CSS?
Ich hab damals bei meinem (einzigen) Projekt auf Bootstrap zurück gegriffen und war sehr froh über die fertigen Komponenten, Formulare, etc.. Das war aber evtl. auch gar nicht das was du meinst, du schriebst ja auch von "Layout". Aber so eine Design-Komplettlösung wie Bootstrap finde ich schon sehr sympathisch, wenn es nicht gerade total fancy oder originell aussehen muss.
 
  • Gefällt mir
Reaktionen: Madman1209
Natürlich werden die Browser irgendwann inkompatibel. Aber das dauert eine längere Weile.

Ich finde HTML5 ziemlich albern - nicht zuletzt wegen der sinnlosen DOCTYPE Deklaration und der implizit angenommenen, aber nirgends erforderlichen xmlns Deklaration / Compliance.

Aber dennoch, aktuelle Browser können trotzdem auch HTML 3.x Standard genügende Dokumente darstellen, wenn sie denn entsprechend ausgezeichnet sind.

Es fällt natürlich schwer, "DOCTYPE html" explizit irgendeiner Revision des HTML-Standards zuzuweisen. HTML5 ist ein Standard "für Dumme", alles das was bis dahin noch für eine ordnungsgemäße Darstellung erforderlich war an Deklarationen ist weggefallen und die Versionierung auch. Wenn es jetzt irgendwann HTML6 geben "sollte"... dann wird sich das sicherlich nicht in "DOCTYPE html" widerspiegeln (können) und entsprechend hat man in Bezug auf Revision 5 voraussichtlich das Problem fehlender Revisionssicherheit; denn während HTML6 oder später sicherlich irgendeinen neuen xmlns referenzieren kann, so ist dieser für HTML5 halt optional und ein Browser kann sich den Unterschied bestenfalls "denken".


Aber dennoch, bis auf weiteres bleibt uns allen nicht viel übrig, auf HTML4 oder 5 zu setzen oder in Richtung XHTML zu gucken und immer zu bedenken: die Transitional Option gilt es grundsätzlich zu meiden, wenn es keinen triftigen Grund dafür gibt (zB die Migration der bestehenden Website auf eine neuere HTML-Revision).
 
sh. schrieb:
@Boa-P welches Tooling kannst du den empfehlen oder was verwendest du da so?
Hi @sh. ,
wenn es rein um Templates bauen geht nutze ich ganz gerne sowas wie handlebars.js. Dabei handelt es sich um eine HTML Template Engine. Dafür reicht dann ein kleines Node Programme, was dir das immer wieder ausführt. Dazu kann man sowas nutzen wie gulp.js.
Dazu sei gesagt, dass sind beides nicht die latest oder hottest Libraries/Frameworks, aber sie tun Ihren Job.

Was ich auch schon gemacht habe, ist React als Template Engine zu nutzen. Denn man kann Reacht nicht nur zum App Bau nutzen, sondern sich auch einfach das resultierende HTML ausgeben lassen. Dazu bedarf es dann aber ein etwas größeres Node Programm. War für unseren Use-Case aber notwendig.
BeBur schrieb:
Machst du denn berufsmäßig kontinuierlich CSS?
Ich hab damals bei meinem (einzigen) Projekt auf Bootstrap zurück gegriffen und war sehr froh über die fertigen Komponenten, Formulare, etc.. Das war aber evtl. auch gar nicht das was du meinst, du schriebst ja auch von "Layout". Aber so eine Design-Komplettlösung wie Bootstrap finde ich schon sehr sympathisch, wenn es nicht gerade total fancy oder originell aussehen muss.
Hi @BeBur ,
jip mach das berufstätig. Bootstrap und ähnliche Produkte haben, definitv ihre Berechtigung und man kann damit gut Dinge bauen. Das Problem meiner Meinung nach ist dabei nur, man verliert seinen eigenen Look ;) Und die ganze Zeit alles zu überschreiben, macht auch keinen froh.
Wenn die Seite die gebaut werden soll eine gewisse Größe hat, dann kommt meist das eigene Design. Da fangen dann an Lösungen wie Bootstrap einem im Weg zu stehen. Wir haben bspw. bei uns in einem Projekt in den letzten Monaten Bootstrap ausgebaut, dass war kein Spaß :D und das wird leider auch immer vergessen bei solchen Komplettlösungen. Was kostet es mich das wieder auszubauen, zu updaten oder weiterzuentwicklen.
Aus meiner Erfahrung kann ich berichten, dass so etwas wie Bootstrap häufig nur für das Grid System eingesetzt wird. Hier bin ich fest der Meinung das man das nicht mehr braucht und stattdessen CSS Grid benutzen kann und sollte.
Kleines Beispiel:
HTML:
<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta http-equiv="X-UA-Compatible" content="IE=edge" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>Computerbase</title>
    <link rel="stylesheet" href="./main.css">
  </head>

  <body>
    <div class="logo">some logo</div>
    <header>menu items, quick links etc.</header>
    <nav>side navigation</nav>
    <main>just content</main>
    <footer>additional links etc.</footer>
  </body>
</html>
CSS:
body {
  margin: 0 auto;
  padding: 0;
  width: 100%;
  height: 100vh;
  max-width: 1000px;

  display: grid;
  grid-template-columns: repeat(4, 1fr);
  column-gap: 2rem;
  grid-template-rows: 3rem repeat(2, 1fr) 4rem;

  /* mobile Viewport */
  grid-template-areas:
    "logo header header header"
    "nav nav nav nav"
    "main main main main"
    "footer footer footer footer";
}

/* tablet Viewport */
@media (min-width: 500px) {
  body {
    grid-template-areas:
      "header header header logo"
      "nav main main main"
      "nav main main main"
      "footer footer footer footer";
  }
}

/* desktop Viewport */
@media (min-width: 1000px) {
  body {
    grid-template-areas:
      "logo header header header"
      "nav main main ."
      "nav main main ."
      "footer footer footer footer";
  }
}

.logo {
  grid-area: logo;
  background-color: rosybrown;
}

header {
  grid-area: header;
  background-color: palevioletred;
}

nav {
  grid-area: nav;
  background-color: aliceblue;
}

main {
  grid-area: main;
  background-color: aquamarine;
}

footer {
  grid-area: footer;
  background-color: darkcyan;
}

Wie man sieht, bedraf es keiner extra <div> Tags mehr die einen Container oder Row definieren. Was definitv Geschmackssache ist, will ich mein Layout im HTML haben oder in CSS. Ich bi großer Fan davon, alles was das aussehen betrifft im CSS zu haben. ;)
Gut zu sehen ist, ich kann im CSS besstimmen, wie das Layout aussehen soll, gut zu sehen unter dem Attribut "grid-template-areas". Den einzelnen Elementen sagt man dann nur noch auf welche von diesen Areas die sich legen sollen. Hier sei gesagt das ist nur eine Möglichkeit mit CSS Grid ein Layout zu beschreiben.
CSS Grid + Flex Box ist dann auch für mich aktuell alles was ich brauche um Dinge im Web zu bauen. Wir konnten damit auch JavaScript Lösung auf reine CSS Lösungen umbauen, was wiederrum der Performance gut tut.
Bei Fragen komm gerne auf mich zu.
 
  • Gefällt mir
Reaktionen: sh. und BeBur
@Boa-P sehr cool was man mit dem CSS Grid alles machen kann :)

Was hälst du persönlich von Wordpress? Mann muss ja nicht unbedingt alles mit einem Page-Builder zusammenklicken. Klar ist Wordpress für eine kleine statische Seite schon übertrieben aber heutzutage kostet ja guter Webspace auch noch kaum was im Verhältnis von früher.
 
Wordpress ist halt auch ein komplexer Faktor, wenns um Sicherheit geht. Klar ist es cool am Ende ein vollständiges CMS zu haben, aber man muss halt wirklich immer am Ball bleiben und fleißig die Software updaten, ansonsten kann es passieren, dass du am Ende dich bei deiner Seite nicht mehr einloggen kannst...
Wenn es eine kleine statische Seite, dann würde ich, wann immer es möglich ist, auf Wordpress verzichten, auch wenn es einem zu Beginn das Leben deutlich vereinfachen könnte. Langfristig hat man damit aber mehr Arbeit als mit einer rein statischen Seite.
 
Hi,

das sehe ich anders. Seit WordPress den Core und auch Plugins automatisiert updaten kann ist die dauerhafte Arbeit damit auf ein Minimum reduziert.

Und nachdem es in meiner persönlichen Erfahrung so ist, dass Projekte eher wachsen als Schrumpfen sparst du dir gerade im weiteren Verlauf bzw. Nachgang sehr viel Zeit damit. Mit einem Tool wie ManageWP lassen sich auch mehrere Instanzen zentral verwalten, sichern und updaten.

Auch verstehe ich nicht, wieso das Wort "Page Builder" so despektierlich benutzt wird. Ein richtig guter Page Builder reduziert die Angriffsfläche, weil man sich damit etliches an Plugins sparen kann. Und für die Performance ist es auch nicht von Nachteil. Im Gegenzug hat man aber viel Komfort und trotzdem noch die Möglichkeit, selber Hand anzulegen wenn man das möchte oder muss.

Ich sehe hier eigentlich nur Vorteile.

VG,
Mad
 
An sich stimme ich dir auch zu, nur mit einem kleinem (großem) Einwand: Ich habe die Erfahrung gemacht, dass die Auto-Updatefunktionalität gerne abgestellt wird, da viele Wordpressbenutzer gerne an der Codebasis des CMS herumdoktern und somit dann Angst haben, dass ihre Änderungen durch ein Update überschrieben werden. Geht man von dem einfachsten Fall aus, nämlich, dass nicht an Wordpress selbst was geändert wird und auch keine exotischen Plugins verwendet werden, dann ist Wordpress eine relativ sichere Sache, wenn es sich selbst updatet.
Relativ halt auch nur weil Wordpress (inkl. Plugins) so groß und bekannt ist, dass es auch oft unter Beschuss genommen wird: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=Wordpress
Die gelisteten Schwachstellen sind nur die, die bekannt sind.

Zum Wachsen von Projekten: Ja, da stimme ich dir zu. Wenn da immer jemand am Ball ist und sich um alles kümmert, dann mach ich mir um die Sicherheit auch keine Gedanken und empfehle da auch gerne Wordpress. Oftmals wird aber eine Seite erstellt, z.B. für einen Verein, die dann einmal mit Inhalten gefüllt und dann nie wieder angefasst wird. Genau bei solchen Seiten steigt das Risiko dann halt, selbst mit Auto-Update: Angenommen die Entwicklung eines Plugins wird eingestellt und es wird bei diesem eine Schwachstelle gefunden.

Ich denke die negative Annotation mit dem Word Page-Builder ist historisch entstanden. Die älteren hier werden sich sicher noch an MS Frontpage erinnern. Denke mehr muss ich dazu nicht sagen. Zum heutigen Stand kann ich nichts sagen, hab noch nie einen Page-Builder verwendet.
 
Zurück
Oben