Im Firefox werden alle Doppelpunkte zuweit nach rechts gerückt.. Woran liegt das?
Die Webseite ist in UTF-8 und alle Umlaute sind nicht HTML-kodiert, was ich aber auch gerne so lassen würde. Schließlich klappt es mit IE5-8, Safari, Opera, FF unter OS X...


Woran mag das liegen?

Hier! Ich weiß! Am FF!
Manchmal frage ich mich, ob wir nicht alle nur verarscht werden.
Gerade mit HTML habe ich schon mehr Pferde vor Apotheken kotzen sehen, als es Kübel gibt.
Wir haben einen Disclaimer-Anhänger, der HTML Code einschiebt, was eigentlich eine saubere Sache ist, es gibt aber doch tatsächlich Provider, die es schaffen diesen HTML Code zu ändern...

Hat denn niemand sonst eine Idee?

Standardkonformen Quelltext schreiben vielleicht?
Dass das in den anderen Browsern funktioniert ist eigentlich nur Glück, denn eigentlich gibt es keine Umlaute im UTF-8 Zeichensatz.

Wo kann man sich die betreffende Webseite im Internet mal ansehen? URL?

poste doch mal die entsprechenden Code-Zeilen.
Nicht, dass Du ein bisschen rumgetrickst hast, damit es besser aussieht.

Und bitte keine Leerzeichen und Punkte in Dateinamen verwenden - auch wenn es technisch gestattet ist.

Wie man am Screenshot sieht, ist das überhaupt kein Umlaut-Problem, denn die Umlaute sind ja da.

Deine Installation von Firefox hat ein Font-Problem. Hast Du irgendwelche internen Schrift- oder Schriftglättungseinstellungen von Firefox verändert? Passiert das bei allen Schrifttypen? Wird irgendein Firefox-Plugin verwendet, das Einfluss auf die Schriften nimmt?

Das habe ich ja jetzt erst gerafft. Erst schummeln und sich dann fragen, weshalb die Darstellung nicht passt.

Vor einer Weile hatte ich das Phänomen auch mal.
Schau dir den Quelltext mal in unterschiedlichen Editoren an. In meinem Fall wurde dann ersichtlich, dass da tatsächlich zwei Zeichen waren - der Vokal und die Punkte - jeweils einzeln. Der Firefox hat das dann entsprechend verschoben dargestellt.

Ich hab' das nicht genauer verfolgt, aber in meinem Fall kam das vermutlich von der Bearbeitung in einem Editor eines CMS' mit einem Mac.

Laphroaig:

Bitte poste hier mal einen relevanten Ausschnitt Deines Quelltextes -- den Header von der ersten Zeile an (im Fall von XHTML inkl. des XML-Prologs und der XHTML-Deklaration) und eine beispielgebende Stelle, an der Du Umlaute verwendest. Und der Vollständigkeit halber und zur Info zusätzlich mal die Version Deines verwendeten Firefox.

ex_apple_user_neu:

Wenn er es richtig macht und richtig kodiert bzw. an den richtigen Stellen die Kodierung nennt und das Dokument dann vom Webserver auch als UTF-8 Dokument ausliefern lässt (und nicht z.B. per default-Einstellung des Webservers die Kodierung im Dokument mit standardmäßig z.B. iso-8859-10 überschreiben lässt), muss er keine Entitäten für die Umlaute verwenden, das ist das Schöne an UTF-8. HTML-Entitäten für die Umlaute sind für unseren Sprachraum in HTML nur dann zwingend erforderlich, wenn er eine ISO-Kodierung verwendet, ansonsten schaden sie jedenfalls nicht bzw. sollte man sie in der Tat verwenden, wenn man ansonsten nicht so Bescheid weiß bzgl. Kodierung des Dokuments und Auslieferung desselben durch den Webserver.

Das ist kein Schummeln, sondern völlig korrekt, sofern man den "charset" im Content-Type-Meta-Header deklariert.

