[DISKUSSION] & oder &

R

rico2009

Guest
Hi,

laut w3c ist & in einer URL ein Fehler, der Validator empfiehlt &. Jetzt frage ich mich, ob das in Zeiten von HTML5 und UTF8 noch sinnvoll ist. Ein einfaches & kann jeder Browser inzwischen interpretieren.

Was sollte man in URL z.B. bei Get-Parametern nehmen, & oder &?


Gruß
rico
 
Das ist doch das Trennzeichen für Parameter bei GET Requests. Und wenn es & geschrieben wird nimmt der Browser es nicht als Trenner sondern als Parameter Value. Oder ist das nicht (mehr) so?
 
Und wenn es & geschrieben wird nimmt der Browser es nicht als Trenner sondern als Parameter Value.
Ok, dann versteh ich aber nicht, warum das funktioniert. Wenn ich das als & schreibe funktioniert alles ohne Probleme und ich bekomme auch keine Fehler in der Konsole angezeigt. Nur der W3C Validator meckert eben.

Ich weiß, dass man früher alles als & oder ä schreiben musste. Dann habe ich irgendwo mal gelesen, dass das seit utf8 überflüssig ist.
 
Ein & alleine irgendwo im HTML ist einfach ein Fehler. Mit URLs hat das nichts zu zun. Du musst einfach in HTML jedes & durch & ersetzen - egal wo das steht. So auch in einem src oder href.
Wenn nach dem & aber kein valides HTML-Entity kommt, interpretieren die Browser das hald einfach auch als &.

UTF-8 ändert daran nichts, da HTML immer noch HTML ist... du musst beim Server einfach sagen, welches Charset du verwendest, dann kann der Browser das richtig interpretieren. Mit HTML-Entities verwendest du einfach nur den ANSI Zeichensatz und musst dich nicht darum kümmern, dass auf der Transportebene die nicht ANSI-Zeichen richtig übertragen und am Ende dann richtig interpretiert werden.
 
Nur der W3C Validator meckert eben

Der is ja auch ein Arsch und Spielverderber und meckert bei allem rum...

Ich habe es aufgegeben Zeugs von mir durch den Validator zu jagen, der kennt html5 nicht wirklich.

& ist weiterhin das gültige Trennzeichen für Variablen bei GET-Parametern

& -man achte darauf, dass dieses Zeichen ebenfalls mit einem & beginnt aber mit einem ; endet- ersetzt, solange der URI KEIN ?bla= voran steht, das & was viele als einfaches "und" verwenden würden.
 
Ein & alleine im HTML ist und war schon immer invalide. Das hat in erster Linie nichts damit zu tun, dass ein & das Trennzeichen von GET-Parametern ist.

Jedes HTML, das man erzeugt sollte valide sein. Reduziert die Browserunterschiede und macht das Parsen auch schneller.
 
Jedes HTML, das man erzeugt sollte valide sein. Reduziert die Browserunterschiede und macht das Parsen auch schneller.
Ja, sehe ich genauso. Deswegen sollte man am Ende eines Projektes oder wenn das Projekt einige Zeit läuft ruhig mal ein wenig Zeit in die Code Validierung stecken (auch wenns total nervig ist).

Was die Schnelligkeit einer Seite angeht, so gibt es hier noch ein kleines Tool von Google: http://developers.google.com/speed/pagespeed/insights/ (Bitte nicht alle Anmerkungen von denen ernst nehmen, manches lässt sich einfach nicht umsetzen.)
 
Bitte nicht alle Anmerkungen von denen ernst nehmen, manches lässt sich einfach nicht umsetzen.

Das hier passt auch nicht so ganz: ;)
Ihre Seite enthält 1 blockierende Skript-Ressourcen. Dies verursacht eine Verzögerung beim Rendern Ihrer Seite.
Keine der Seiteninhalte "above the fold" (ohne Scrollen sichtbar) konnten ohne Wartezeiten für das Laden der folgenden Ressourcen gerendert werden. Versuchen Sie, blockierende Ressourcen zu verschieben oder asynchron zu laden, oder laden Sie kritische Bereiche dieser Ressourcen direkt inline im HTML.

Entfernen Sie JavaScript, das das Rendering blockiert:
http://projects.julian-jp.tk/crypt/functions.js
Das ist mal ein seeeeehr passender Kommentar: "Löschen Sie doch einfach mal Ihre einzige JS-Datei mit sämtlichen Funktionen!" :D
Und irgendwie passt dann auch der Kommentar weiter unten überhaupt nicht zu dem Ergebnis von oben...
7 bestandene Regeln
...
JavaScript reduzieren
Ihre JavaScript-Ressource wurde reduziert.
 
Das hier passt auch nicht so ganz: ;)

Das ist mal ein seeeeehr passender Kommentar: "Löschen Sie doch einfach mal Ihre einzige JS-Datei mit sämtlichen Funktionen!" :D
das passt schon, dort steht ja nicht, du sollst deine js-datei(en) löschen, sondern blockende js-dateien entfernen.
also asynchron nachladen über z.b. require oder ans ende verschieben.
da kann man geteilter meinung sein, ob das sinnvoll ist (ich halte das für irrelevant - für normale projekte, bei reinen js-single-page-web-applikationen kann es anders aussehen)
 
das passt schon, dort steht ja nicht, du sollst deine js-datei(en) löschen, sondern blockende js-dateien entfernen.
also asynchron nachladen über z.b. require oder ans ende verschieben.
Ich weiß schon, das stand auch oben. Aber "Entfernen Sie JavaScript, das das Rendering blockiert" hört sich dann doch etwas rabiat an ;)

ich halte das für irrelevant - für normale projekte, bei reinen js-single-page-web-applikationen kann es anders aussehen
Ja, bin ich deiner Meinung.
 
Zurück
Oben