CMSimple und Webstandards 5 - Templates

[Gert]

Bereits erschienen:
CMSimple und Webstandards - Prolog
CMSimple und Webstandards 1 - Validierungslinks im Template
CMSimple und Webstandards 2 - CMSimple selbst
CMSimple und Webstandards 3 - html und Xhtml
CMSimple und Webstandards 4 - Editoren
CMSimple und Webstandards 5 - Templates
CMSimple und Webstandards 6 - Pluginloader
CMSimple und Webstandards 7 - Plugins

Links zum Thema:
Webstandards bei Wikipedia | (X)html-Validator des W3C | CSS-Validator des W3C | Meine Seiten zum Thema
________________________________________________

Im Gegensatz zu den Plugins können Templates nicht so einfach nach (X)html entwickelt werden. In der template.htm wird der doctype definiert, nach dem die Seiten validieren sollen. Templates können also immer nur Xhtml- oder html-valide gestaltet werden.

Das Hauptproblem bei den Templates ist, dass auf den Download-Seiten der Template-Designer in der Regel nicht angegeben ist, ob es sich um ein html- oder ein Xhtml-Template handelt. Ich muss also immer erst das Template herunterladen und in der template.htm nachschauen, nach welchem Standard das Template geschrieben wurde.

Validierungslinks sind bei CMSimple-Templates ja sowieso nicht üblich, so dass ein Anwender gar nicht merkt, wenn er sich ein Xhtml-Template herunterlädt, CMSimple jedoch auf html eingestellt ist (Xhtml-EndTags deaktiviert) und die Inhalte mit einem html-Editor erzeugt werden.

An die Template-Designer

Liebe Template-Designer: Bitte macht auf Euren Download-Seiten zu jedem Template eine doctype-Angabe oder sortiert die Templates entsprechend. Es ist ein wichtiger Unterschied, ob ein Template z. B. auf html 4.01 transitional oder Xhtml 1.0 transitional basiert. Von den strict-Varianten will ich hier gar nicht reden.

Baut Validierungslinks in Eure Templates ein, damit die Anwender merken, wenn sie invalide Seiten produzieren und das Thema somit vielleicht auch öfters mal in den CMSimple-Foren auftaucht und diskutiert wird. Und vielleicht kommen dann auch endlich mal die nicht validen Plugins zur Sprache, die weder unter html noch unter Xhtml und schon gar nicht unter beiden Standards validen Code erzeugen.

Der erste Schritt zur Besserung ist die Erkenntnis .

An die CMSimple-Anwender

Bitte achtet darauf, dass Eure Einstellungen in CMSimple mit dem doctype des Templates, das Ihr nutzt, übereinstimmen. Wie man CMSimple auf Xhtml oder html einstellt ist hier beschrieben.

Wenn Ihr in Eurem Template keinen Validierungslink findet, dann baut den bitte selber ein. Das ist ganz leicht, wie das geht ist hier beschrieben. Auf dieser Seite erfahrt Ihr auch, wie Ihr Eure Seiten direkt im Validator des W3C auf Einhaltung der Webstandards prüfen könnt.

An die CMSimple-Macher

Bitte macht Vorgaben für eine einheitliche Template- und Plugin-Kennzeichnung, damit sich die weniger versierten Anwender passende Komponenten zusammenstellen können, ohne erst nach dem Download in der template.htm nachsehen zu müssen, in welcher Markup-Sprache dieses geschrieben ist. Mein Vorschlag:

X für Xhtml-Templates
H für html-Templates

Ein Template mit dem Namen "Rote Rosen" könnten dann "Rote Rosen X" heissen, die zip-Datei "rote_rosen_X.zip". Die html-Version dieses Templates entsprechend "Rote Rosen H" und "rote_rosen_H.zip".

"Xhtml" und "html" sind als Kennzeichnung deshalb nicht geeignet, weil bei den Plugins ja noch die Variante (X)html dazukommt. Das ist aber als Dateiname für die zip-Datei nicht geeignet, wegen der Klammern. Die Kennzeichnung für Plugins und Templates sollte jedoch einheitlich sein.