Nur für andere Metadaten, die sich im Headerbereich befinden (z.B Suchworte und Zusammenfassungen für Suchmaschinen), sollte man das vermeiden.

Vielen Dank für die vielen Antworten.
Genau das gleiche Phänomen ist auch bei mir. Mein Editor heißt Coda und hat sonst noch nie Probleme mit dem Zeichensatz gehabt. Der Coda-Quellcode ist korrekt, im Gegensatz zu dem Firefox-Quellcode.

Die Seite findet man hier:

Die Umlaute sind völliger Matsch.

Laut Header soll das UTF-8 sein.

Das kleine ä ist als hex 0x61 0xCC 0x88 (ja, 3 Byte!) codiert.

0x61 0xCC 0x88 entspricht jedoch: normales a, und dann ein loses [COMBINING DIAERESIS] (also ein a und die Punkte lose rechts daneben.)


Korrekt wäre 0xC3 0xA4 für ä

=> Firefox malt genau das was bestellt wurde auf den Bildschirm.


Dein Quellcode ist also Matsch.

Eine Jugendfreizeit ohne Alkohol, Drogen, Zigaretten und Laptops? Ich kann verstehen, dass Firefox da nicht mitmachen will

Erstens: mein Firefox 3.6RC1 und mein Camino Nightly (äquivalent etwa zu Firefox 3.0.x) zeigen das Problem nicht, dort sieht alles in Ordnung aus.

Zweitens: Nachlässigkeit oder Absicht, dass der obligatorische XML-Prolog im Quelltext fehlt/weggelassen wurde (<?xml version="1.0" encoding="UTF-8"?> bzw. <?xml version="1.0">)?

Drittens:

Antwort-Header, wie ihn der Webserver aussendet bzw. wie er im Browser ankommt:

Date: Thu, 07 Jan 2010 22:54:40 GMT
Server: Apache/2.2.9 (Debian) mod_ssl/2.2.9 OpenSSL/0.9.8g
X-Powered-By: PHP/5.2.6-1+lenny4
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html

200 OK

Wo ist da die Kodierung zu sehen, ich sehe keine?

Content-Type: text/html;charset=utf-8
Content-Type: application/xhtml+xml;charset=utf-8

Z.B. festzulegen in einer .htaccess-Datei, wie von mir oben beschrieben.

Woher soll der Browser wissen, welche Kodierung er verwenden soll, wenn der Server diesbzgl. nix mit auf den Weg gibt und dazu auch noch der komplette XML-Prolog fehlt (wo die Kodierung auch noch mal drinstehen könnte)?

Im Quelltext steht zwar drin, doch gilt das nur für den Fall, dass das Dokument mit dem Mimetype text/html ausgeliefert wird, also als HTML-Dokument, geparst vom SGML-Parser des Browsers. Wird es als echtes XHTML-Dokument mit dem dazu empfohlenen Mimetype application/xhtml+xml ausgeliefert und vom XML-Parser des Browsers verarbeitet, so wird eine solche Meta-Angabe bzgl. des Content-Types im Dokument nicht verarbeitet bzw. komplett ignoriert.


Und letztens (hat zwar mit dem vorliegenden Problem nix zu tun, aber der Vollständigkeit halber bitte korrigieren):

Der Fehler: Du schachtelst an der betreffenden Stelle so:


Das ist falsch und unzulässig.
Erklärung: Ein p-Element ist ein sog. Blocklevel-Element und erwartet als Inhalt per definitionem inline-Elemente und keine weiteren Blockelemente (das ul-Element ist jedoch, genau wie das p-Element, ein Blockelement und kein inline-Element wie z.B. reiner Text oder ein anderes inline-Element es wäre), siehe (<!ELEMENT P - O (%inline;)*, "The P element represents a paragraph. It cannot contain block-level elements (including P itself).")

Richtig wäre es an der Stelle z.B. so:


