Selbst testen
<a href= "https://www.bilderhoster.net/users/usr/3wyf1ww1.jpg " target="_blank">
<img src="https://www.bilderhoster.net/users/usr/3wyf1ww1.jpg "border="0" width="120" height="200">
</a>
Selbst anklicken:
https://home.fastix.org/Tests/space-in-uri.html
Das von Rolf aus der Spec zitierte
“The href attribute on a and area elements must have a value that is a valid URL potentially surrounded by spaces.”
sagt (auch mir) nichts darüber, was ein Browser wohl daraus macht: Immerhin sind Spaces (an jeder Stelle!) gültige Zeichen in Dateinamen (Linux):
/tmp$ touch "spaceAm Ende "
ll
-rw-rw-r-- 1 user group 0 Dez 18 09:48 'spaceAm Ende '
Ich hätte das selbe Ergebnis wie Martin vermutet („Da würde also jemand 3wyf1ww1.jpg%20 anfordern.“) - aber zumindest Chromium zeigt nicht dieses Verhalten.
Also: Vor mutigen Aussagen immer testen...
Ich hab den Quelltext dennoch als „bad“ markiert, weil $andereSoftware
auf den Fehler im HTML mehr „wahrscheinlich“ als „womöglich“ anders reagiert. Die Software (kann auch ein anderer Browser sein) könnte ja auch meckern statt spekulierend zu reparieren: Das ist es, was die Spec (einem Ganzgenauheimer wie mir) sagt, wenn diese eine „valide URL“ fordert - und das Ergebnis von solchen Reparaturversuchen vorhersagen zu wollen ist stets „mutig“: Vorliegend käme
- spekulieren und fehlerhafte Stellen „URL-kodieren“ (Martins Vermutung, wird nicht gemacht),
- spekulieren und „trimmen“ (wird von meinem Chromium gemacht) oder eben
- nicht spekulieren, sondern „meckern“ (das würde ich tun)
in Frage. Aber wenigstens wissen wir jetzt, warum die Browser so fett sind (300MB und mehr) wie früher ein ganzes Windows NT. Da dürften zahlreiche Regeln für spekulative Reparaturen etlichen Speicherbedarf haben.