This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Full proposal at: https://github.com/marcoscaceres/Locale-Preferences-API/blob/master/proposal.md
arv indicated support on the WHATWG list.
Jungshik indicated a concern, see http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Nov/0351.html ...and bz's response at http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Nov/0352.html
Checked in as WHATWG revision r8458. Check-in comment: Add navigator.getLanguages() and <body onlanguagechange=''> http://html5.org/tools/web-apps-tracker?from=8457&to=8458
Checked in as WHATWG revision r8462. Check-in comment: Change navigator.getLanguages() to navigator.languages http://html5.org/tools/web-apps-tracker?from=8461&to=8462
Note that IDL arrays are on the chopping block. What you probably want to spec here is something along the lines of case B of bug 23682 comment 0. That is, a plain JS Array, with a new one returned if/when the value ever changes. We really need IDL to describe this behavior.
Hixie, is there a place where you explain the rationale regarding the differences what you spec'd and what Mozilla proposed? I found two differences: - .getLanguages() vs .languages; - the event is fired on the global context instead of the Navigator object.
I thought that Arv at Google also had expressed a preference for .languages over .getLanguages(). I don't really see any obvious advantages firing the event on window vs. navigator so I don't have strong preferences.
http://krijnhoetmer.nl/irc-logs/whatwg/20140204#l-1026 Continues in: http://krijnhoetmer.nl/irc-logs/whatwg/20140205
(In reply to Ian 'Hixie' Hickson from comment #8) > http://krijnhoetmer.nl/irc-logs/whatwg/20140204#l-1026 > Continues in: http://krijnhoetmer.nl/irc-logs/whatwg/20140205 Those explains why .getLanguages() changed to be .languages. It doesn't explain why the event moved to the window. It's probably not a big deal but having an object on navigator and the associated event on the global sounds a bit odd to me [1]. Is it because Navigator isn't an EventTarget so far? [1] Actually, my ideal design would have the change event fired on navigator.languages to keep it well isolated but some might say that it's not Web-y enough :(
The event is on Window because that way you can do <body onlanguagechange=""> to handle it. This is consistent with how there's navigator.online, but the events ('online' and 'offline') are fired at Window, so you can do <body ononline="" onoffline="">. Basically I was just following the way we had done it before.
Sounds good to me
(In reply to Ian 'Hixie' Hickson from comment #10) > The event is on Window because that way you can do <body > onlanguagechange=""> to handle it. This is consistent with how there's > navigator.online, but the events ('online' and 'offline') are fired at > Window, so you can do <body ononline="" onoffline="">. Basically I was just > following the way we had done it before. I am not sure how important consistency is in that case. I would prefer to compare the two solutions for their own benefits, not consistency and I'm not convinced that there is a real benefit in being able to have an inline event handler for this while writing code like this is a bit odd: window.onlanguagechange = function() { updateDocumentLangueg(navigator.languages); } This could very quickly lead to bugs where developers would mix |window| and |navigator| and end up listening to the languagechange event on the |navigator| object or try to get the |languages| from the |window|.
Actually I'd argue the opposite. In fact, that's why I argue consistency is important. If we always put the event handler in the same place, authors are much more likely to always get it right, and the wrong case is much more likely to stand out. When we put event handlers sometimes on Navigator, sometimes on Window, sometimes on an the Array or array-like object you get from some method or other... then authors won't know what to look for. Now, if we were arguing about this back in 1995, wondering whether to make the "resize" event fire on Window or on Screen, then I would be totally on your side, and would agree that we should fire change notification events as close to the objects that represent the changed data as possible. But that decision was made long before I was around, and changing it now would not make things less confusing, it would just make things more inconsistent. IMHO.
Marking WORKSFORME since I'm not clear on what needs changing here.