You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It's exciting to see this specification reach this stage. Congratulations to the many contributors.
One aspect of this multiple vs. single attribute debate that I have not seen discussed is "performance" - as in run-time performance - when implementing either approach. After having implemented this draft specification (the single-attribute approach) one thing that I can state for certain is that sniffing/selecting for up to 29 different data-ssml-* attributes on every html element/tag in the DOM is going to be 20+ times worse than sniffing/selecting 1 data-ssml attribute and unpacking that json to tease out the ssml information via a json processor.
From experience, when a TTS player has to rip through the DOM in real time, scanning each element for all of data-ssml-* attributes that the TTS player supports (up to 29!?) before sending the information off to the device's (or player's) speech synthesis API ... well that's going to be a brutal experience full of unwanted pauses unless you are running on some amazing equipment which doesn't exist in the K-12 space where I've done my implementation.
Just my $0.02 cents: don't let style win over substance.
The text was updated successfully, but these errors were encountered:
It's exciting to see this specification reach this stage. Congratulations to the many contributors.
One aspect of this multiple vs. single attribute debate that I have not seen discussed is "performance" - as in run-time performance - when implementing either approach. After having implemented this draft specification (the single-attribute approach) one thing that I can state for certain is that sniffing/selecting for up to 29 different data-ssml-* attributes on every html element/tag in the DOM is going to be 20+ times worse than sniffing/selecting 1 data-ssml attribute and unpacking that json to tease out the ssml information via a json processor.
From experience, when a TTS player has to rip through the DOM in real time, scanning each element for all of data-ssml-* attributes that the TTS player supports (up to 29!?) before sending the information off to the device's (or player's) speech synthesis API ... well that's going to be a brutal experience full of unwanted pauses unless you are running on some amazing equipment which doesn't exist in the K-12 space where I've done my implementation.
Just my $0.02 cents: don't let style win over substance.
The text was updated successfully, but these errors were encountered: