miradlo bloggt
« 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&#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ä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.

Ähnliche Beiträge

Der Beitrag wurde am Freitag, den 29. Februar 2008 um 00:00 Uhr veröffentlicht und wurde unter tipps, web, wordpress abgelegt.

Dir gefiel der Artikel? Dann abonniere doch den RSS Feed oder abonniere die Beiträge per E-Mail. Du kannst die Kommentare zu diesem Eintrag durch den RSS 2.0 Feed verfolgen. Du kannst einen Kommentar schreiben, oder einen Trackback auf deiner Seite einrichten. Add to Technorati Favorites

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

Kommentar schreiben

Dein Kommentar

XHTML 1.0 strict: Folgende Tags könnt ihr verwenden: <a href="" title=""> <em> <strong>

zum Seitenanfang