[Webkit-unassigned] [Bug 69029] Please implement key, char, location and locale properties of KeyboardEvent

Wed Jan 11 16:10:17 PST 2012

https://bugs.webkit.org/show_bug.cgi?id=69029

--- Comment #11 from Alexey Proskuryakov <ap at webkit.org>  2012-01-11 16:10:17 PST ---
> > What I see in MS Word is that it uses the current keyboard input source to make the decision, not the input source an event came from.
> 
> I do not understand the difference.

The difference manifests itself as a bug in MS Word. When you use Character Viewer to input a glyph for straight quote (U+0022), Word converts it to a French quote, mistakenly thinking that the input came from a French source.

A glyph selected in Character Viewer is what the user wants to be inserted verbatim.

> I prefer my UI to be in English, but I often type Hebrew and Russian text.

I think that you misunderstood what system-wide preference I was talking about. There is a preference to select quote style, and it should be honored. I'll attach a screenshot.

The preference may not work perfectly yet (e.g., there isn't even an option for secondary quote style that's appropriate for Russian), but following platform behavior is what editing in a browser should do.

> If OS X does not currently provide any way to determine which keyboard the user is using is a missing OS X feature. When running on a platform that does not expose the keyboard language, WebKit is obviously supposed to leave locale undefined (or was it null). The script can detect that and use less reliable signals, e.g. the user's preference for the UI language.

Leaving such details to web application authors is really undesirable. Whenever possible, we should expose interoperable APIs, and if an API can only be implemented on Windows, it simply shouldn't be exposed.

Note that OS X provides a list of languages that can be typed with each keyboard input source, not a single language per layout. This doesn't meaningfully map to a value that could be exposed by Event.locale, and doesn't lend itself to implementing your use case either.

> > The fact that this property is wanted to implement incorrect behavior appears to be a strong argument against it.
> 
> It is not incorrect. It is heuristic. Generally, it helps a lot more than it hurts. Applications usually provide a way to turn it off for the users who do not like it.

We should be able to do better than provide an unreliable heuristic to address the two use cases that you gave in www-dom thread. A targeted API to educate quotes seems to be in order here.

> As I said before, we are repeating the discussion that took place in www-dom when this was originally proposed for the spec. The consensus at the end of that was to include it in the spec.

I have taken the time to read the thread, and these concerns have not been discussed there.

Getting several experts who frequent a mailing list reach a consensus is an important milestone, but it's perfectly normal to have blocking feedback when it comes to implementation.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.