Also in dem Fall ein Blockelement nach dem anderen; zuerst das eine (der Absatz <p>), dann das andere (Liste <ul>). Wolltest Du unbedingt schachteln, müsstest Du aus dem Absatz (p-Element) ein div-Element machen, das erlaubt Dir per definitionem die Schachtelung mehrerer weiterer Blockelemente, siehe (<!ELEMENT DIV - - (%flow;)*, "These elements define content to be inline (SPAN) or block-level (DIV)").

Zudem: insgesamt solltest Du Deine Seiten nochmal dem Validator vorlegen, so z.B. auch (Fehler in Das essentielle Zeichen "&" muss mit &amp; als Entität geschrieben/maskiert werden, weil es selber wiederum als Steuerzeichen dazu dient, ggf. andere Entitäten in HTML/XHTML/XML einzuleiten).

Zum Thema sicher auch hilfreich:
W3C XHTML 1.0: 3.1.1. Strictly Conforming Documents und die entsprechenden Hinweise dort zur Codierung
W3C XHTML Media Types , insbesondere der Abschnitt Codierung
Christoph Schneegans: XHTML zum selben Thema

Weniger in Gott vertrauen und mehr in W3C-Validator.

Nein, das stimmt so nicht. Der Code ist korrekt, aber Laphroaig hat in der Tat einen alten Fehler in Firefox gefunden. Der Fehler hat Bug-ID 404848, ist seit mindestens November 2007 bekannt und bisher nicht behoben. Weitere Informationen hier:

Die Darstellung eines ä als kombiniertes diakritisches Zeichen ist in Unicode erlaubt und muss funktionieren. Ob ein Browser das richtig macht, kann man auf dieser Testseite überprüfen:

Die alternative Lösung, die Du angibst, ist richtig und kann dazu benutzt werden, um den Fehler in den Mozilla-Browsern zu umgehen. Das ä muss entweder als Unicode-Zeichen 0xE4 oder in UTF-8 als 0xC3 0xA4 kodiert werden.

Laphroaig verwendet wahrscheinlich einen Editor für den Quellcode, der standardmäßig die Funktion "normalisierte kanonische Dekomposition" für Unicode eingeschaltet hat. Das sollte auf "normalisierte kanonische Komposition" (NFC) umgestellt werden, falls möglich.

Vielen Dank für die guten Kommentare. Die Seite ist nun wieder W3C-konform.
sierkbs Vorschlag mit demhat den FF von der gewünschten Darstellung überzeugt.

Marcel Bresinks Vorschlag kann ich leider nicht umsetzen, da Coda (zumindest in dieser Version) solche Möglichkeiten noch nicht kennt.
Trotzdem. Jetzt geht ja alles. Super Forum!

Wenn ich mich recht erinnere, ist das i.d.R. absichtllich weggelassen, weil es den IE (welche Versionen weiß ich gerade nicht mehr) zuverlässig in den Quirks-Mode schickt.

Richtig. Das betrifft IE6. Im IE7 bereits ist dieser Browser-Fehler behoben, aktuell ist derzeit IE8. Den Rest überlasse ich jetzt Deiner Bewertung.

Gibt es da einen Standard-konformen Workaround? Denn tatsächlich: seit dem XML-Prolog rafft es der IE6 nicht mehr...

Und es kommt noch besser: Im Gegensatz zu Win7 hat der FF unter XP hat weiterhin das Problem mit den Umlauten... Aaaaah! Zum Wahnsinnig werden.

SInd denn auf XP und Win7 die gleichen Firefox Versionen installiert?

Ja. V3.5.7

mach mal neue Screenshots, bitte

Das Bildchen kann man auch hier laden:

Ist schon interessant, das die Übernachtung hinhaut, aber Bettwäsche und Handtücher nicht... Der Screenshot ging leider nicht noch größer

Laphroaig:

