While checking out browser issues on mediawiki due to bad edits like http://en.wikipedia.org/w/index.php?title=Star_Wars_Episode_III:_Revenge_of_ the_Sith&diff=prev&oldid=21694074 it was brought to my attention that lynx and links were problematic. additional research has shown that w3m also suffers from this issue in a way that is in some ways more problematic than how the other browsers suffer. w3m only breaks the edit box text if you actually edit it meaning its not possible to use say a dummy edit box at login time to detect if it is in a unicode safe mode.
The issue seems to be that all the browserts listed convert the text to the users local character set before editing and then convert it back to utf-8 for submission. This leads to breakage of parts of the text that the user did not intend to edit. This is a major issue for sites like wikis where browsers are used to edit existing text. we do have a workaround in place (http://bugzilla.wikimedia.org/show_bug.cgi?id=2676) for IE mac (where there is no hope of a fix) and this workaround could be extended to the text based browsers listed. However i'm reluctant to submit a patch to do that as afaict all of the aformentioned browsers do have modes in which they can edit unicode safely. Unfortunately it doesn't seem possible to detect when they are in such modes. I'm writing this message to ask two questions 1: are there any ways of detecting if a text browser is safe to edit unicode from the requests it makes (i couldn't find any) and if not would you be prepared to agree on a method for indicating you are in a mode that is safe for editing unicode in future versions of your browsers (possiblly by sending accept-charset headers with weighting based on the mode). _______________________________________________ elinks-dev mailing list elinks-dev@linuxfromscratch.org http://linuxfromscratch.org/mailman/listinfo/elinks-dev
