Selbst ‘denkende’ Browser und Editoren verhindern korrektes HTML

« Mozilla, Iceape oder Seamonkey geht nicht nach Update - Probleme Der Winter geht ::: neues Design auf miradlo bloggt »

Selbst ‘denkende’ Browser und Editoren verhindern korrektes HTML

29. Februar 2008 ute

Ich kann es nicht leiden. Vor kurzem im Artikel über die Firefox-Versionen hatte ich es ja auf Anhieb gar nicht verstanden, was gemeint war, weil ich es mir nicht vorstellen konnte. Tatsächlich ist es wohl so, dass einige Browser, zumindest der IE (Internet Explorer) selbständig einen des Seitenanfangslinks einfügen. Klar, wenn man das gewöhnt ist und es dann im Firefox nicht geht ist das irritierend, mir sind jedoch Browser lieber, die meinen Code in Ruhe lassen.

Ich erwarte von Browsern, dass sie bitte, danke, genau das interpretieren, was ich vorgebe, nicht mehr, aber auch nicht weniger. Über diesen Seitenanfangslink kann man noch diskutieren, was die Bequemlichkeit angeht, aber ich will nicht, dass mir der Browser das Denken abnimmt. Worüber ich gar nicht mehr diskutieren will, ist ein kürzlich festgestelltes Verhalten von zumindest einigen Browsern (ich habe nicht alle getestet):

Quellcode, Befehle, spezielle Zeichen in HTML nutzen

Ich schrieb einen Artikel in Wordpress, wie meist zunächst mit dem internen Editor, für einige Teile des Artikels über Mozilla & Co. brauchte ich jedoch spezielle Formatierungen. Diesen Teil schrieb ich in Quanta, und fügte den Quelltext in den internen Wordpress-Editor ein.

Zunächst beschloss der Editor, dass er zu entscheiden gedenkt, wann Absätze zu Ende sind und ähnliches. Erst nachdem ich den Quelltext ohne weitere Leerzeilen eingab, behielt er die Formatierungen der Befehlszeilen und des Codes bei.

Nachdem das geklappt hatte, schaute ich mir in der Vorschau das Ergebnis genauer an, und stellte fest, dass es immernoch nicht korrekt war. Einige meiner Konsolenbefehle für Gentoo benötigen zwei Minuszeichen hintereinander, die waren jedoch in den Browseransichten alle weg. Für die Befehle, in den speziell formatierten Bereichen, ließ sich der Editor überreden, das Element <code> auch nach dem Speichern zu behalten und somit zeigten die Browser meine doppelten Minuszeichen an. Bei dem einen Mal im Text war der Wordpress-Editor jedoch stur, ich habe es mit mehreren Möglichkeiten versucht, unterm Strich bleibt ein Ergebnis:
Gebe ich in der Code-Ansicht meine Minuszeichen als Bindestriche in der folgenden Form ein:
<strong>emerge ‐‐search</strong> (strong, um hervorzuheben; um einen Zeilenumbruch im Befehl zu verhindern), dann klappt zunächst alles, um folgendes Ergebnis zu erhalten:
emerge ‐‐search
Wordpress liefert es so aus, in dieser Form verstehen auch die Browser, dass sie keine Minuszeichen wegwerfen sollen, also alles gut.

Nun, fast!

