Gunnar Bittersmann: Währung im Shop wird in Firefox Linux falsch angezeigt

Beitrag lesen

@@TS

<meta http-equiv="content-type" content="text/html; charset=UTF-8" >
ist zwar vorhanden, aber sehr weit unten

Außerhalb der ersten 1024 Bytes. Damit also quasi nicht vorhanden.

und gilt mMn für HTML 4.1.

Und natürlich auch für HTML5 a/k/a/ HTML. Ein HTML-Parser wäre schön blöd (d.h. kaputt), wenn er sagen würde „<meta http-equiv="content-type" content="text/html; charset=UTF-8" > ist mir zu altertümlich; das beachte ich nicht.“

<meta charset="utf-8"> fehlt vollkommen. Ich habe's zumindest nicht gefunden und sollte bei HTML 5 benutzt werden.

Aber nicht zusätzlich zur http-equiv="content-type"-Angabe, sondern anstatt dieser. Es darf nur eine geben.

Und nicht „sollte“ (im Sinne von RFC 2119), sondern „kann“. Weil’s kürzer und einfacher ist.

Das ändert nichts daran, dass <meta http-equiv="content-type" content="text/html; charset=UTF-8" > weiterhin eine korrekte Angabe ist.

Und der Server liefert eine Angabe: Content-Type: text/html;charset=UTF-8

Ich weiß zwar nicht aus dem Handgelenk, ob nicht nach dem Semikolon auch ein Leerzeichen vorgeschrieben ist

Kann man nachlesen. HTTP/1.1 war einst in RFC 2616 beschrieben, der inzwischen „Obsoleted by: 7230, 7231, 7232, 7233, 7234, 7235“ ist.

In RFC 7231 werden wir fündig: 3.1.1.5. Content-Type. Von dort wird man zu 3.1.1.1. Media Type geschickt, worin zu lesen ist:

     media-type = type "/" subtype *( OWS ";" OWS parameter )

Und wenn man nach „OWS“ sucht, landet man schließlich in RFC 7230 3.2.3. Whitespace :

     OWS            = *( SP / HTAB )
                    ; optional whitespace

aber es fehlt und alle anderen mir bekannten Seiten liefern es mit Leerzeichen.

Es fehlt also nicht. Es ist optional.

Die Clients sind da manchmal etwas empfindlich.

Ein Client, der da empfindlich wäre, wäre kaputt.

LLAP 🖖

--
“When UX doesn’t consider all users, shouldn’t it be known as ‘Some User Experience’ or... SUX? #a11y” —Billy Gregory