[1]Because Gampelay paages don't specify the encoding used and, moreover, they don't use entities for symbols, as any beginner's guide to HTML suggests.
Can anyone tell me why, no matter how many different versions of Camino I use, or how many different fonts I use in the program, Camino still can't cope with showing price values.[2]encodings for Amazon.co.uk page (they're all actually ISO Latin 1 (ISO-8859-1)) -- but then amazon.co.uk never declares any, either in the response headers or in <meta> tags.
http://www.amazon.co.uk/exec/obidos/ASIN/0563521082/ ref%3Ded%5Fart%5F541563%5Fri%5F1/202-8138292-3690224
[3]
bugzilla.mozilla.org/show_bug.cgi?id=248304), as it might be useful. For we UK users it would be really good to get some traction on this bug, its infuriating to have to remember to switch character encodings every time you think "that price can't be right..." on a site. Worse, less experienced users might get completely confused and give up on the browser.
Well, my 2004082608 (admitted, old) version of Camino displays the above amazon.co.uk (why use the co subdomain at all? In the name of simplicity! Grr..) fine, including pound signs - which it codes correctly as html elements. Camino seems to select *no* text encoding by default.
With regards to the Gameplay site, it is using incorrect HTML, but will display correctly in either ISO Latin 1 or MacOS Roman (but not Unicode - Why wasn't unicode made compatible with the previous ISO standard - they have 65,556 characters at their disposal after all... When loading Gamplay, Camino selects ISO Latin 1 initially, but as soon as it starts "transferring data", the encoding menu displays NO encoding.
How about some coordinated web-dev activism? Everyone on this list write to the webmaster of Gameplay (and probably other sites they run across) and tell them to either specify the text encoding in the correct place in the <meta> tag or Content-type, or use the £ HTML element as specified in the spec. Even better, tell them to use the Unicode encoding, which is probably what everything will end up using in 10 years anyway.
Until the webmasters start cleaning up their encoding-ambigous websites or use Unicode for everything, and since the pound sign is the SAME in both MacOS Roman and ISO-Latin, why not (as a stopgap, admittedly, but one which *might* work) have a preference to automatically select one of these if not default encoding is set by the page, for all .com, .us, .ca, .uk (and all UK country codes), and maybe a few other TLDs. (.net and .org and probably .biz are probably spread outside the 'ISO Latin' world (I don't know which, not being a character encoding expert)
(Or, as a sort of Rube-Goldberg solution, could a simple text-analyzer analyze a page and compare it to letter/bigraph/top-word frequency tables for European languages to make an educated guess as to the correct encoding?)
(<rant> This assumes that HTML is not succeeded by some other protocol-mix in the future - XML/client-side XSLT, or some kind of 'HTML bytecode' for bandwidth reasons perhaps.. *Something* is needed to deal with the 'tables-as-formatting' mess HTML has forced designers into. Getting webmasters to *use* it is and browser-makers [read MS] to *support* it a different matter though.)
Jim Witte
_______________________________________________ Camino mailing list [EMAIL PROTECTED] http://mozdev.org/mailman/listinfo/camino
