Re: Error event/callback for speech synthesis

I've updated the spec with these changes:
https://dvcs.w3.org/hg/speech-api/rev/18ba5d8b0530

As always, the current draft spec is at:
http://dvcs.w3.org/hg/speech-api/raw-file/tip/speechapi.html

/Glen Shires

On Wed, Oct 10, 2012 at 4:02 PM, Glen Shires <gshires@google.com> wrote:

> I think adding an onerror event is the best option because of: clarity of
> what it means (as opposed to re-purposing onend) and because it's easy for
> an author to assign both onerror and onend to the same function if he
> desires (and to use event.type to distinguish). Therefore I propose the
> following definition. If there's no disagreement, I will add this to the
> spec on Friday.
>
>     interface SpeechSynthesisUtterance {
>       ...
>       attribute Function onerror;
>     };
>
> error event
>   Fired if there was an error that prevented successful speaking of this
> utterance. If this event fires, the onend event MUST not be fired for this
> utterance.
>
>
> /Glen Shires
>
> On Tue, Oct 9, 2012 at 9:10 AM, Dominic Mazzoni <dmazzoni@google.com>wrote:
>
>> There's one case that isn't covered in the speech synthesis spec: what
>> happens if there's an error with a particular utterance that isn't detected
>> at the time when it's enqueued?
>>
>> As an example, suppose the author writes malformed SSML, but the speech
>> is implemented in a remote server so the fact that there was an error isn't
>> discovered until after several utterances have been enqueued?
>>
>> Possible solutions:
>> * Yet another callback, onerror - that indicates that a particular
>> utterance was not and will not be spoken, because there was an error
>> processing that particular utterance. Other utterances are unaffected; if
>> there was another one in the queue after it, it will start speaking next
>> (or error as well).
>> * An extra argument in SpeechSynthesisEvent when an 'end' event is fired,
>> indicating success or failure, along with an error message. The downside is
>> that these arguments wouldn't apply to all callbacks, but the upside is
>> that clients could only listen to onend and be sure to get a callback for
>> every utterance, rather than needing to listen to onend and onerror.
>> * Or, a compromise could be that when there's an error, both onerror and
>> onend get fired, in that order - to make things easier for clients.
>>
>> I think it'd be too limiting to expect that errors could be caught
>> synchronously before the call to speak() returns. Web APIs are moving in
>> the direction of being more asynchronous, and when speech is likely to be
>> implemented remotely, or even locally in a different thread or process, we
>> should let speak() return immediately and have an error callback later.
>>
>> - Dominic
>>
>>
>