Deshalb: einheitliche Kennzeichnung von Templates und Plugins, XH für (X)html (nur Plugins), X für Xhtml und H für html. Dann können sich die Anwender die passenden Komponenten zusammenstellen.

Das kann aber langfristig nur dann funktionieren, wenn von Seiten der CMSimple-Macher klare Vorgaben gemacht und auf den offiziellen CMSimple-Seiten mit Nachdruck propagiert werden.

Und bitte, liefert bei Euren Downloads eine readme.txt mit, in der die Anwender darauf hingewiesen werden, dass CMSimple auf der Basis von 2 unterschiedlichen Markup-Sprachen betrieben werden kann und dass man bei der Auswahl von Template, Editor und Plugins darauf achten muss, für welche Markup-Sprache diese geschrieben oder programmiert sind.

Oder legt EINEN Standard für CMSimple fest, aber dieses Thema wurde ja bereits an anderer Stelle diskutiert.

[wosee]

Das Problem ist halt, dass viele CMSimple Templates von Haus aus in keinster Weise konform sind.
Bei Soccer von cmsimple-styles.com fehlt z.B. sogar der zweite Teil der Deklaration und dann steh' ich schon beim zweiten Fehler an.

Spalte: 8
Fehler: Im Element td ist das Attribut `BACKGROUND` nicht erlaubt.

Fehlerstelle: <td background="./templates/soccer/images/template_r2_c5.jpg">

Wie lös ich soetwas per CSS und wär's da nicht vernünftiger, gleich das ganze Template umzuschreiben?

Ich rufe die Entwickler auf, dass Templates erstmal in irgendeiner Sprache validiert werden können.

[Gert]

Hallo wosee,

genau das will ich erreichen, dass sich die Anwender nicht nur um die Funktionalität ihrer Seiten kümmern, sondern auch um die Validität.

Bei den Templates wird es auch nicht anders aussehen als bei den Plugins, das kann ich aber schlecht beurteilen, weil ich meine Templates selber schreibe. Deshalb rufe ich hier nochmal alle Anwender von Templates und Plugins auf, ihre Seiten zu validieren und Fehler zu bemängeln, das muss nicht öffentlich erfolgen, man kann auch die Anbieter kontaktieren.

Wenn so etwas von cmsimple-styles.com kommt ist es natürlich besonders peinlich, weil man ja da einen Club-Beitrag zahlt, um die Angebote zu nutzen.

Zu Deinem Problem: wenn ich den Code sehe, gehe ich davon aus, dass man das Template tatsächlich komplett überarbeiten sollte. Aber hier erstmal das konkrete Problem:

Code: Select all

<td style="background: url(./templates/soccer/images/template_r2_c5.jpg);">

Du kannst natürlich auch in der stylesheet.css des Templates eine Klasse oder eine ID definieren und einbinden:

Code: Select all

<td class="Deine_Klasse">

beachte aber dabei, dass eine ID nur einmal pro Seite vorkommen darf.

Mehr dazu bei selfhtml .

[wosee]

Vielen vielen Dank, hab' jetzt 20 Fehler abgearbeitet, der grüne Balken wirkt wirklich schöner wenn man selber Mal handanlegen muss. Nur den Locator hab' ich auskommentiert, weil ich keine Ahnung habe, was da falsch sein soll.

Code: Select all

<table border="0" cellpadding="0" cellspacing="0" style="border-collapse: collapse" width="100%" id="AutoNumber6">
 <tr>
  <td width="100%">
   <tr>
    <td valign="middle" class="locator"	>&nbsp;
     <?=locator()?>
    </td>
   </tr>
  </td>
 </tr>
</table>

Da wird ein <table> ommited und das erlaubt html 4.01 nicht...
Allerdings habe ich nun einfach den vom Validator vorgeschlagenen Code genommen und das funktioniert

