CMSimple und Webstandards 3 - html und Xhtml

[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
________________________________________________

Eines vorweg: Vieles wäre einfacher, wenn man sich bei CMSimple auf EINEN Standard einigen könnte, z. B. html 4.01 transitional oder xhtml 1.0 transitional. Dann könnte man sich Entwicklerdokumentationen sparen (Naja, das tut man ja auch so). Ich verstehe nicht, dass sich ein CMS, das "CMSimple" heisst, eine solche Hürde auferlegt.

Seit einigen Versionen unterstützt CMSimple 2 Standards, html und Xhtml. Das kann man unter "Einstellungen / Editieren Konfiguration" unter "xhtml_endtags" festlegen, leer bedeutet html und "true" bedeutet Xhtml. Ist diese Option auf "true" gesetzt, erzeugt CMSimple bei Solo-Tags (z. B. <br> und <img ...>) die bei Xhtml obligatorischen EndTags: <br />, <img ... /> usw.

Leider ist es damit nicht getan. Editoren, Templates, Pluginloader und Plugins sind dem nämlich in der Regel nicht gewachsen und machen, was sie wollen. Die Folge ist ein fürchterlicher Mix von html und Xhtml in den erzeugten (X)html-Dokumenten, Validierung Fehlanzeige.

CMSimple oder CMSkompliziert?

Wenn ich zur Zeit eine valide, standardkonforme CMSimple WebSite auflegen will, kommt folgendes auf mich zu:

1. CMSimple herunterladen und auf dem Webspace installieren
2. Wunschtemplate herunterladen und auf den Webspace übertragen
3. Herausbekommen, ob es sich um ein html- oder ein Xhtml-Template handelt, das wird nämlich auf den Downloadseiten in der Regel nicht erwähnt.
4. Den richtigen Editor finden (FCKeditor4CMSimple natürlich ), herunterladen und installieren.
5. Den Editor auf den richtigen doctype einstellen, dazu muss ich lange lesen und am Ende eine javascript-Datei modifizieren. Hier ist allerdings beim FCKeditor4CMSimple Besserung in Aussicht.
6. Herausfinden, wo es den Pluginloader gibt (im Wiki), herunterladen und auf den Webspace übertragen.
7. Merken, dass der Pluginloader weder nach html noch nach Xhtml validiert und die index.php selber modifizieren (oder hier herunterladen )
8. Plugin herunterladen und auf den Webspace übertragen.
9. Merken, dass die Seiten nun weder nach html noch nach Xhtml validieren und in der Regel den (X)html-Output in mehreren Programmdateien selbst modifizieren ...

CMSimple? Wohl eher nicht. Das dürfte so manchen überfordern und am Ende auf die Webstandards pfeifen lassen. Da ist es dann auch kein Wunder, dass es so aussieht wie es zur Zeit aussieht.

CMSimple wäre DAS:

1. CMSimple herunterladen und auf dem Webspace installieren
2. Wunschtemplate herunterladen und auf den Webspace übertragen
3. Den richtigen Editor (FCKeditor4CMSimple natürlich ) herunterladen und installieren.
4. Pluginloader im Wiki herunterladen und auf den Webspace übertragen.
5. Plugin herunterladen und auf den Webspace übertragen

... und fertig sollte die valide, standardkonforme WebSite sein. Naja, ein paar Inhalte noch ...

So einfach könnte es sein, wenn CMSimple nach EINEM Standard arbeiten würde. So wie es zur Zeit ist, wäre es aber notwendig, dass alle Templates, Plugins, der Pluginloader und alle für CMSimple modifizierten Editoren eine eindeutige Kennzeichnung tragen, z. B.:

- (X)html, wenn das Programm CMSimple ermöglicht, nach beiden Standards validen Quellcode zu erstellen
- Xhtml, wenn das Programm Xhtml-Quellcode ausgibt
- html, wenn das Programm html-Quellcode ausgibt.

Von mir aus auch XH, X und H, aber das muss von oben, von den Machern von CMSimple, entschieden und vorgegeben werden. Das heisst, es müssen Entwicklerdokumentationen für Plugins, Pluginloader, Editoren und Templates erstellt werden, um Ordnung zu schaffen, und die Anwender sollten an irgendeiner Stelle (z. B. in der readme.txt) auf diese Problematik hingewiesen werden.

Programme (Plugins, Pluginloader, Editoren) können schon jetzt so programmiert werden, dass CMSimple je nach Einstellung html oder Xhtml produzieren kann. Ansonsten sollte eine html- und eine Xhtml-Version deutlich gekennzeichnet angeboten werden. Ist gar nicht so schwer, einfach konsequent nach Xhtml entwickeln und dann für die html-Version einen Editor die Endtags entfernen lassen, dann ist das meistens schon erledigt, "suchen und ersetzen" kann jeder Editor. Ich weiss, dass Xhtml mehr ist als "html mit EndTags", aber an den EndTags liegt es doch meistens.

Bei den Templates ist keine (X)html-Version möglich. Im Template wird der doctype eingebunden, nach dem die Seiten validieren sollen. Templates sollten immer in 2 Versionen angeboten werden, deutlich gekennzeichnet (auf den Download-Seiten) unter Angabe des doctypes oder entsprechend sortiert. Auch hier gilt: Nach Xhtml entwickeln und dann eine Kopie auf html zurücksetzen ist einfacher als umgekehrt.

Noch einmal zur Erinnerung:

Das alles wäre nicht notwendig, wenn man sich bei CMSimple auf EINEN Standard einigen könnte, z. B. html 4.01 transitional oder xhtml 1.0 transitional.

[Connie]

Gert,

das sind wirklich prima Informationen und Dokumentationen, die gehören eigentlich ins WIKI, warum immer nur englischer Text dort?

Leider ist Peter Harteg wohl recht "beratungsresistent" in Hinsicht auf die Erstellung von Entwicklungsrichtlinien, aber das ist nicht nur bei CMSimple so, da krankt (fast) jedes CMS dran, am meisten wohl diese unsäglich zähe und mistige Joomla! (mit dem ich leider beruflich zu tun habe...)

da gibt es überhaupt keine Standards... und alles ist ein unüberschaubarer Haufen... da haben wir es doch besser, wenn auch bei CMSimple, wie du ja dokumentierst, noch nicht alles "rund" ist

danke für deine Informationen!

[beate_r]

Hallo Gert,

jetz habe ich alles mal rasch durchgelesen. Vielleicht folgende Gedanken:

Wenn CMSimple schon die Möglichkeit bereitstellt, zwischen HTML und XHTML umzuschalten, dann sollte dies auch konsequent erfolgen. Das bedeutet, dass die Standard-Templates ebenfalls beide Dialekte sprechen können müssen, und von oedit wäre das ebenfalls zu erwarten. Ganz besonders Dinge wie das fehlende ALT-Tag (das ja, wenn ich mich richtig erinnere, zumindest bei HTML nur vorhanden sein muss, aber sogar leer sein darf) sind ja für jemanden, der in den Code eingearbeitet ist, leicht zu vermeiden bzw. zu fixen.

Soweit es also CMSimple selbst angeht, würde ich es als Bug bezeichnen. Und diese Dinge sollten auch die ersten sein, die geradegezogen werden. Danach können dann die anderen Dinge angegangen werden - zuerst mal der Plugin-Loader. Nicht wahr?

Beate

[Gert]

Hallo Ihr zwei,

danke für Eure Kommentare. Ich habe mir erstmal vorgenommen, die Stellen aufzulisten und zu dokumentieren, die für invalide Seiten sorgen. Und das sind einige, es werden noch Beiträge zu Templates, Pluginloader und Plugins folgen, auch wenn sich dann einiges wiederholen wird. Damit das ganze eine in sich geschlossene Dokumentation wird habe ich die Kopfnavigation angelegt, mit der die verschiedenen Beiträge verlinkt sind. Wenn man dann später einen der Beiträge gefunden hat, braucht man die anderen nicht mehr zu suchen.

Ich mache das, weil ich CMSimple mag und die Idee genial finde, nicht, weil ich es schlechtreden will .

Wenn diese Stellen erstmal bekannt und katalogisiert sind kann jeder, der Lust hat, an dem einen oder anderen Problem arbeiten. Trotzdem muss sich einer den Hut aufsetzen, das ist wohl Peter, und Entscheidungen treffen, z. B. ob CMSimple wirklich zwei Markup-Sprachen braucht. Warum ist eigentlich Xhtml dazugekommen? Weil der FCKeditor nur Xhtml konnte? Dieses Problem besteht ja nun nicht mehr. Ich hätte aber auch nichts dagegen, wenn Xhtml der Standard bei CMSimple würde. Nur das Durcheinander wird immer wieder zu Problemen führen.

Zwei Markup-Sprachen sind ein enormer Mehraufwand für Entwickler von Templates und Plugins und eine Fehlerquelle für die Anwender, die davon nix verstehen und falsche Komponenten zusammenstellen. Wenn es aber dabei bleibt, ist eine einheitliche Kennzeichnung aller Templates, Plugins und Editoren notwendig, eben damit der unbedarfte Anwender in der Lage ist, sich passende Templates, Plugins und Editoren zusammenzustellen. Und eben das kann nur zentral "von oben" vorgegeben werden.

Spricht Peter eigentlich deutsch oder kann er es lesen? Ich bekomme das leider nicht in englisch hin

[Holger]

Ich mische mich jetzt auch einmal ein...

Ich habe mir erstmal vorgenommen, die Stellen aufzulisten und zu dokumentieren, die für invalide Seiten sorgen.

Gut so! Eine lückenlose Übersicht des momentanen Standes finde ich sehr hilfreich.

Wenn diese Stellen erstmal bekannt und katalogisiert sind kann jeder, der Lust hat, an dem einen oder anderen Problem arbeiten.

Leider wird es dann aber auch nur unkoordinierte Insellösungen geben.

Warum ist eigentlich Xhtml dazugekommen?

Weil es "Stand der Technik" ist und einige User sich das gewünscht haben.

Zwei Markup-Sprachen sind ein enormer Mehraufwand für Entwickler von Templates und Plugins

Das kann ich nicht nachvollziehen. Für die Plugin-Entwicklung stellt Peter alle nötigen Voraussetzungen zur Verfügung. Problematisch ist nur, dass die wenigsten Plugins auf aktuellem Stand sind.
Alle Quelltexte, die ich mir angesehen habe (zuletzt genizFAQ), konnten mit wenig Aufwand HTML und gleichzeitig XHTML kompatibel gemacht werden.
Leider sind die Entwickler der alten Plugins zwischenzeitlich komplett von CMSimple abgesprungen und andere Leute müssen sich mit der Weiterentwicklung auseinandersetzen.

Zu den Templates:
Ein Template kann als HTML4x oder XHTML Template geschrieben werden. Der "Installer" sollte spätestens an der DTD erkennen wie CMSimple konfiguriert werden muss.
Vom Prinzip her könnte man auch Templates für beide Versionen - unter Zuhilfenahme der CMS-Funktionen - erstellen. Probleme würden allerdings bei den CSS-Dateien kommen.
Aber weshalb der Aufwand? Ein Minimalverständnis der Materie muss man vom "Installer" erwarten dürfen.

Spricht Peter eigentlich deutsch oder kann er es lesen? Ich bekomme das leider nicht in englisch hin

Nein, spricht er meines Wissens nicht.

So viel erst einmal von meiner Seite.

Was mach' ich jetzt nun mit Deinen Beiträgen?
Leider ist das Wiki nur in Englisch. Aber dort würde wohl der richtige Platz für Deine Beitragsserie sein.

Holger

[Tata]

Obwohl es mit der Thema wenig gemeinsam hat... Wäre es wohl möglich eine Kopie von Wiki erstellen für Deutsch und die registrierten Freiwilligešn es übersetzen lassen..? Ich würde gern daran teilnehmen, soweit mein Deutsch reicht. Nach kurzer Zeit könnte dann Wiki auch "deutsch sprechen", oder..?
Falls jemand nur Deutsch/English spricht, könnte eine Regel im Title gegeben werden, die Einträge in beiden Sprachen zu schreiben oder wenigstens zu erwähnen. Z.B.:
Falls nur in einer der Sprachen geschrieben - unter dem Titel die Verlinkung auf die alternative Sprachseite zu geben und auf der alternativen Sprachseite dan nur die ensprechende Stelle reinbauen mit der Verlinkung auf die "AutorsSprachSeite".
Wenn einer dann eine solche leere Seite findet, kann einfach die "AutorsSprachBeitrag" reinkopieren und übersetzen.

Etwa so:
Mein Beitrag
ENGLISH ---> http://www.cmsimplewiki.com/en/....../?My_Entry
Das ist mein Beitrag. Blabla blablabla blablabla.

und nach Verlinkung...

My Entry ---> http://www.cmsimplewiki.com/de/....../?Mein_Beitrag
GERMAN

Zu idealistisch, hm?

[Gert]

Hallo Holger,

ich weiss, meine Beiträge sind lang ... zu lang vielleicht manchmal. Da kann es schon mal sein, dass jemand den Beitrag nur überfliegt und nur die Kommentare richtig liest . Mir geht es zur Zeit mit dem Thema "Google-Browser" so, da interessieren mich eigentlich nur noch die Kommentare bzw. die Diskussionen auf den verschiedenen Blogs.

Oben im Beitrag habe ich ja schon geschrieben, dass man Programme (Plugins, Pluginloader) für (X)html, Xhtml oder html schreiben kann, Templates nur für Xhtml oder html. Es werden noch spezielle Beiträge zu den Themen "Templates" und "Plugins" folgen.

Aber du hast schon recht, wenn die Plugins erstmal mit (X)html durch sind, erstreckt sich der Mehraufwand nur noch auf die Templates.

Der "Installer" sollte spätestens an der DTD erkennen wie CMSimple konfiguriert werden muss ... Ein Minimalverständnis der Materie muss man vom "Installer" erwarten dürfen.

Da hast Du recht, auch ein Radfahrer sollte ein paar Verkehrsregeln kennen . Es geht mir auch eher darum, dass man VOR dem Download erkennt, ob es sich um ein Xhtml oder ein html-Template handelt. Deshalb die Anregung, eine eindeutige Kennzeichnung der Templates schon auf den Downloadseiten zu organisieren.

Damit ich ein Template nicht erst herunterladen und mir die template.htm ansehen muss, um zu beurteilen, ob das Template zum Rest meiner Installation passt. Und damit ein weniger versierter "Installer" sich die passenden Komponenten anhand einer eindeutigen Kennzeichnung zusammenstellen kann. CMSimple trotz 2 Standards.

Gert wrote:
Wenn diese Stellen erstmal bekannt und katalogisiert sind kann jeder, der Lust hat, an dem einen oder anderen Problem arbeiten.

Leider wird es dann aber auch nur unkoordinierte Insellösungen geben.

Der nächste Satz in meinem Kommentar ist aber schon: " Trotzdem muss sich einer den Hut aufsetzen ... ". Das kann Peter sein, muss aber nicht.

Aber auch hier stimme ich Dir zu, es muss "organisiert" werden. Wenn einer eine Lösung erarbeitet hat, sollte die dann an EINER Stelle geprüft werden. Es sollte natürlich auch eine "offizielle" Stelle geben, wo man "zertifizierte" Plugins herunterladen kann, das könnte z. B. das Wiki sein. Aber eigentlich wären die "offiziellen" CMSimple-Seiten der richtige Ort.

Zertifiziert heisst: Das Plugin trägt eine Kennzeichnung ( (X)html, Xhtml oder html bzw. XH, X oder H ). Wir können natürlich nicht beeinflussen, was hier und da so zum Download angeboten wird. Wildwuchs wird es immer geben.

Weil es (Xhtml) "Stand der Technik" ist und einige User sich das gewünscht haben.

Auch so etwas ändert sich schnell. Zur Zeit ist das W3C eher mit der html 5 Spezifikation beschäftigt und lässt meines Wissens Xhtml ein wenig ruhen. Ich sehe das eher als wechselnde Modeerscheinung. Aber, wie gesagt, mir wäre auch Xhtml als alleiniger Standard recht, alles, nur nicht dieses Durcheinander.

Hallo Tata,

es hat durchaus etwas mit dem Thema gemeinsam. Wenn ich mir dieses Forum ansehe (Startseite), dann ist die deutschsprachige CMSimple-Gemeinde die mit Abstand aktivste neben der englischsprachigen Community. Deshalb denke ich, dass ein deutschsprachiger Bereich im Wiki durchaus seine Berechtigung hätte.

Dann würde ich die Beiträge gerne auch im Wiki präsentieren. Es kann aber jeder, der will, meine Beiträge ins englische übersetzen und ins Wiki stellen, gerne auch meinen (X)html-Pluginloader.

[Holger]

Etwa so:
Mein Beitrag
ENGLISH ---> http://www.cmsimplewiki.com/en/....../?My_Entry
Das ist mein Beitrag. Blabla blablabla blablabla.

und nach Verlinkung...

My Entry ---> http://www.cmsimplewiki.com/de/....../?Mein_Beitrag
GERMAN

Warum nicht so?
Vielleicht macht dann ja jemand wirklich eine Übersetzung.

Was sagen die Wiki-Admins dazu?

Holger

[Till]

Vielleicht macht dann ja jemand wirklich eine Übersetzung.

Was sagen die Wiki-Admins dazu?

Holger

CMSimpleWiki.com ist als internationales Wiki geplant und eingerichtet worden. Die Sprache, die in CMSimpleWiki üblich und international z. Z. auch gängig ist, ist "English". CMSimpleWiki.com war nicht gedacht als eine Einrichtung, die nationale Sub-Contents in den jeweilig dazugehörigen Sprachen vertritt - wie es etwa bei einem Forum möglich ist. Der Grund dafür war die Befürchtung, dass sich einige Sprachgemeinschaften ausgeschlossen fühlen könnten. Die Beiträge in CMSimpleWiki sollten deshalb auch in englischer Sprache veröffentlicht werden.

Englisch ist die Sprache, die man in unserer globalisierten Welt einfach anwenden können muss. Sonst kann man in ihr nicht mehr bestehen. Dennoch bleibt es jedem unbenommen, ein eigen-sprachliches CMSimple WIKI aufzubauen.

Till

.

[Holger]

CMSimpleWiki.com ist als internationales Wiki geplant und eingerichtet worden. Die Sprache, die in CMSimpleWiki üblich und international z. Z. auch gängig ist, ist "English". CMSimpleWiki.com war nicht gedacht als eine Einrichtung, die nationale Sub-Contents in den jeweilig dazugehörigen Sprachen vertritt

Stimmt Till.
Ich stell' mir nur einmal die Rubrik "Plugins" vor:
Eine Beschreibung in Deutsch, die nächste in Englisch, Französisch, Dänisch....
es würde nur ein heilloses Durcheinander werden.

Holger