Bis vor ~1/2 Wochen wurde dies unterstützt von w3.org-Validierer für HTML5; jetzt gibt es diesen Fehler:
Line 14, Column 163: Bad value http://fonts.googleapis.com/css?family=Open+Sans:400,600,300,800,700,400italic|PT+Serif:400,400italic|Bree+Serif for attribute href on element link: Illegal character in query: not a URL code point.
Was mag der W3C Markup Validator jetzt nicht?
Steveax
URL kodieren die | (Pipe-Zeichen) in der href Attribut (%7C):
Ist dies ein Problem mit der von Google generierten URL oder ein Problem mit dem w3-Validator? Erfordert eine Spezifikation tatsächlich, dass das Pipe-Zeichen im HTML-Attribut codiert wird?
– Mikko Rantalainen
20. September 17 um 6:08 Uhr
@MikkoRantalainen, RFC-1738 stellt fest, dass das Pipe-Zeichen unsicher ist: Andere Zeichen sind unsicher, weil Gateways und andere Transport-Agents dafür bekannt sind, solche Zeichen manchmal zu ändern. Diese Zeichen sind „{“, „}“, „|“, „“, „^“, „~“, „[“, “]“ und „`“.
– Steveax
20. Oktober 17 um 4:37 Uhr
Ich würde erwarten, dass rohes UTF-8 in UTF-8-codiertem HTML gültig ist, ohne andere Zeichen als die für HTML verwendeten zu codieren, z &, " und '. Und diese Sonderzeichen müssten durch HTML-Regeln codiert werden (z & etc). Es wird dann erwartet, dass der Benutzeragent RFC 3987 folgt und den IRI in prozentual codiertes UTF-8 konvertiert, bevor er ihn über HTTP (tools.ietf.org/html/rfc3987).
– Mikko Rantalainen
23. Oktober 17 um 6:30 Uhr
Es gibt zwei Möglichkeiten, dieses Validierungsproblem zu beheben:
URL kodieren die | (vertikaler Balken/Linie) Zeichen in der href Attribut der link Element (wie %7C) :
Ich weiß, dass dies ein älterer Beitrag ist, aber weiß jemand, ob die Trennung einen (Nach-) Vorteil für die Leistung hat <link> Stichworte? Komprimiert Google, wenn mehrere Schriftarten in einem Aufruf vorhanden sind?
– Patrick Moore
7. September 16 um 20:09 Uhr
@PatrickMoore 2 Dinge: ein) Ihre Server-Upload-/Antwortgeschwindigkeit im Vergleich zu Ihrer Endbenutzer-Downloadgeschwindigkeit B) Zeit, um eine weitere Verbindung herzustellen (Server-Antwortzeit vs. Endbenutzer-Antwortzeit), theoretisch, wenn Sie 2 “schwere” Schriftarten laden und Ihre Seite ansonsten schnell lädt, könnte das separate Laden (auf parallele Weise) zu einem schnelleren Laden führen . Aber es hängt wirklich von a) & b) ab
