Selbst testen ~~~HTML,bad <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): ~~~BASH /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.

Selbst testen ~~~HTML,bad <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): ~~~BASH /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...

Selbst testen ~~~HTML,bad <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): ~~~BASH /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“ (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...

Selbst testen ~~~HTML,bad <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): ~~~BASH /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“ (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 (250MB und mehr) wie früher ein ganzes Windows NT...

Selbst testen ~~~HTML,bad <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): ~~~BASH /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“ (wird nicht gemacht), - spekulieren und „trimmen“ (wird von meinem Chromium gemacht) oder eben - nicht spekulieren, sondern „meckern“ (das würde ich tun) in Frage.

Selbst testen ~~~HTML,bad <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): ~~~BASH /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 ein 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 „URL-kodieren“ (wird nicht gemacht), - spekulieren und „trimmen“ (wird von meinem Chromium gemacht) oder eben - nicht spekulieren, sondern „meckern“ (das würde ich tun) in Frage.

Selbst testen ~~~HTML,bad <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): ~~~BASH /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 ein 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: - „URL-kodieren“ (wird nicht gemacht), - „trimmen“ (wird von meinem Chromium gemacht) oder eben - „meckern“ (das würde ich tun) in Frage.

Selbst testen ~~~HTML,bad <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): ~~~BASH /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 Typo mehr „wahrscheinlich“ als „womöglich“ anders reagiert. Die Software (kann auch ein anderer ein 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.