- From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- Date: Thu, 21 Jul 2011 22:15:50 +0200
- To: Chris Weber <chris@lookout.net>
- Cc: public-iri@w3.org
Chris Weber, Thu, 21 Jul 2011 12:53:27 -0700: > On 7/21/2011 12:05 PM, Leif Halvard Silli wrote: >> The actual *problem* in Opera's treatment of Test 1 is not that it >> displays ~/Dürst but that, when you ctrl-click/right-click (or just >> click) the link in order to copy it (or follow it), then you get >> ~/D%FCrst instead of ~/Dürst. > > Why is that a problem? Because 1) it disappoints and confusees the user when upon activating the link, he/she doesn't get to the intended resource. 2) it is also confusing that hover says "ü" while the link says something else. 3) it also means that typing "Dürst" in the URL bar will work better than clicking the link. (And this is a good reason for, when hovering, *display* the URL as "Dürst" rather than percent encoded.) > All browsers tested agree that the path for > this URI is "/People/D%FCrst" as literally typed and as evident by > observing the HTTP request. * When we observe what it "displays" to the user, then they don't agree. > That seems to align with my > understanding of RFC3986 and 3986's treatment of the %FC which if > decoded would be illegal UTF-8. The page in question uses Windows-1252/ISO-8859-1. Question: Would it have made a difference if instead of using ISO-8859-1 based percent encoding, Martin had typed the letter 'ü' directly? Because, if, in a ISO-8859-1 encoded page, hef="D%FCrst" does not work as well as href="Dürst", then I think HTML5 validators in fact should warn against use of percent encoding that isn't UTF-8 based. -- Leif H Silli
Received on Thursday, 21 July 2011 20:16:22 UTC