WhiteShark schrieb:
Also diese Aussage kann man so nicht stehen lassen. Ein CMS erzeugt Code aus einem Template. Wenn das Template aus lauter Tabellen aufgebaut ist, würde ich das nicht als sauber bezeichnen.
Auch kann ein Template fehlerhaft sein. Und wenn man es anpassen will können genauso Idiotenfehler passieren wie ohne CMS.
Erst recht wenn man das Template komplett selbst aufbaut.
Kommt aufs CMS an. Bei Contao ist der gesamte Core seit 2.11 (2.10 hatte Macken in der Verwendung von Article, Section und Aside) fast durch die Bank weg sauberes HTML5. 3rd Party Extensions, die für 2.10/11 freigegeben sind, sind größtenteils ebenfalls komplett auf HTML5-Notation umgestellt. Du kannst eine sehr komplexe Seite zusammen klicken, ohne jemals ein Template zu modifizieren, und hast trotzdem weitestgehend semantisch sauberes HTML5-Markup.
Das einzige Problem, das ich kenne, ist die Art und Weise, wie TinyMCE hier mit Blockquote arbeitet. Zitate werden zwar je nach Auswahl als <q> oder <blockquote> angelegt, aber die Parameter sowie der Autor-Footer lassen sich nicht automatisiert erzeugen.
Auch erzeugt ein CMS keinen effektiven Code. Gerade wenn man viele Plugins nutzt, so binden die alle ihr eigenes CSS und Javascript ein. Effektiver wäre es, wenn man das alles in einer Datei zusammenpacken würde (siehe oben).
Kann man umgehen. Kommt aufs CMS an.
Bspw kann man sich auf nem Zettel skizieren wie der Aufbau der Seite sein soll und das dann Schritt für Schritt in Html/CSS umsetzen.
Nennt sich Screenraster, das macht jeder gute Designer so. Genauso wie ein guter Programmierer als erstes einen PAP (oder ähnliches) skizziert, skizziert ein Designer erst einmal die grobe Aufteilung und Struktur.
Jesterfox schrieb:
@Miyamori: wenn eine Seite wirklich semantisch korrekt ist, dann kann man sie auch ohne JavaScript benutzen (Navigation bedienbar, kein AJAX). Die per JS realisierten Extras kommen dann nur als Bonus oben drauf.
<ul><li><a href="link-1"><ul><li><a href="link-1-sub-1"></li></ul></li>
Mag semantisch korrekt sein, aber was passiert wohl bei ul ul {display:none}, und selbiges display:none erst per JS aufgehoben wird?
Gerade bei den rotzigen 20$-Templates aus Themeforrest wird laufend mit JS-basierten Navigationen gearbeitet, die am Ende ohne JS gar nicht funktionieren und dabei doch nichts besser können als eine reine CSS-Version. Schön, ohne CSS3 hat man keine hübsche Slide-In - Animation, und?
omaliesschen schrieb:
PS: Es geht nach wie vor um semantisch penibel vs. average div/span/p/h/ etc.
Schon allein die semantisch (und SEO-technisch) korrekte Verwendung der Headlines ist ein Fall für sich. Selbige macht extrem viel aus. Bei HTML4/XHTML1 werten Suchmaschinen z.B. die mehrfache Verwendung von <h1> ab.
omaliesschen schrieb:
Für Sehschwache integrier ich eine JS Lupe.^.^
...und ignorierst damit genau die Leute, für die Barrierefreiheit gedacht ist.
Semantisch korrekter HTML5-Code erleichtert es barrierefreien Lesegeräten, die Seite korrekt "darzustellen". Ein entsprechend moderner Screen Reader kann durchaus zwischen <body><header> und <article><header> unterscheiden. Das macht einen gewaltigen semantischen Unterschied.
Manche Seiten welche von google auf Seite eines gelistet sind wissen nicht einmal was html überhaupt ist...
Wenn die Seiten alt, hoch frequentiert und inhaltlich sehr wertvoll sind: warum nicht?
Du baust aber keine ALTE Seite mit einer gewaltigen Menge Stamm-Besucher. Du baust eine komplett neue Seite oder überarbeitest eine bestehende.
Edit: Das tags wie <article> sinnvoll sein können wird gar nicht bezweifelt, es ging vorhin um tags wie blockquote oder dl, dd, darauf basiert die Argumentation.
Du begreifst immer noch nicht, dass es auch Projekte gibt, an denen mehrere Menschen arbeiten. Was denkst du, wird z.B. passieren, wenn jemand anderes deine Projekte übernimmt?
Ein wirklich gutes Beispiel für eine korrekte Verwendung von <dl> (Definition List) wäre z.B. ein Glossar. Klar, du kannst ein Glossar auch als Wald voll <div> aufbauen... aber dein Nachfolger an dem Projekt kann den Code deutlich besser lesen, wenn du semantisch korrekt gearbeitet hast. Auch du selbst kannst den Kram besser bearbeiten, wenn du ihn in einem Jahr noch einmal anfassen musst.
Semantische Korrektheit verbessert die Wartbarkeit von Code und senkt das Datenvolumen. Eine Reihe von Kommentaren im HTML-Code oder monströse Klassen-Konstrukte können auch den Code strukturieren, erhöhen aber das Datenvolumen deutlich. Und auch der DOM-Parser wird nicht gerade schneller dadurch, dass er die 10 Klassen eines Divs durchwursteln muss.
Kleines praktisches Beispiel: Ich will jeden Kopfbereich eines Artikels in einem Blog mit einem grauen Hintergrund versehen:
Code:
article > header {background: grey;}
Wenn dich die Vorteile von HTML5 abseits von "juhu, ich kann Videos einbinden" nicht interessieren, dann lass es halt. Bleib bestenfalls Mittelmaß, eher unterste Schublade. Wir professionellen (im Sinne von: Wir werden dafür bezahlt) Webentwickler sind nicht dazu da, dir alles vorzukauen.
omaliesschen schrieb:
...und selbst wenn.
Ein einfaches +/- in der Schriftgröße, gespeichert in nem Cookie oder Local Storage, kann die Nutzererfahrung deutlich verbessern. Man muss solche Optionen nur mit Bedacht einsetzen.