Code: Select all

<table border="0" cellpadding="0" cellspacing="0" class="c1" width="100%" id="AutoNumber6">
<tr>
<td width="100%"></td>
</tr>
<tr>
<td valign="middle" class="locator"><?=locator()?>
</tr>
</table>

Mir leuchtet absolut nicht ein, warum dieser Code überhaupt funktioniert...
Aber sorry fürs Threadhijacken, beim nächsten Mal mach' ich einen eigenen Thread auf.

[Gert]

Aber sorry fürs Threadhijacken, beim nächsten Mal mach' ich einen eigenen Thread auf.

KeinProblem, das gehört ja hier her, ich freue mich, 20 Fehler weniger im www und auf CMSimple-Seiten

Wenn du ja sowieso das halbe Template umschreibst, kannst Du ja auch gleich alle html-Formatierungen rauswerfen, ausser "cellspacing", dafür gibt es kein CSS-Äquivalent. Dein table-Code würde dann so aussehen:

Code: Select all

<table cellspacing="0" id="AutoNumber6">

Die id "AutoNumber6" (vermutlich in der stylesheet.css im Template-Verzeichnis) muss ergänzt werden mit:

Code: Select all

#AutoNumber6 {... ; width: 100%; border-collapse: collapse; border: 0; padding: 0;}

Da musst Du aber aufpassen was da schon definiert ist, damit nicht eine Anweisung doppelt ist.

Kleine styles lasse ich manchmal auch im Template, wie z. B.:

Code: Select all

<td style="width: 100%;">

Das kann man ja später ganz einfach per class oder id ins stylesheet auslagern, wenn noch mehr style-Anweisungen im Tag dazukommen.

Html-Formatierungen wie:

Code: Select all

<table background-color="white" border="0" cellpadding="0" width="100%" align="left" valign="top" usw.>

sind out, u. a. weil sie den Code aufblähen. Gegen Tabellen als Layout-Instrument habe ich nix, im Gegensatz zu anderen Webstandard-Fetischisten, aber mit der Verschachtelungstiefe sollte man es nicht übertreiben.

[mvwd]

...soviel zum Thema Validität in Templates.

Habe vor einiger Zeit eine CMSimple-Seite umgebaut und ein Template eines bekannten Template-Designers für CMSimple verwendet. Bei Prüfung der Seite auf Validität kamen mir über 60 Fehler entgegen, die definitiv vom Template stammen.
Also habe ich mir das mal genauer angeschaut: Da waren an allen möglichen und unmöglichen Stellen Codezeilen eingefügt,
die ungefähr so aussehen: </td></tr><!--webbot bot="HTMLMarkup" endspan i-checksum="33806" --></td>.
Da das Template auf Tabellen basiert (wenns denn sein muß...), und die Codezeilen scheinbar willkürlich und unbeabsichtig (wahrscheinlich von Dreamweaver) platziert wurden, validiert diese Seite niemals! Es grenzt meiner Meinung nach an ein Wunder, daß die Tabelle nicht auseinanderfliegt...

Ich habe das für meine Seite dann natürlich berichtigt und die Seite validiert mittlerweile.
Aufgrund der von Gert angestossenen Diskussion habe ich den Designer mal darauf angesprochen, woraufhin er mir folgenden Link (neben ein paar Worten) als Antwort schickte: http://www.cmsimple.dk/forum/viewtopic.php?f=6&t=5887.
Wer's nicht Lesen will, Fazit daraus: Wenn die Seite in allen Browsern funktioniert, wieso dann validieren?

Schade...

Ich weiß, als Plugin-Programmierer muß ich auch vor meiner eigenen Haustüre kehren. Aber wenigstens gestehe ich meine ((X)HTML/CSS)-Fehler und gelobe Besserung...

mvwd.

[Gert]

Hallo mvwd, genau die von Dir zitierte Einstellung (... Wenn die Seite in allen Browsern funktioniert, wieso dann validieren?) ist es, die ich kritisiere und so nicht akzeptiere, da sind wir uns einig.

