Re: php.net css, /stats/

> Just checked back and it looks a lot better! Homepage is fine, > the sidebar still needs one fontsize-increase for me but I can > live with that, and main body is fine. Also, it only happens > with Chimera and Mozilla (running 1.3b), other browsers I > checked (Safari, recent Explorer, Netscape 4.x and unofficial > Phoenix port) all rendered the page perfectly readable. Well, that is just what used to be on php.net, no size decrease was made. > Other small issue, when trying to see how it looked in other > browsers, I pointed Safari at php.net/mail, and it jumped to > http://www.php.net/manual/ja/ref.mail.php which is a very > nice feature except that I don't read Japanese very well :-) > > Safari's language header looked like this: > > Accept-Language: en-us, ja;q=0.07, nl-nl;q=0.86, nl;q=0.79, > de-de;q=0.71, de;q=0.64, fr-fr;q=0.57, fr;q=0.50, it-it;q=0.43, > it;q=0.36, es-es;q=0.29, es;q=0.21, ja-jp;q=0.14, en;q=0.93 > > I'll readily admit it's a mess, but according to the RFC "en" > (at the very end) does have a higher quality value than "ja", > so it should be chosen instead of Japanese, no? Well, the current language parser discards the "q" values, as it expects the languages to be ordered in priority order, which is not the case for Safari... But since you have tried this with Safari, the parsing is at least fixed in the sense, that it interprets different language flavours as the base language itself (en-us = en), so the site works well, with default Safari settings, and displays the en pages for shortcuts. I'll look into this, and implement the feature more closer to the RFC. However, we won't be too close to it, as it says "en-gb" does not imply a fallback to "en", in case "en-gb" is not available, and we will fall back to "en" for our users convinience... Otherwise, I think we will conform to the RFC, as I have time to implement the quality value parsing... Goba