On 19/04/13 00:35, Yuan Xulei wrote:
> On 04/18/2013 12:52 AM, Mounir Lamouri wrote:
>> Hi,
>>
>> First of all, thank you for working on this Yuan. The API looks
>> generally good, but I have a few comments.
>>
>> I think it would be good to clearly mention as a UC (Use Case) that this
>> API is there for dealing with text but not to deal with other form
>> controls like <select>.
>>
>> I am not sure what InputMethodManager is there for given that it is not
>> defined. Is that intentional?
>
> Yes, it will defined later.
Please, define at least what would be the purpose.
>> We should not expose it to
>> other platforms anyway, right?
>
> Why not? The desktop and mobile browser may benefit from the API. We can
> provide virtual keyboard to other platforms as well.
I doubt any other platforms will use that API any time soon. Pushing it
to other platforms will increase the exposure of this API. We should
keep it inside Firefox OS to not harm the Web.
>> I'm not a big fan of the 'inputmethodstatechange' event and the
>> 'inputStarted' attribute. First of all, the event name is way too long
>> and developers don't like long name. 'statechange' would be enough.
>
> Shorter and simple event name will be better, but the name should tell
> the developer that it is an IME event.
This event is sent on an object named inputMethodConnection implementing
the InputMethodConnection interface. I believe it should be clear the
event is related to 'inputmethod'.
>> Should we simply
>> have some kind of 'start'/'change'/'finish' events? I actually wonder
>> how the Keyboard application is expected to be created. Shouldn't we
>> make the 'start' event a system message and maybe the 'finish' event
>> should not exist because we might expect the application to be killed at
>> that point? Though, I guess it might be platform dependant.
> The life-cycle of the Keyboard application is:
>
> 1. create
> |
> 2. start <-----
> | |
> 3. change focus an input field
> | |
> 4. finish -----
> |
> 5. destroy
>
> The Keyboard manager will create the keyboard app, which will run as a
> normal app and receive the load event on start-up. When user focus an
> input field, the keyboard app starts text input. During the input, the
> content or attributes of input field may be changed by external
> actions(for example, JS code to clear the text), the keyboard app should
> get notification about the changes. After user finishes input of current
> input field, the keyboard app will wait for the user to focus another
> input field.
>
> So there needs a least two types of events: one fired when user switches
> between input fields, and the other fired when the current input field
> has changed.
I'm not sure if you are agreeing or disagreeing with my proposal. It
seems that 'start', 'modify' and 'finish' would work correctly here,
wouldn't they? Also, 'inputStarted' could be replaced by 'enabled'
maybe? Basically, the keyboard application would know if it is currently
being in use.
> Besides the load and unload events, we may need additional 'start',
> 'change' and 'finish' events.
To be honest, I wonder if the start event is really needed. When the
keyboard application is started, it will be obviously used for a field
so a 'start' event is useless here. If the keyboard got dismissed and is
re-open again without being actually killed, we might as well just send
a 'modify' event. Another option could be to use a system message.
I'm not sure those are great ideas but probably worth thinking about.
>> It seems that replaceSurroundingText could be replaced by replaceWord
>> unless there are some UCs I'm missing. Inserting some text maybe? But I
>> don't see in which case we want to insert more that one character at a
>> time without replacing the current word?
>
> For CJK, the words are not separated by spaces. Each sentence could be
> viewed as a word. replaceWord doesn't work for CJK IME.
> And for Latin, when doing suggestions, we often need to insert some text
> to complete a word, for example, input 'En' and get the suggestion of
> 'English'.
For the latin case, you could simply do replaceWord('English') and that
would replace 'En' with 'English'.
For the CJK case, I do not know anything about that but I wonder how the
keyboard application would be able to know that something is a word if
the UA can't event know that. Are CJK users editing their previously
typed stuff and except to have auto-correction? or that is something
only latin users expect?
>> I feel that setComposingText UCs can be handled by replaceWord. If
>> replaceWord takes by the default the word at the cursor position and we
>> consider that in the following case "foo|" the cursur is position on the
>> word "foo", wouldn't setComposingText be exactly like replaceWord?
>
> Yes, replaceWord or replaceSurroundingText can be used to add a string
> to the input field as well. But the setComposingText is not used to add
> string to the input field. It is used to handle composition events for
> CJK IMEs. For example, to input the Chinese word '我', we will input the
> composing text 'wo' first, then convert it to corresponding Chinese
> character. Also sometimes we use composing text to help us input special
> characters, such as mathematical symbols. For example, the composing
> text of Σ is '\sum'. You can find more about composing text in the
> section "2.1 Compose" of
>
https://dvcs.w3.org/hg/ime-api/raw-file/default/Overview.html#composer-section.
First use case:
- the user types 'wo';
- the keyboard application calls replaceWord('我') which is going to
replace the current word ('wo') with '我'.
Second use case:
- the user types '\sum';
- the keyboard application calls replaceWord('Σ') which is going to
replace the current word ('\sum') with 'Σ'.
Why wouldn't that work?
>> Why do we have getText() instead of always exposing the text inside the
>> field? Is that to improve performance?
>
> Yes, to avoid transfer large text between apps, sine for the content
> editable element, the text content may be several KB. But I think we
> could change it to a sync method without callback.
I think we should keep that async. If the concern is to save
performance, we shouldn't make that synchronous. Also, we should
probably use:
Future<DOMString> getText(start, end);
>> What is the UC for removeFocus() all the keyboards I have seen are
>> dismissed by the system, not by themselves. Is there a particular UI in
>> mind?
>
> removeFocus could support a hide button for the keyboard. If the
> keyboard support full screen editing, it will need a hide button to
> cancel editing.
I've never seen such UI. On Android, I'm able to dismiss a virtual
keyboard from the system UI but I never saw a virtual keyboard offering
a button to dismiss itself even when they are fullscreen.
Do you have specific UIs in mind? Are we planning to implement that in
our UI?
>> advanceFocus() and rewindFocus() are interesting because they seem to
>> apply on the entire document but all the keyboards I have used would
>> make that feature work in a form, not in the document. Is that
>> applicable in the document on purpose?
>
> Yes, applicable in the document, but the app itself could the focus be
> restricted in the forms.
I didn't catch that.
>> Also, this would skip some form
>> elements, which I believe a user wouldn't want.
>
> Yes, non-text field will be skipped. Those methods just follow the
> behaviour of that on android and iOS.
I haven't seen that behaviour on Android. I doubt the iOS behaviour is
that great. I think the form behaviour is way better but we could also
design the API such as a keyboard can implement both.
>> Finally, returnKey will not be added as an attribute on form controls. I
>> do not think this is needed and people will reject that proposal if the
>> use case is a Keyboard API. Actually, what can't we do with the
>> information we already have? If type='search', you can use 'search', if
>> there is no form control after, you can use 'done' or 'go' (you might
>> need to know if the form is submittable for that though). I do not see
>> what 'send' is there for.
>> Anyway, the idea is that we should give enough context to the keyboard
>> so it can show its own UI based on those information.
>
> It will complicate for the keyboard to infer the return key meaning by
> the context. Take the awesome bar of firefox browser for example, if
> user inputs a keyword, the return key will be 'search'; if user inputs a
> URL, the return key will be 'go'. Keybard can hardly determine the
> return keyboard type by the content of the awesome bar.
>
> 'send' is used for sending a mail, SMS, instance message and so on.
The problem is that first of all, you can't expect web pages to use that
magic returnKey attribute just because the Keyboard API uses it. If I
recall correctly, Firefox Android tried to use this and switched back to
guess the label based on the content.
Second of all, standardizing this API is going to be hard. If we have to
rely on a new magic attribute in HTML, this is going to be even harder.
The HTML specification will never accept that change. If we keep that
work self-contained, we increase the chances to have it standardized. If
that happen, we would have a stronger point if we go to the HTML WG and
ask for a new attribute for the virtual keyboards.
Cheers,
--
Mounir