Da kam ich doch auf die Idee, nach dem Korrekturlesen noch zwei, drei Kommas zu ändern und den Entwurf nochmal zu speichern. Damit hatte ich die Dickköpfigkeit des Editors unterschätzt, denn meine Kommas waren schon da, aber mein korrekter Konsolenbefehl war wieder weg. ;-(

Würgaround (von Workaround, Lösung passt ja nicht…)

Wenn ich partout speziellen HTML-Code haben möchte, dann hilft:

Die letzte Aktion vorm Speichern eines Beitrags muss die sein, die den relevanten Code in der Code-Ansicht, nicht in der Ansicht “Visuell” betrifft. Damit behält Wordpress, den Code, wie eingegeben, bei. Sollte man später noch einmal etwas am Beitrag ändern oder ergänzen, dann muss man diesen speziellen Code nach den anderen Änderungen nochmals einfügen.

Als mir das erste Mal ein solches Verhalten auffiel, hatte ich die Einstellung “Wordpress soll falsch verschachteltes XHTML automatisch korrigieren” im Verdacht, die war es jedoch nicht. Denn nach entfernen der Einstellung blieb das Problem bestehen. Leider scheint es das Problem für alle Code-Teile zu geben, die man in der Codeansicht einfügt, falls sie nicht genau so sind, wie der Editor sie erwartet.

Bei Artikeln mit solchen Bestandteilen achte ich darauf, diese zum Schluss nochmals anzupassen und ich prüfe bei solchen Artikeln nach dem endgültigen Speichern, ob der Code nach W3C noch korrekt ist. Wenn die Optik der Vorschau und der Validator einer Meinung sind, dann passt es.

Ergänzung vom 6. April

Für ein anderes Problem habe ich einen weiteren Würgaround gefunden. Der Editor verschluckte sich, wenn ich innerhalb einer Tabelle Text und Listen hatte, es fehlte jeweils das beginnende “p” des Paragraphs. Gibt man dieses von Hand an, dann klappt es nur bei direktem Speichern aus der Code-Ansicht. Beim nächsten Bearbeiten ist es wieder weg.

In vielen Fällen ist das nicht so schlimm, bei Beiträgen, die sich nicht ändern, lässt es sich damit umgehen. Bei Artikeln, wie dem Glossar, an denen ich immer wieder ergänze, ist das jedoch nicht nur ärgerlich, sondern schlicht unbenutzbar.
Tiny MCE bei Wordpress zeigt das Verhalten alles zu entfernen, was es für überflüssig hält, damit werden z.B. absichtlich leer gelassene alt-Attribute schlicht entfernt.
Die Umgehung ist kein Traum, aber praktikabel, ich nutze keine leeren Attribute, Tags usw.
Ins alt-Attribut schreibe ich also etwas, was noch nicht in der Beschreibung steht. Wenn ich ein p-Tag erzwingen will bekommt es jetzt eine Klasse “help”, damit bleibt es erhalten.

Fazit

Dieses Verhalten ist ein weiterer Versuch der Hersteller von Software, hier von Browsern und Editoren, alles zu tun, damit diejenigen, die mit der Software umgehen es möglichst leicht haben. Leider scheitern daran dann oft diejenigen, die genau wissen, was sie tun und die das nicht, wie gewünscht, lösen können:

In diesem Fall ist es einerseits das Browserverhalten, was aus doppelten Minuszeichen eins macht, da ja nicht angezeigt werden soll, dass der Autor sich vertippt hat. Andererseits die Editoren, die es auch in der Codeansicht nicht dem Autor überlassen, dafür zu sorgen, dass das Ergebnis korrekt ist, sondern den, von Hand eingegebenen, Quellcode noch ändern.

Wie erwähnte ich bereits zu Beginn: Ich kann es nicht leiden.

3 Reaktionen zu “Selbst ‘denkende’ Browser und Editoren verhindern korrektes HTML”

Jeena Paradies Am 15. März 2008 um 21:01 Uhr
Afair nutzt WordPress TinyMCE, und der lässt ziemlich viele Custom-Einstellungen zu. Guck sie dir mal an, sicher findest du die richtige um diese Lästigkeiten auszuschalten.
ute Am 16. März 2008 um 16:16 Uhr
Ja, es ist TinyMCE und ja, es lässt sich einiges anpassen.

Nach deiner Anregung habe ich es auch nochmal versucht und habe mir den Button HTML eingebaut, der alle HTML-Tags anzeigt, in der Hoffnung, dass dieser das Problem behebt. Leider hilft das noch weniger, weil sich der Beitrag dann nicht in dieser, sondern nur in der WYSIWYG-Ansicht speichern lässt.

Ich fürchte, sobald man einen Beitrag in dieser Ansicht öffnet, wird sich an dem Problem nichts ändern lassen, außer man bastelt tiefer im Quellcode in den regulären Ausdrücken, die sich darum kümmern. Zumindest im Moment ist es mir das nicht wert.

Durch deinen Kommentar sah ich dann, dass ich wohl mal wieder vergessen hatte, zuletzt in Code-Ansicht zu speichern, das habe ich jetzt behoben.
ute Am 6. April 2008 um 14:31 Uhr
Die Ergänzung eingefügt, zu dem dass TinyMCE in Wordpress noch das ein oder andere selbst entscheidet und wie sich das umgehen lässt.

miradlo bloggt