23517 2013-10-14 22:19:13 +0000 Expose the user's preferred languages in a DOM API 2014-03-19 20:55:34 +0000 1 1 1 Unclassified WHATWG HTML unspecified Other other RESOLVED WORKSFORME P2 enhancement Unsorted 1 ian ian bzbarsky ehsan erik.arvidsson ian jonas marcosscaceres mike mounir stas w3c contributor oldest_to_newest 94727 0 ian 2013-10-14 22:19:13 +0000 Full proposal at: https://github.com/marcoscaceres/Locale-Preferences-API/blob/master/proposal.md 94855 1 ian 2013-10-16 19:48:51 +0000 arv indicated support on the WHATWG list. 96889 2 ian 2013-11-27 23:09:29 +0000 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 99671 3 contributor 2014-02-04 19:37:59 +0000 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 99704 4 contributor 2014-02-04 23:17:05 +0000 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 99732 5 bzbarsky 2014-02-05 02:57:17 +0000 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. 101726 6 mounir 2014-03-02 18:30:27 +0000 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. 101745 7 jonas 2014-03-03 06:43:41 +0000 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. 101765 8 ian 2014-03-03 19:00:33 +0000 http://krijnhoetmer.nl/irc-logs/whatwg/20140204#l-1026 Continues in: http://krijnhoetmer.nl/irc-logs/whatwg/20140205 101794 9 mounir 2014-03-03 22:48:13 +0000 (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 :( 101879 10 ian 2014-03-05 00:00:42 +0000 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. 101881 11 jonas 2014-03-05 00:11:53 +0000 Sounds good to me 101894 12 mounir 2014-03-05 11:17:45 +0000 (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|. 101923 13 ian 2014-03-05 21:12:42 +0000 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. 102674 14 ian 2014-03-19 20:55:34 +0000 Marking WORKSFORME since I'm not clear on what needs changing here.