Re: [agenda] 8 September 2011

I brought up automatic binding because of the points Olli mentioned and that
we should support all elements that contentEditable is supported. Dropping
automatic binding would make it much less complex.

At least for the original use cases which motivated us to propose a <reco>
markup element, automatic binding is not a hard requirement. But user
initiated recognition is. Note that even with automatic binding, the page
still needs scripting to do things such as submit the form once the user
stops speaking without forcing the user to click on yet another button. So I
don't see why the result handling can be left to script.

Another option to consider is to only allow binding to a small set of
elements, perhaps just to the <input type='text'> tag, though that feels
half baked.

Cheers
Satish


On Tue, Sep 13, 2011 at 8:26 PM, Michael Bodell <mbodell@microsoft.com>wrote:

>  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.****
>
> ** **
>