RE: <reco> examples

Following up on what Satish pointed:
If the for attribute is not specified, but the reco element has a recoable
element descendant, then the first such descendant in tree order is the reco
element's reco control.

The examples below without the "for" attribute show the control element as a
sibling rather than a descendant.  The descendant approach matches the
<label> element and seems clearer for both developers and implementers.

Updated Example 1: Using <reco> with a simple field (no id needed either)

<form>
  <reco>
    <input type="text"/>
  </reco>
</form>

-----Original Message-----
From: public-xg-htmlspeech-request@w3.org
[mailto:public-xg-htmlspeech-request@w3.org] On Behalf Of Michael Bodell
Sent: Thursday, October 27, 2011 4:46 AM
To: public-xg-htmlspeech@w3.org
Subject: <reco> examples

I updated a simple reco example in the latest web api document and tried to
add more text about how binding would work to make more concrete the
proposal.  Glen also sent out some reco examples at
http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2011Oct/0048.html
that are well worth reviewing and while it does require flash I quite like
Charles's examples from
http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2011Oct/0055.html
and think it would also be a clear place where markup can solve the task.

I know there has been some discussion the past few weeks about a "Speech
IME" that Satish and some others suggested may negate the need for the
<reco> tag (because the UA will use a Speech IME to speech enable all input
fields) but I fundamentally disagree.  The model of a speech IME in the UA
means the web application author does not have the abiltiy to select either
the grammars nor the recognition service.  In essence the web application
author is at the mercy of the UA for the speech web service.  That is
fundamentally unexceptable.  The web application author needs the control
over choosing which recognition service is in place.

There have been some other discussions about decalative versus procedural
and here to I agree with Glen.  There are a wide variety of users.  Some
only know mark up and want to copy and paste mark up from view-source and
want it to work.  Some know mark up plus very basic JS to write conditions
and handlers in attributes of elements.  Some live and breath a dynamic JS
web where all of their elements are constructed in JS.  We should endevour
to make the easy truely easy (and for many people that means mark up with a
minimum of JS) while leaving the hard possible (and for some things that
does mean you need to go to scripting).

Here is my take on the 8 examples from Glen's original Oct 4 mail
http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2011Oct/0000.html

Example 1: Using <reco> with a simple field

<form>
  <reco/>
  <input id="in1" type="text"/>
</form>

The reco inside a form is automatically is associated with the next input.
The default grammars work with the text and the default assignement is what
we want.  If you wanted to be explicit with the for attribute and also
wanted to make sure the value was always overwritten you could do:

<form>
  <reco for="in1" onresult="in1.value = this.item(0).interpretation"/>
  <input id="in1" type="text"/>
</form>

Note that with the semantics that are in the current proposal these two will
be slighlty different in the case that there was some text already in the
input.  Consider that the user typed "this is speech" and then highlighted
the "is" before speaking and that the interpretation of the speech is the
word "cool".  The first markup would now have the value of the input in1 as
"this cool speech" while the second one would be just "cool".

Example 2: Using CSS to position reco
<form>
  <reco style="position:relative; left:-30px;"/>
  <input id="in2" type="text"/>
</form>

CSS still works the same, although there is no guarentee the UA will work
with the style the way you are expecting as the UA rendering of the reco
element could be producing a button in the chrome that wouldn't be styled
like this.  But in any case, normal CSS rules would work.

Example 3: Overwriting and then submitting the form:
<form action="http://google.com/search" method="get">
  <reco onresult="q.value=this.item(0).interpretation; this.form.submit()"/>
  <input id="q" type="text"/>
</form>

No problem to define the simple 2 JS statements as an attribute on reco.

Example 4: Using <reco> to append continuous text to <input> field <form>
  <reco continuous="true"/>
  <input id="in3" type="text"/>
</form>

Here the smart default binding will be appending to the input anyways.

Example 5: Using <reco> to append continuous text to <textarea> <reco
continuous="true" for="ta"/> <textarea id="ta" cols="50"
rows="2"></textarea>

Again the binding by default appends.

Example 6: Using <reco> to append continuous text to <span> <span id="spn"
style="border:solid red;"></span> <reco continuous="true"
onresult="spn.innerHTML+=this.item(0).interpretation"/>

This time no for (neither implicit nor explicit) but the tag still works
(assuming the UA will do something smart with the default grammar and with
the visual rendering of this reco control).

Example 7: Using <reco> to append continuous text to <div> <div id="dv"
style="border:dashed blue;"></div> <reco continuous="true"
onresult="dv.innerHTML+=this.item(0).interpretation"/>

Same as above.

Example 8: Using <reco> to select from a menu <form>
  <reco/>
  <select id="sel">
    <option value="asparagus">asparagus</option>
    <option value="broccoli">broccoli</option>
    <option value="cauliflower">cauliflower</option>
    <option value="spinach">spinach</option>
  </select>
</form>

Here the reco inside the form will be implicitly set to the select element
in the form, the default assignment will be if the option matches to set the
selectedness to true.  The one caveat that should be handled better would be
the building of the grammar as right now it will just use builtin:select
where it should probably do something like
builtin:select?value=asparagus&value=broccoli&value=cauliflower&value=spinac
h or some other way of communicating the select options.  If I use a little
more non-default behavior I can use the sample grammar Glen did and get:
<form>
  <reco for="sel" grammar="http://example.com/menugrammar.xml"/>
  <select id="sel">
    <option value="asparagus">asparagus</option>
    <option value="broccoli">broccoli</option>
    <option value="cauliflower">cauliflower</option>
    <option value="spinach">spinach</option>
  </select>
</form>

In general I think these type of mark up bindings are both simple and also
quite powerful.  HTML 5 has already gone to the trouble to define a whole
bunch of types, define what are valid text values or not, and say how to
convert from text to the various types.  I think we'd be foolish to not
leverage this.  If we do another pass or two we may get all the bindings
specified perfectly, but even if we don't, I think an editors note in the
final report would be valuable and the working group that fully standardizes
our proposals could complete the details to make sure the i's are dotted and
the t's are crossed correctly.

Received on Thursday, 3 November 2011 08:17:17 UTC