Überflüssiger HTML-Quellcode und CSS Klassen in TYPOlight?

Ich habe diese beiden Beiträge aus einem anderen Thema extrahiert und hier ein eigenes Thema damit geöffnet. So kann diese Sache hier separat diskutiert werden :)

Zitat:

---

ich bin für so wenig Markup wie möglich, nur so viel wie nötig :cool:

---

Das Problem ist die Definition von "nötig". Wenn du nur in den Sphären eines einzelnen Webprojekts oder in einfachen Projektgrenzen denkst, stimme ich dir sofort zu. Sobald du aber mal mit den Besonderheiten von sehr breitgefächterten oder anderswertig besonderen Anforderungen zu tun hast, wirst du sehen, dass die "reine Lehre" zwar in der Theorie schön, in der Praxis aber oft nicht sinnvoll ist. Ich könnte dir davon Stunden erzählen. In meiner Anfangszeit mit TYPOlight bin ich Leo deswegen oft sehr auf die Nerven gegangen, habe prinzipiell Templates "gesäubert" usw. Bei anderen CMS habe ich das auch so gehandhabt.

Bis ich mit den Jahren irgendwann gemerkt habe,

...dass es nicht immer der Tod ist, nur weil mal ein paar HTML-Elemente oder Klassen mehr (als auf den ersten Blick anscheinend notwendig) verfügbar sind ;)
... dass das aber bei vielen Projekten der Unterschied zwischen "viel Aufwand - für Kunden unbezahlbar" und "wenig Aufwand - für Kunden bezahlbar" ist. Besonders wenn später mal Änderungen vorgenommen werden oder mal eine neue Funktion eingehängt werden muss.
... dass ein paar Klassen/Elemente mehr für viele Nutzer große Vorteile bieten bzw. diverse bekannte Bugs von vornherein nicht auslösen.
...usw.

Wie so oft, ist also auch hier vieles relativ. Das gute an TL ist, dass jeder dank der Templates die Ausgaben an seine Wünsche anpassen - und auf Wunsch eben auch "säubern" - kann.

PS: Webstandards etc. sollte man natürlich einhalten ... nur dass hier keine Missverständnisse aufkommen :)

Ich schreibe das hier nun doch auch öffentlich (nicht nur in PN/Twitter), da es vermutlich mehrere Leute interessieren könnte:

Ich kann nur wiederholen, was ich schon angedeutet habe: Es kommt auf die Situation an.

Ganz ehrlich, ich erkenne mich in dieser Art der Argumentation teilweise wieder. Vor ein paar Jahren konnte man mich sozusagen zu den "radikalen Webstandard-Barrierefreiheitlern" zählen. Mein Ziel war damals: so wenig Code wie möglich, perfekte Semantik, keine ID/Klasse zu viel, usw. Ich habe deshalb an allen Orten missioniert und versucht jedem CMS-Hersteller meine Sicht reinzudrücken (Typo3, Weblication, Typolight, und viele andere).

Ich bewegte mich damals aber in meinen eigenen begrenzten Kundenprojekten. Diese wurden ausschließlich von mir betreut und es waren meist kleinere/mittlere Kunden. Dort konnte ich meine Sicht der Dinge perfekt durchziehen.

Das ging so lange, bis ich das erste Mal auf Projekte traf, an denen auch andere mitarbeiteten. Oder Projekte die Fremdsoftware integrierten. Projekte mit ganz besonderen Anforderungen in Hinsicht auf die Technik oder Updatefähigkeit. Projekte die sich aus verschiedenen Gründen in Umgebungen befanden, die sich regelmäßig änderten und deshalb variabel sein mussten. usw.

Plötzlich merkte ich, dass mein Ansatz zwar theoretisch schön ist, aber in der Praxis einfach an der Realität von Großprojekten vorbei geht. Oft merkte ich, dass ein paar DIVs oder Klassen mehr plötzlich einen riesigen Unterschied für die Kunden machten: weniger Aufwand, weniger Kosten, leichter anpassbar, weniger Bugs, usw.

Parallel dazu diskutierte ich viel mit sehr bekannten Kollegen aus der Webstandards-Szene und merkte, dass es bei größeren Projekten bzw. bei Projekten an denen ganze Webteams arbeiten andere Voraussetzungen gibt, als bei Einzelkämpferprojekten.

Ich merkte auch, dass sich z. B. ein CMS nicht primär an den perfektionistischen Einzelkämpfer richtet, sondern den Bedürfnissen vieler Leute und Projekte entsprechen muss. Um also beim Beispiel TYPOlight zu bleiben:

Auf den ersten Blick gibt es in TYPOlight jede Menge "unnützen zusätzlichen Quellcode". Zu viele DIVs, zu viele Klassen, usw. Man merkt oft erst nach sehr langer Zeit der intensiven TL-Nutzung mit unterschiedlichsten Projekten, dass da doch eine Logik dahinter steckt. Um mal ein paar konkrete Punkte zu benennen:

In den Listen werden teilweise diverse Extraklassen definiert (first, last, active, trail, etc.). Manche Nutzer werden diese Klassen nie benötigen. Andere Nutzer wollen aber aufwändige Layouts umsetzen und finden so von vornherein alle nötigen Klassen um z. B. das erste Element vom letzten zu unterscheiden, aktive von inaktiven Punkten, um immer abwechselnd (z. B. in Tabellen) die Reihen zu stylen, usw. Beim aktiven Punkt würde nun mancher Nutzer argumentieren, dass das unnötig ist, da der aktive Punkt sowieso kein Link-Element ist und sich somit automatisch vom inaktiven Punkt unterscheidet. Man könnte deshalb doch die Klasse weglassen ... nope, kann man nicht: für viele Layoutideen benötigt man auch diese zusätzliche Klasse.

Oder die Extra-DIVs mit der Klasse .inside im Framework: Manch' einer hält sie für unnötig. Tatsächlich können sie aber (sofern man sie richtig einsetzt) diverse Bugs in Browsern verhindern. Ein paar DIVs mehr, aber dafür sehr viel mehr Stabilität zwischen den Browsern.

Um es auf den Punkt zu bringen: Ich kann durchaus verstehen, wenn mancher Nutzer findet, dass es in TYPOlight oder in anderen CMS zu viel Quellcode gibt. Ich verstehe auch, dass mancher Nutzer für bestimmte Situationen andere HTML-Elemente wählen würden die ihm/ihr semantischer vorkommen. Diese Nutzer möchte ich bitten, dass sie daran denken, dass ein CMS ein Tool für viele Nutzer mit unterschiedlichsten Ansichten ist. Die Ansicht des einzelnen Nutzers kann daher nicht über alle anderen Nutzer gestellt werden.

ABER: TYPOlight bietet euch die Möglichkeit Templates an eure Bedürfnisse anzupassen! So hat TL imho den idealen Spagat zwischen beiden Welten gemacht.

PS: Ich betreue übrigens auch ein Projekt in dem enorm viele Templates angepasst wurden um den "Optimum"-Quellcode zu erreichen. Es ist also definitiv möglich, aber man sollte sich gut überlegen ob es das wert ist, da man natürlich bei Updates aufmerksam sein muss um keine Änderungen zu übersehen. Deshalb hat man zeitweise mehr Aufwand. :)

Sehr schön erklärt Nina, danke dafür.

Der Titel ist jedoch etwas irreführend, man denkt bei Quellcode und Klassen zuerst dass irgendwas am PHP Code bemängelt wird.

Danke für den Hinweis; hab den Titel nun erweitert :)

Ich kann Nina da nur zustimmen. Ich bin auch ein Freund von schlankem Quellcode, Semantik, etc. und habe wie viele denke ich damit angefangen mir meine eigenen Templates zu basteln, weil ich dachte: »Man ist das aufgebläht!« Aber wie Nina schon sagte, hat man mal ein größeres Projekt oder eins, das viele Details abverlangt, dann freut man sich über die zusätzlichen Klassen und IDs. Gerade das ein oder andere DIV ist sogar essentiell, wenn man sich mal mit Cross-Browser-Kompatibilität auseinandergesetzt hat. Ich sag nur: Der IE lässt grüßen. :)

Und die Leute, die sich über den Overhead aufregen, sollten eins immer im Kopf behalten:
Ein einziges nicht oder schlecht optimiertes JPG auf der Seite mit vielleicht 75–100kB verursacht ein Vielfaches mehr an Bandbreite als so ein paar überflüssige DIVs. ;)

Salve, Nina,
ich bin ja erst kurz dabei.
ich finde, viele (richtig verwendete) id/klassen stehen einer zugänglichkeit im sinne von layout-inhalt-trennung nicht im wege.

und was mich besonders an TL beeindruckt SIND diese wohldurchdachten klassen, wie will man sonst halbrunde navibutton am anfang und ende erzeugen etc :cool:

Zitat:

---

In den Listen werden teilweise diverse Extraklassen definiert (first, last, active, trail, etc.).

---

gruss