Ich kann das Problem bestätigen unter Windows XP/Service Pack3 und Firefox 3.5.7 (läuft in einer VM). Nicht bestätigen kann ich es auf dem Mac (generell mit welchem Browser, dort sieht es generell alles OK aus).
Bestätigen kann ich den Darstellungsfehler auch bzgl. IE8 (keine IE8-Updates installiert) unter obigem Windows XP.

Ja. Und der lautet schlicht: IE6 nicht mehr verwenden -- schließlich existieren sei mehreren Jahren IE7 und IE8.

Abgesehen davon, lesen und beherzigen, was dort zu dem Thema geschrieben steht. Das Dokument ist mit Rücksicht auf den IE6 (was die XML-Deklaration und die Probleme damit angeht) und mit Rücksicht auf IE7/IE8 (was den Mimetype angeht) geschrieben. Gäbe es die Probleme mit diesen Browsern nicht, gäbe es dieses Dokument nicht. Seit der Existenz von IE7/IE8 ist zumindest das Problem mit der XML-Deklaration vom Tisch und somit der Teil des Dokuments einigermaßen obsolet.

Abgesehen davon sehe ich:

Wieso das, wieso wird hier deklariert, dass nachfolgender Inhalt in egnlischer Sprache sei, obwohl er in deutscher ist?


Wieso nicht richtiger

Beide Schreibweisen deshalb: wird das Dokument als text/html geparst, so wird lang="de" gelesen und kommt zum Tragen. Sollte es einmal als "application/xhtml+xml" ausgeliefert werden (und damit als echtes, reines XHTML- bzw. XML-Dokument), so käme "xml:lang='de'" zum Tragen (aufgrund des einleitenden xml:-Namensraumes), ansonsten wird's nämlich geflissentlich überlesen vom Parser. Wird auch unter "A.7. The lang and xml:lang Attributes" des obigen Dokuments erklärt und steht auch in der XHTML Spezifikation unter "C. HTML Compatibility Guidelines - C.7. The lang and xml:lang Attributes" .

Da das Problem Windows XP-only zu sein scheint und dort sogar (zumindest bei mir) bei Firefox UND auch IE8 auftaucht, nähere ich mich ein wenig Marcel Bresinks Vermutung an, jedoch ohne mich dabei auf Firefox zu beschränken. Evtl. ist's ein Problem generell in Windows XP (eben deshalb, weil IE8 den Fehler auch zeigt) bzw. mit den dort installierten Fonts (obig genannter Firefox Bug sagt u.a. Näheres dazu). Meine XP-Testinstallation enthält nicht komplett alle IE- und Betriebssystem-Patches bis zum heutigen Tage, deshalb kann ich nicht sagen, ob evtl. ein solcher Patch den Fehler evtl. auf Betriebssystemebene gefixt hätte bzw. das tut. Deine IE8-Installation unter XP scheint ja fehlerfrei zu sein, meine zeigt den Fehler aber eben auch da, also ist der Fehler offenbar nicht allein auf Firefox begrenzt.

Gerade auch und in diesem Zusammenhang stellt sich die zentrale Frage, ob von Deinem Coda-Editor wirklich die korrekten Umlaute (bzw. deren Codierung auf Bitebene) verwendet wurden (oder ob der verwendete Editor da nicht evtl. Mist gebaut hat), zur Sicherheit bzw. testweise vielleicht einfach mal deren HTML-Entitäten einsetzen (also "&auml;" statt "ä" und "&uuml;" statt "ü")...
Was ist in Deinem Coda-Editor also eingestellt, welchen Zeichensatz er verwenden soll und wie er derlei Zeichen abspeichert? Im Grunde müsste man, wie Knorz es gemacht hat, an den betreffenden Stellen den Quellende tatsächlich mal auf Bitebene genau untersuchen und z.B. mit einem Hexeditor genau nachschauen, ob für die fehlerhaft dargestellten Umlaute überhaupt die korrekten hexadezimalen Werte dort aufzufinden sind (ich habe mir das bislang verkniffen bzw. war zu faul dazu). Bzw. die dort stehenden Werte mal mit den im selben Text korrekt dargestellten Umlauten und ihren Werten vergleichen.

