Re: [agenda] 8 September 2011

>
> I am wondering if we really need automatic binding to existing elements
>> or can <reco> just be a standalone new UI element. The main reason I
>> support a <reco> element is for user initiated recognition (without
>> automatically throwing up security prompts on page load).
>>
>
> I don't know what <reco> has to do with security prompts.
> User needs to give permission at some point.
> To me <reco> is mainly just a hint for UA to show some
> UI for starting speech recognition (before starting recognition there
> is some permission UI, if user hasn't given permission in other ways).
> The same could be achieved by
> letting page to style elements in the way they want to show the UI for
> starting speech recognition.
>

The draft has this wording:

"Some user agents like the idea of different consent bars based on the user
clicking a markup button, rather then just relying on scripting."

This is what I meant about security prompts. When using <reco>, the page's
JS doesn't have to call SpeechInputRequest.start() and let the user start it
at their own convenience. The page can definitely have its own button or
similar UI which when clicked calls the .start() method, but the UA will
have no context whether the user clicked on a 'start speech input' button or
'shoot the monkey' button - so it has to ask the user for consent again.

Having a reco element allows the UA to distinguish between the two, know in
advance that the page supports speech input (which can enable a hardware
button or a button in the browser chrome), show a more-in-context
permissions UI (probably close to where the button was or where the user
clicked) and so on.

Hence my thought that we don't need automatic binding of values and we can
treat <reco> as a standalone element for this purpose. Looking at the
current proposal I think it should be possible to extend it later and add
binding support if required.