> On 18 Jun 2015, at 13:07, Jonny Rein Eriksen <jon...@opera.com> wrote: > > On 18.06.2015 12:01, Florian Rivoal wrote: >> Would it make sense to add an 'auto' value to the lang attribute, explicitly >> instructing the UA to try and guess what language is being entered? >> Remembering what was used last time being a legitimate way to guess, but >> looking at what keyboard you're using, or at the content of what you're >> typing being others. UAs that don't know how to guess would be no worse off >> than today, but for those that do, you'd get the benefits that Jonny was >> talking about, plus any language dependent css being applied correctly... >> >> The mechanics of it aren't hard to polifyll, so maybe leaving it up to >> author provided js is good enough, but a js implementation would have access >> to less information to base its guess on. For instance, if you're using a >> typical mobile on-screen keyboard, it wouldn't know which language the >> keyboard is in, which provides a big clue as to what you're typing. > This is another part of the problem. There is currently no way to set which > keyboard you would like to use on iOS/Android if I understand correctly. We > could maybe get a standardized API which could solve this. Having support in > desktop browsers first for handling spell check better would probably help in > achieving this though.
If a text input field has lang=foo, and your system has a (virtual) keyboard for language foo, I would expect that keyboard to be the one presented to you. Same thing with IMEs (e.g. you have a US keyboard and a Japanese IME installed on your desktop computer, when focusing a text input field with lang=ja, I would expect the IME to be turned on). Not sure if any spec change is needed for that. - Florian
