Re: [heycam/webidl] Extending an interface with boolean attribute with default value false (#880)

> That being said, the API design looks pretty odd. 

That is what we have to work with

[5.2.3 SpeechSynthesisUtterance Attributes](https://w3c.github.io/speech-api/speechapi.html#utterance-attributes) **_text_ attribute** This attribute specifies the text to be synthesized and spoken for this utterance. **This may be either plain text or a complete, well-formed SSML document.** 

emphasis added at last sentence. 

`window.speechSyntheis.speak()` communicates with `speech-dispatcher` where the flag that needs to be set is https://github.com/brailcom/speechd/blob/master/src/server/configuration.c#L487

`GlobalFDSet.ssml_mode = SPD_DATA_TEXT;` 

which when the `ssml` flag is set needs to be set to value

`GlobalFDSet.ssml_mode = SPD_DATA_SSML;` 



> In particular, forcing users to modify the `ssml` and `text` attributes separately could contribute to a temporary state of inconsistency between `ssml` and `text`, which IMO would be poor design. 

Again, that  is what we have to work with. Am banned from WICG for 1,000 years, WICG has no administrative appeals process whatsoever for the bans they impose, therefore it is unlikely will be able to contribute there. Have already filed issues at Chromium and Firefox to support SSML parsing, and at the specification to clarify what you appear to be also describing: ambiguity; lack of clarity; no algorithms to implement.

> (E.g., `text` has been set to SSML text while `ssml` is still false.) 

Not sure gather how that  would be possible. If the default value is text then the user will need to set `ssml` flag explcitily in order to turn SSML parsing on. In theory, the entire specification and API could be re-written, however, am attempting to at least solve the SSML parsing issue first. 

Technically the application could parse whatever is passed to `text`. Look for the elements specified in SSML specification https://www.w3.org/TR/2010/REC-speech-synthesis11-20100907/, parse them if found, otherwise process plain text (including punctuations). Again, an algorithm is required to do that. No such algorithm exists in Web Speech API specification. The specification does not offer guidance as to disambiguation.

>  In response to this, I'd propose making `ssml` settable through the constructor but immutable otherwise. In fact, if I were to design the API, I'd make all of these properties (`text`, `volume`, etc.) readonly; but if that's no longer possible, making `ssml` immutable and only settable through the constructor is the next best thing.

How would that  look in terms of Web IDL? Are there viable alternatives? The goal  of this issue is to have all of the "Web IDL" parts of this procedure ready for immediate implementation if and when there is movement in the specification, and/or implementers (who do what they want anyway) for finally at least implementing SSML for Web Speech API. Then we can move on to emerging technologies in this domain. If we cannot get past implementing what is already technically possible and ready to go, the Web Speech API truly is still as dead as it was when initially filed https://github.com/WICG/speech-api/issues/10.


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/heycam/webidl/issues/880#issuecomment-629566474