Skip to content

Selbst 'denkende' Browser und Editoren verhindern korrektes HTML

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 WordpressArtikels ü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&#160;&#8208;&#8208;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

Trackbacks

Valide Seiten in Blogs ::: standardkonform nach W3C auch mit Wordpress &raquo; m am :

"" vollständig lesen
[...] Zuweilen nervt der Editor, der manchmal meint besser zu wissen als ich, was ich haben will, siehe dazu auch: Selbstdenkende Editoren [...]

Kommentare

Jeena Paradies am :

Jeena Paradies 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 :

ute 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 :

ute 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.

Kommentar schreiben

Die angegebene E-Mail-Adresse wird nicht dargestellt, sondern nur für eventuelle Benachrichtigungen verwendet.

Um maschinelle und automatische Übertragung von Spamkommentaren zu verhindern, bitte die Zeichenfolge im dargestellten Bild in der Eingabemaske eintragen. Nur wenn die Zeichenfolge richtig eingegeben wurde, kann der Kommentar angenommen werden. Bitte beachten, dass Ihr Browser Cookies unterstützen muss, um dieses Verfahren anzuwenden.
CAPTCHA

Umschließende Sterne heben ein Wort hervor (*wort*), per _wort_ kann ein Wort unterstrichen werden.
Standard-Text Smilies wie :-) und ;-) werden zu Bildern konvertiert.
BBCode-Formatierung erlaubt
Gravatar, Twitter, Favatar Autoren-Bilder werden unterstützt.
tweetbackcheck