Ich akzeptiere es durchaus, wenn jemand die Webstandards ignoriert und einfach nur Browsertests macht, was natürlich bei der Vielzahl der Systeme und Browser immer schwieriger wird. Dann sollte der aber konsequenter Weise auch keinen Doctype drüberschreiben.

Wenn ich im html-header einen Doctype definiere, sollte ich mich dann auch an diesen Standard halten. Nach dem Motto: Was draufsteht, sollte auch drin sein. Wenn nichts "draufsteht" (keine doctype-definition im html-header) ist es halt ein Überraschungspaket, wie bei den Koffer-Versteigerungen der Fluggesellschaften. Auch da kann ja durchaus was brauchbares drin sein, vor Überraschungen ist man aber nicht sicher .

Ich freue mich, dass Du den Template-Anbieter darauf angesprochen hast, genau das wollte ich mit meinen Beiträgen erreichen. Als Einzelkämpfer kann ich nix bewirken. Nur wenn der Druck wächst werden Template-Designer und Plugin-Entwickler angehalten, saubere Arbeit abzuliefern.

[mvwd]

Eine Möglichkeit, mit der ich neuerdings zum testen verschiedener Einstellungen bei meinen Arbeiten an Templates/Plugins mein Template dynamisch die passende Doctype verpasse, habe ich hier mal gepostet:

Code: Select all

<?php //set correct doctype depending on CMSimple-settings
echo((strtolower($cf['xhtml']['endtags'])=='true')
?'<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">'
:'<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>');
?>

...wäre doch'ne Möglichkeit die Templates universell zum Download anzubieten. Quasi eine kombinierte HTML/XHTML-Variante. Der User entscheidet dann in der Config von CMSimple ob er HTML oder XHTML haben möchte. Wenn dann noch die Plugins dynamischen Code produzieren wäre doch ein Optimum an Flexibilität erreicht oder?

mvwd.

[CMSimple-Styles.com]

Im Prinzip kann ich hier nur zustimmen allerdings ist das von uns besprochene template uralt und die neueren templates validieren zwar auch nicht alle perfekt, haben aber einen vernünftigen doctype und sind logisch und mit CSS-Positionierung aufgebaut. Validierungslinks werde ich nie auf meinen templates unterbringen, wer überhaupt weiß was Validierung bedeutet weiß auch wie er die w3c-Seite findet. Im vergleich zu den DCWD Templates sind unsere neueren templates jedoch relativ strukturiert aufgebaut und mit wenig Aufwand validieren diese auch, ich habe die templates selbst in etwas abgewandelter form öfters für meine eigenen webprojekte w3c konform umgestrickt. Die Templates von nmud.de sind soweit ich weiß alle perfekt w3c konform.

[Gert]

@mvwd: So einfach geht das nach meiner Meinung nicht. Auch ins Template werden br-Tags, img-tags und andere Solo-tags geschrieben. Die müsste man dann alle mit einer Variablenabfrage einbinden, jeden einzelnen. Jeder Solo-tag müsste also per php eingebunden werden, mit einer Abfrage der endtag-Variablen. Sehe ich das richtig?

Da ist es sicher einfacher, ein Template in Xhtml zu schreiben und dann die End-tags mit suchen & ersetzen zu entfernen und das ganze als html-Version anzubieten.

Nachtrag: Bei einem kurzen Test hat bei mir folgendes funktioniert:

Statt <br> oder <br /> folgendes ins Template einfügen:

Code: Select all

<?php echo tag('br'); ?>

Jetzt werden die tags je nach CMSimple-Einstellung dynamisch erzeugt, wenn jetzt noch die DTD mit einer Variablenabfrage je nach SMSimple-Einstellung erzeugt wird, sollte es möglich sein, ein Template (X)html-valide zu schreiben.

Ist aber noch nicht zu Ende gedacht und getestet ...