Oder, der Einfachheit halber, den Quellcode mal mit einem ganz anderen Editor be- und nachbearbeiten, der nicht Coda heißt, sondern z.B. Smultron oder TextEdit etc. Und dabei eben die Umlaute mal löschen (zur Sicherheit auch den darauffolgenden und vorangegangenen Buchstaben, um evtl. versteckte Steuerzeichen zu eliminieren und dann die Umlaute neu reinschreiben, meinetwegen sichergehend oder testweise als HTML-Entität, also &auml; oder &uuml;) Dabei Abspeichern als UTF OHNE BOM bzw. Nur-ASCII-Text nicht vergessen.

Interessant ist bei Deinem letzten Screenshot, dass es wohl an der einen Stelle im Text (Bettwäsche und Handtücher) zu einer solchen Fehldarstellung kommt und an anderer Stelle weiter unten z.B. nicht (z.B. an der Stelle Christusträger Bruderschaft - Gästebüro -) — und das in ein- und demselben Browser. Also könnte es was zu tun haben mit den an den betreffenden Stellen tatsächlich verwendeten Zeichen (die nur rein äußerlich aussehen, als seien sie gleich, sich in Wirklichkeit aber möglicherweise unterschiedlich zusammensetzen).

Interessantes Problem!

Ich hab's jetzt hier auf meiner Windowskiste (Windows7/64, FF3.5.7) auch nochmal probiert. Bei der Seitendarstellung fallen jedenfalls keine verschobenen Umlaute auf. Auch nicht in IE5.5/6 mittels IETester. Allerdings fällt da die eine Grafik an der rechten Seite auseinander.
In der einen Hälfte meiner Editoren sind auch die Umlaute unauffällig. Interessant finde ich jedoch, dass der Quelltext scheinbar unterschiedliche Umlaute enthält, wie es mir die andere Hälfte meiner Editoren darstellt (siehe Bild). Verblüffend auch, was passiert, wenn man das "ü" oder die "Lücke" auswählen will (ebenfalls: siehe Bild)...
Bin mal gespannt, ob jemand die eigentliche Ursache herausfindet.

rondimax:

Erstens: und wie sieht dann dein Screenshot aus, wenn man die Wörter "überweisen" und "Christusträger" und "Gästebüro" gegenüberstellt den Worten, die falsch dargestellt werden, also "Bettwäsche" und "Handtücher"?
Wie sehen die entsprechenden Hex-Codes in einem Hex-Editor aus (dann müssten die Unterschiede ja ganz besonders deutlich zu sehen sein aufgrund unterschiedlicher Hex-Codes an den entsprechenden Stellen, obwohl da derselbe Hexcode stehen müsste)?

Warum nicht der Einfachheit halber einfach die betreffenden Umlaute vollständig gelöscht und durch garantiert fehlerfreie und korrekte Umlaute in einem Editor des Vertrauens (in diesem Fall nicht Coda) ersetzt?

Ich hab gerade die vermatschten Umlaute (mit Coda) neu geschrieben und siehe da... es geht! Pff. Das ist doch unglaublich seltsam. Und Coda ist definitiv nicht unschuldig, da auf der Seite noch kein CMS werkelt.

Wie ich schon schrieb: hier wird ja in den Browsern auf der gegebenen Seite nichts verschoben dargestellt.
Und wenn ich den UltraEdit bemühe, sagt der mit, dass das "ü" in "überweisen" ein "cc 88" ist, und das bei den "Handtüchern" ein AFAIK korrektes "c3 bc". Im UltraEdit sieht man nur einen Unterschied, wenn man in den Hex-Modus umschaltet. (Für mich ist das in DEN Feinheiten ja absolutes Neuland.)