Selbst 'denkende' Browser und Editoren verhindern korrektes HTML
Geschrieben von am Noch keine Kommentare
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):
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. ;-(
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 ‐‐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!
Jeena Paradies
ute
ute