[whatwg] Implement XMLHttpRequest interface subset onHTMLDocument

Thomas Broyer t.broyer at gmail.com
Wed Dec 10 06:33:10 PST 2008

On Wed, Dec 10, 2008 at 3:01 PM, Anne van Kesteren <annevk at opera.com> wrote:
> On Thu, 30 Oct 2008 08:21:10 +0100, Weston Ruter
> <weston at shepherd-interactive.com> wrote:
>> I have an amendment to my proposal. There was a
>> post<http://ajaxian.com/archives/language-jsonp-service>on Ajaxian
>> today about a "Language JSONP Service" which "calculates the
>> users language based on browser headers". This seems like a terrible
>> workaround since the Accept-Language header is sent from the same browser
>> that the script is running in; a script shouldn't have to make an HTTP
>> request just to find out what the browser's request headers are.
> Did you read what kriszyp wrote in a comment to that post?

Yes, and the answer to his question is: yes, there is a difference.

First, those client-side properties give you one lang code only, which
is clearly not enough for conneg. Let's say I have a GWT application
available in dutch and english, where dutch is the "default language"
(i.e. prefered over english). My navigator.language returns "fr", but
my Accept-Language reads "fr-fr, fr, en". With navigator.language
only, I'd have the dutch version, with Accept-Language I'd have the
english one.

Second, these client-side properties return the UI language, which is
different from the user-preferred language. FF3.1b2 is now available
in many languages but before that, only english was available.
navigator.language in this case would return "en", despite me having
changed Accept-Language to "fr-fr, fr, en".

Thomas Broyer

More information about the whatwg mailing list