Hallo Community,
Ich sehe gerade diesen Beitrag und muss deswegen mal mein erstes Posting hier schreiben 
Ich habe das System zu schätzen gelernt (mehrere Projekte in den letzten Monaten), die Kunden kommen auch gut damit zurecht, allerdings nehme ich diesen Thread hier mal als Aufhänger für die Dinge, mit denen ich nicht einverstanden bin. Generell stösst mir die Durchmischung von Content-/Layoutadministration im Backend auf. Das System ist ein CONTENT Management System und kein LAYOUT Management System.
Der Anspruch ist zwar universell, allerdings ist dieser durch die komplexe und teilweise krude Technologie CSS und deren Browserunterstützung in Verbindung mit Javascript nicht umzusetzen. Hier mal ein paar konkrete Punkte, die ausschliesslich den eingebauten Template-/Layoutansatz betreffen und mir unter der Voraussetzung der Verwendung des eingebauten Templates nicht gut gefallen:
1. TL benutzt Positionsangaben für die Spaltenselektoren
Die Bezeichnungen für die id-Selektoren "left" & "right" sind m. E. nach unglücklich und überholt. Es bietet sich generell an, für Selektoren semantische Bezeichnungen zu wählen. Warum? Will mein Kunden alle Inhaltsmodule auf der rechte Seite auf die linke Seite verfrachten, habe ich 2 Möglichkeiten:
1) Entweder ich tausche im Backend bei allen Seitenlayouts alle Module aus -> viel unnötige Arbeit und fehlerträchtig
2) Oder ich positioniere per CSS die Spalte rechts/links um, allerdings befindet sich dann die DIVision "left" rechts im Layout und der DIV-Container "right" auf der linken Seite -> wenig Arbeit, aber verwirrend.
Würde man man einheitlich semantische Bezeichnungen für die Selektoren nehmen, wäre man das Problem los und ist nicht auf die Position festgelegt, sprich, die kann mit 2 Zeilen CSS geändert werden. Als Beispiel ist hier "main" zu nennen, das ist eine semantische Bezeichnung. Für weitere Spalten wäre z. B. "sub1" und "sub2" oder "sub_a" und "sub_b" in Ordnung (statt "left" und "right").
2. TL legt mich/sich auf ein JS-Framework fest
Die mootools möchte ich grundsätzlich nicht benutzen, deswegen möchte ich die auch nicht eingebunden haben. Sicherlich geht es nicht nur mir so. Die JS-Dateien sind aber fest in fe_page.tpl verdrahtet. Hier sehe ich das generelle Problem, dass es einfach unelegant ist, sich in der Fülle der Möglichkeiten auf eine Lösung von Herstellerseite aus festzulegen. Daneben spielt hier auch Punkt 4 eine Rolle, wenn ich kein eigenes Template benutze (mit entfernten mootools-Links), sondern einfach jQuery oder was weiss ich zusätzlich einbinde.
3. TL nutzt Inline-CSS
HTML-Code:
<style type="text/css" media="screen">
<!--/*--><![CDATA[/*><!--*/
#header { height:200px; }
#left { width:200px; }
#right { width:100px; }
#main { margin-left:200px; margin-right:100px; }
#footer { height:200px; }
/*]]>*/-->
</style>
Hiermit erzeuge ich eine Spezifität in der Kaskade von 1,1,0,0. Dadurch lege ich mich sehr fest, da 1,n,n,n kaum zu überschreiben ist (nur durch spätere Inline-Anweisungen). Das ist zwar bei den Positionierungen für "gröbere" Strukturelemente kein so grosses praktisches Problem, allerdings kein eleganter Stil.
4. TL macht mein Frontend langsam(er)
"Out of the box" bringt TL das folgende mit:
HTML-Code:
<link rel="stylesheet" href="system/typolight.css" type="text/css" media="screen" />
<!--[if lte IE 7]><link rel="stylesheet" href="system/iefixes.css" type="text/css" media="screen" /><![endif]-->
<link rel="stylesheet" href="plugins/slimbox/css/slimbox.css" type="text/css" media="screen" />
<script type="text/javascript" src="plugins/mootools/mootools.js"></script>
<script type="text/javascript" src="plugins/slimbox/js/slimbox.js"></script>
Binde ich nun über das "Head"-Feld z. B. noch jQuery ein (wie unter 2. schon ausgeführt) habe ich 6 (!!!) extern eingebundene Dateien, ohne überhaupt eine einzige eigene Stilangabe geschrieben zu haben. Mit meinem Stylesheet bin ich dann bei 7 Dateien. Mittlerweile sollte sich rumgesprochen habe, dass das Reduzieren von http-Requests Webseiten deutlich beschleunigen kann. Parallel kann ein Client von einer Domain 2 Sachen gleichzeitig anfordern: CSS-/JS-Dateien, Bilder, Hintergrundbilder. Mit jedem zusätzlichen Request erzeugt man eine Latenz von ca. 200 ms + Downloadzeit pro Request. Reduziere ich den ganzen Krimskrams auf das Notwendigste verbessert man durch den schnelleren Seitenaufbau die Nutzererfahrung und damit die Usability. Hier steht mehr darüber: http://developer.yahoo.com/performance/rules.html
Wo wir gerade bei Beschleunigung sind: JS-Dateien sollten am Ende des HTML-Dokumentes eingebunden werden, auch das geht nur mit eigenem Template.
Ein unangenehmer Nebeneffekt ist es, dass ich auch erstmal nicht weiss, wass in typolight.css und iefixes.css drinsteht und ich mitunter Nebeneffekte habe, die nicht kalkulierbar im CSS zu beheben sind.
5. TL erfordert das Erlernen der systemeigenen Selektorbezeichnungen
Wenn man nur TL benutzt, ist es sicherlich möglich, sich mit den systemeigenen Bezeichnungen so auseinanderzusetzen, dass man diese blind runterbeten kann. Ich selbst arbeite jedoch regelmäßig mit 5-6 verschiedenen Content Management Systemen und da erwarte ich einfach, dass sich das System mir bzw. meinem CSS-Stil anpasst (Bezeichnungen, Arbeiten im Editor, Single-Line CSS). Zum Glück geht das mit wenigen Änderungen im Haupttemplate von TL (als Kopie) ganz gut.
Warum schreibe ich das alles? Das Ausgangsposting beschreibt, warum man (als TL-Newbie) keine eigenen Templates benutzen soll. Ich möchte jedoch dazu anregen, sich selbst Gedanken darüber zu machen, was "unter der Haube" des Frontends (m)einer Webseite steckt. Es ist eine sehr eigene und subjektive Philosophie, die diesbezüglich in TL verfolgt wird und die wie oben ausgeführt auch Schwachstellen hat. Der TL-Ansatz ist meiner Meinung nach nicht universell genug (geht das überhaupt mit dem derzeitigen Stand der Dinge CSS und XHTML betreffend?), bietet zum Glück aber genügend Freiraum, um eigene Arbeitsprozesse zu integrieren.
"Wie bekomme ich meine Klassennamen in das TL-Template?"
Antwort: Nur mit extrem viel Aufwand, da nicht 1, sondern X (Sub-)Templates angepasst werden müssten. Und dies ggf. auch nach einem Update. Die einfachste Lösung ist die, die eigenen Css-Anweisungen auf die TL-Klassenbenennungen anzupassen.
Das kann man so nicht sagen. Arbeitet man sauber über die Kaskade, habe ich gar keine Änderungen im Template.
Beispielhaft für die eingebaute fe_page.tpl das CSS:
HTML-Code:
#main h2 { ... }
#main p { ... }
ohne Templateänderungen statt
HTML-Code:
h2.hauptinhalt { ... }
p.hauptinhalt { ... }
und dem Ändern der vielen Templatesnippets für die ContentElements.
Allerdings ist das wohl eher ein grundsätzliches Konzept der Arbeit mit Cascading Style Sheets, das in jedem Fall unabhängig vom System verfolgt werden sollte.
Danke für's Lesen und Eure Anmerkungen.
Gemischte Gedanken zu Layouttemplates
Zitieren
Zitat von IamManu
Lesezeichen