Re: SpeechSynthesisCallback

I agree that both proposals are better than callbacks. If speak() doesn't
make a copy of the utterance, then I agree that the IDL that is currently
in the spec is preferable for the reasons Dominic lists. In particular, one
advantage of this over the proposal to make SpeechSynthesis an EventTarget
is that "The target of each event points to the utterance, so clients don't
have to do any work to keep track of which event corresponds with which
utterance."

So I propose to resolve this by simply changing the definition of the
speak() method to omit the copy, specifically:

- Substitute: "appends a copy of the utterance to the end of the queue"
with "appends the SpeechSynthesisUtterance object to the end of the queue"

- Add: "If changes are made to the SpeechSynthesisUtterance object after
calling speak() and prior to the corresponding onend or onerror event, it
is not defined whether those changes will affect what is spoken, and those
changes MAY cause an error to be returned."

If there's no disagreement, I'll update the spec with this on Tuesday.

Glen Shires

On Fri, Oct 12, 2012 at 12:24 PM, Dominic Mazzoni <dmazzoni@google.com>wrote:

> It seems like this decision was a consequence of speak() making a copy of
> the utterance. Could we also consider the alternative?
>
> Suppose we had speak just append the actual utterance to the end of the
> queue, rather than making a copy. It'd be an error to call speak on an
> utterance if it's already in the queue.
>
> The only downside I'm aware of is that clients couldn't reuse the same
> utterance object if they want to enqueue multiple utterances. That doesn't
> bother me much because clients would want different callbacks for each
> utterance anyway.
>
> The advantages I see of using events:
> * It's less for developers to learn. Developers already know how to use
> events, but with new callbacks they'd have to learn everything from scratch.
> * The target of each event points to the utterance, so clients don't have
> to do any work to keep track of which event corresponds with which
> utterance.
> * You can have multiple event listeners attached to an EventTarget.
> * We'd have the option of allowing events to bubble - so for example it'd
> be possible to add a global event listener to the SpeechSynthesis object or
> to the window. I see a lot of reasons why it might be nice to want to
> listen to all speech events rather than needing to add a callback to every
> single utterance.
> * You can set breakpoints for event handlers in the JavaScript debugger
> just using the event name. For callbacks you'd need to find the exact line
> of code.
>
> - Dominic
>
>
> On Thu, Oct 11, 2012 at 6:41 PM, Glen Shires <gshires@google.com> wrote:
>
>> I propose the following change to the SpeechSynthesis IDL to use a
>> callback instead of events. It doesn't change functionality, but does make
>> the IDL more well-defined and conventional. (The current IDL breaks
>> platform conventions, because the speak() method makes a copy of utterance,
>> and thus event.target cannot be properly defined, nor can addEventListener
>> be used in the conventional manner.)  The SpeechSynthesisEvent object is
>> renamed SpeechSynthesisUpdate (because it is no longer an event, but rather
>> a callback).  If there's no disagreement, I'll update the spec with this on
>> Monday.
>>
>>     callback SpeechSynthesisCallback = void (SpeechSynthesisUpdate
>> update);
>>
>>     interface SpeechSynthesis {
>>       ...
>>       static void speak(SpeechSynthesisUtterance utterance,
>> SpeechSynthesisCallback callback);
>>     };
>>
>>     interface SpeechSynthesisUpdate {
>>         enum UpdateType {
>>           "start",
>>           "end",
>>           "pause",
>>           "resume",
>>           "mark",
>>           "boundary",
>>           "error"
>>         };
>>         readonly attribute UpdateType type;
>>         readonly attribute unsigned long charIndex;
>>         readonly attribute float elapsedTime;
>>         readonly attribute DOMString name;
>>     };
>>
>> /Glen Shires
>>
>
>

Received on Saturday, 13 October 2012 07:07:04 UTC