Should sites be able to control Responsive Input Language?

[BenjamP]

If Responsive Input adapts to locale, should it be the browser's locale only or should sites be able to change it? Say you're using a German PC with an English site: should you get German or English keyboard->Responsive Input default mappings?
-From MS Office Team

[rniwa]

Shouldn't this be automatically determined by the UA based on lang attribute?

[BenjamP]

It can be. We just need to decide that it should work that way. Probably with a SHOULD?

[rniwa]

I don't even know if this is worth mentioning in the spec. Keyboard binding may, for example, depend on the screen orientation and other environmental factors. So the only thing UA should do in this regard is to follow the platform convention in my opinion. Perhaps we can just state that?

[NorbertLindenberg]

This may depend on the functionality. For keyboard bindings, I'd agree that they should probably follow platform conventions. What functionality is the MS Office team thinking of?

[BenjamP]

If you're using an English Office account on a German pc on vacation, should you get English or German keyboard shortcuts? Seems like the app should be able to affect this.

[rniwa]

Sounds like the apps can already do that by changing lang attribute on html/body?

[BenjamP]

I think the question is, do we want to suggest what language is used for a given situation so that authors know what they're getting? If an English OS with a French keyboard active and a site with German lang attribute gets French keyboard shortcut defaults on Windows and German defaults on OSX, developers will have to do the mapping themselves to get consistency. Do we want to avoid that situation?

[rniwa]

Are you saying we want to expose the "computed" language the browser is using? Or rather what kind of keyboard the user is using? It appears to me that's exactly the sort of the things device independent events should encapsulate. Authors shouldn't have to manually map key codes depending on the language of the keyboard if we've designed our API right.

[NorbertLindenberg]

Are keyboard shortcuts actually localized? I haven't dealt with this issue in quite some time, but a long time ago at Apple we came to the conclusion that it's a bad idea. See the "what to avoid" section on page 26 of http://norbertlindenberg.com/work/ov20.pdf .

[spocke]

I think localized shortcuts is a bad thing since for example in Sweden Ctrl+F produces bold text in MS Office but in the browser Ctrl+F means Find so it would be an collision. Also it's very confusing to have different shortcuts for different applications a.f.a.i.k Office is the only program that does localized keyboard shortcuts.

[BenjamP]

Hi Spocke- not sure I understand. Do you expect Ctrl+F to be bold in all applications in Sweden? Or are you saying that Ctrl+B should be bold?

[spocke]

Ctrl+B is bold in Sweden for all applications I ever used except MS office they use Ctrl+F instead in the Swedish version so it's some what confusing. So I think it's better to not add that behavior to any spec but let the web applications decide if they want that behavior by adding custom logic for handling shortcuts since it's clearly not a common thing to do so in desktop apps nor should it be that common on the web. Haven't had any requests for us to localize any of the keyboard shortcuts we use in TinyMCE either.

[johanneswilm]

This is another example of how adding formatting input events just overcomplicates things. Given that we have moved this to user land any more, I don't think this applies any more. Please reopen if I am mistaken.