RE: [agenda] 8 September 2011

Frankly, IMO, if we lost the automatic binding we should lose the <reco> in its entirety.  It is only the fact that it is tied to an element in the page that adds its value IMO.  And I think it enables things like a microphone button in the associated text input element on the screen which you certainly don't get with the floating unbound <reco> tag.  It also potentially enables default grammars for user agents that want to have default search/dictation grammars for corresponding elements.

If we wanted to move to all scripting, then I think we'd just want to remove the <reco> tag.  If we want to have the <reco> tag, we should keep the binding.  The binding text is already there so it isn't like this is something that is a large work item or unclear how it would work.

From: Satish S [mailto:satish@google.com]
Sent: Tuesday, September 13, 2011 9:28 AM
To: olli@pettay.fi
Cc: Michael Bodell; public-xg-htmlspeech@w3.org
Subject: 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.