At 1:19 pm -0500 25/9/04, Jim Witte wrote:
Well, my 2004082608 (admitted, old) version of Camino displays the above amazon.co.uk fine, including pound signs - which it codes correctly as html elements. Camino seems to select *no* text encoding by default.
You'll find the problem is intermittent. Some times the
page will be fine, other times it will not be. Try
visiting one of their "new and used" pages, though, (here's
one at random:
http://www.amazon.co.uk/exec/obidos/tg/detail/offer-listing/-/B0000A9YZY/all/) and you'll find Camino almost always gets it wrong
(look down the left side of the page). Camino has been like this since
about last December.
(why use the co subdomain at all? In the name of simplicity! Grr..)
Sorry, but that's just the way we do things in the UK. Or
do you regard the UK as so tiny it isn't worthy of subdivision into
commercial (.co), academic (.ac) governmental (.gov) organisational
(.org) etc subdomains? Pity we own almost half of the class B
networks in the world then... :-p
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.
I'd agree, but I'm having to lie down at the moment after banging
my head against several hundred webmasters already today for sloppy
coding...
for all .com, .us, .ca, .uk (and all UK country codes),
erm... there is only one UK country code: .uk
:)
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)
Truth is, you can pick any Western font and Camino will the
render the pound (and the numbers that follow it) without error.
The problem, as you say, is that Camino is choosing NO encoding.
Firefox doesn't exhibit this behaviour because it lets you choose a
default encoding to use (and defaults to ISO-8859-1 if you don't).
Section 3.7.1 of RFC2616 (the definition of the HTTP/1.1
protocol--full document is at http://www.ietf.org/rfc/rfc2616.txt
should you desire some light reading) has this to say on character
encoding:
When no explicit charset
parameter is provided by the sender, media subtypes of the "text"
type are defined to have a default charset value of "ISO-8859-1" when
received via HTTP. Data in character sets other than "ISO-8859-1" or
its subsets MUST be labeled with an appropriate charset value.
Which is frequently interpreted (incorrectly -- see 5.2.2 of the
html specs http://www.w3.org/TR/html401/charset.html#h-5.2.2 ) by web
designers as an invitation to omit the encoding information if
ISO-8859-1 is in use. BUT, while web designers are not free to
make this assumption, it is fair to say that web client designers
SHOULD apply this simple rule:
any page delivered as text/html without a specified character encoding should be treated as encoded in ISO-8859-1.
Again, note 3.4.1 of RFC2616:
Some HTTP/1.0 software has interpreted a Content-Type header without
charset parameter incorrectly to mean "recipient should guess."
So: clients shouldn't guess. They should enforce
ISO-8858-1. If Camino isn't doing, a bug should be raised.
(<rant> This assumes that HTML is not succeeded by some other protocol-mix in the future - XML/client-side XSLT,
Sorry, Jim... it's already here (as well you know!) BUT...
the encoding rules for XML are much more strict and webmasters won't
get away with being sloppy once they start using it. heh heh
heh. The world could become a better place yet! :)
-Steve
_______________________________________________ Camino mailing list [EMAIL PROTECTED] http://mozdev.org/mailman/listinfo/camino
