W3C home > Mailing lists > Public > public-iri@w3.org > August 2011

Re: How browsers display IRI's with mixed encodings

From: Leif H Silli <xn--mlform-iua@xn--mlform-iua.no>
Date: Tue, 02 Aug 2011 23:03:26 +0300
To: duerst@it.aoyama.ac.jp
Cc: addison@lab126.com, chris@lookout.net, public-iri@w3.org
Message-ID: <8125618557.996793406@xn--mlform-iua.no>
------- Opprinnelig melding -------
> Fra: "Martin J. Dürst" <duerst@it.aoyama.ac.jp>
> Til: xn--mlform-iua@xn--mlform-iua.no
> Cc: addison@lab126.com, chris@lookout.net, public-iri@w3.org
> Sendt: 28/7/'11,  8:26
> Hello Leif, others,
> On 2011/07/28 5:53, Leif H Silli wrote:
>> Phillips, Addison 27/7/'11,  4:13
>>> And an author who inserts u-umlaut and expects it to display as
>>> u-umlaut and send (as %C3%BC in URI form)? Also valid, IMHO.
>> Why did you add 'IMHO'? This should not only be a valid expectation but
>> *the* expected behavior? Did not Martin's test show exactly that for the
>> directly typed IRI?
> I agree that the 'IMHO' is unnecessary.
>> Except a bug in Opera etc. Btw, I tested how some text browsers
>> interprets a directly typed <a href="ü"> in a ISO-8859-1 encoded page.
>> Results: all of them (W3M, Lynx, Links, eLinks, netrik) treated it as
>> %FC (and not as %C3%BC)
> This is what GUI browsers also did some 10 or more years ago. Text-based 
> browsers seem to be behind, probably not only on this issue. I wonder 
> how it may be possible to contact the developers of these browsers (if 
> they are still under development).

Dev happens. E.g. the Japanese W3m was updated this year. Most are opensource products. Do you want a list of the relevant bugzillas?
Leif H Silli  
Received on Tuesday, 2 August 2011 20:08:31 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:14:42 UTC