- From: Bjorn Bringert <bringert@google.com>
- Date: Thu, 13 Oct 2011 16:53:40 +0100
- To: Dan Burnett <dburnett@voxeo.com>
- Cc: Olli@pettay.fi, "public-xg-htmlspeech@w3.org" <public-xg-htmlspeech@w3.org>
I can't make it to the teleconf, but I agree with Glen's proposal, including relying on JS for binding. On Thu, Oct 13, 2011 at 4:49 PM, Dan Burnett <dburnett@voxeo.com> wrote: > Yes, I think we should. > > On Oct 13, 2011, at 10:29 AM, Olli Pettay wrote: > >> IIRC, Glen's proposal hasn't been discussed during conf calls. >> (Not very surprisingly I like especially "The reco tag would not explicitly bind to input fields or other tags, >> instead it would use simple javascript to achieve this." part of it.) >> >> Should we discuss about it? It would simplify the API spec. >> >> >> -Olli >> >> >> On 10/04/2011 08:56 PM, Glen Shires wrote: >>> Some of the goals for the <reco> tag that have been discussed in this >>> group are: >>> >>> 1. Make it easy for developers, at least "keep the simple things simple". >>> Even though he was discussing the <tts> tag, many of the considerations >>> that Charles listed also apply to <reco> >>> http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2011Jul/0027.html >>> >>> - Helps the API be more declarative. >>> - Can control features through the standard DOM >>> - Better for standard HTML developers (the main target?) >>> - Provides a standard place to add event handlers. >>> - Allows for visual control (examples: listening indicator, >>> cancel button) >>> - Can support GUI related interaction considerations: focus and >>> visibility. >>> >>> 2. Enable a markup-affordance-based permissions model (click to speak) as >>> Satish describes. >>> http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2011Sep/0019.html. >>> Preventing click-jacking is important if this is to be used for as >>> one of the >>> permissions models. Olli and Satish have described ways to handle >>> this: >>> http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2011Jul/0004.html >>> >>> 3. From the User/UI perspective, the <reco> tag can show a visual indicator >>> (for example, an icon of a microphone) that: >>> - Provides an indication to the user that speech input can be >>> used for these fields. >>> - By clicking on the icon, the user can simultaneously indicate >>> which field he >>> wishes to speak into, and that he grants permission for audio >>> to be captured. >>> >>> I believe the following proposal achieves all of these goals. >>> >>> The <reco> tag would have attributes that mirror most of the attributes, >>> event-attributes and methods of the SpeechInputService. For example: >>> >>> <reco continuous="true" languages="en-AU" grammars="<builtin:datetime>" >>> onresult="processResult()"/> >>> >>> A comma-separated list of items can also be specified, for example: >>> >>> <reco continuous="true" languages="en-AU, en-GB" >>> grammars="<builtin:datetime>, http://example.com/mygrammar.xml"> >>> >>> The reco tag would not explicitly bind to input fields or other tags, >>> instead it would use simple javascript to achieve this. Keeping the >>> "keeping simple things simple" mindset, bindings can be achieved with >>> inline javascript code that developers can easily cut-and-paste along >>> with the rest of the markup. See attached html file for examples. (If >>> you open this html file in Chrome, the examples are functional...click >>> on the microphone icon to see them in action. I've emulated the reco tag >>> using Chrome's current experimental syntax. I've also attached a >>> screenshot in case you don't have Chrome handy.) The use of javascript >>> also provides the flexibility to enable advanced developers to create >>> complex interactions, while keeping the browser implementation and >>> syntax simple. >>> >>> While these examples are not purely declarative in the strict sense, >>> they achieve the spirit of this goal in that developers can easily >>> specify speech input, without having to connect multiple diverse >>> sections of the file together (they don't have to connect the javascript >>> section of the file to the html markup section). Instead, developers can >>> use the common practice of copying snippets of markup to "keep the >>> simple things simple". >>> >> >> > > > -- Bjorn Bringert Google UK Limited, Registered Office: Belgrave House, 76 Buckingham Palace Road, London, SW1W 9TQ Registered in England Number: 3977902
Received on Thursday, 13 October 2011 15:54:20 UTC