Re: [css3-lists] [css3-speech] Purpose of the module

On Thu, Jun 2, 2011 at 6:52 PM, Andrew Thompson <lordpixel@mac.com> wrote:
> Indeed you are correct and I have reading comprehension issues :)

> But in that case the spec makes no sense to me.
> If a document is written in Spanish
> but my user agent preferences happen to say I am primarily an English
> speaker would I really want 1 pronounced 'one' rather than 'uno' in the
> middle of an otherwise exclusively Spanish document?

Possibly. I generally ask for consistency. It's clear that the spec
today isn't consistent.

> In most synthesizers switching the language implies switching to a different
> voice, which is jarring (think font substitution but much worse) and
> potentially very expensive in memory and time.

True, although it might cache list values (and probably should as a QoI issue).

> Surely the spec should say either 'in the element's language' or 'with the
> synthesizer's current settings' (meaning with the current voice and
> settings in effect for the list)?

I'd be perfectly happy with this being left as an implementation
choice. It seems like QoI, competition, and user choice.

> I take your point documents are often poorly marked up with lang attributes,
> but if a speech synthesizer has failed to determine the correct language for
> an element then generally speaking the entire output will be unintelligible
> anyway so counters would be the least of your problems.

Indeed. One would hope that a decent UA would let the User inform it
that the document is in some other language. Personally, I'd hope that
a UA would be smarter than a classic http UA is wrt text encodings,
and basically run the document through some of its speech synthesizers
to decide which has the fewest errors and decide "this document
appears to be <x>", that's how charset decoding worked in Gecko when
we still used it (we don't by default these days). But such an
implementation is only viable for desktops or cloud systems and isn't
viable for UAs operating on mobile devices (Opera Mini would be a
"Cloud UA" by this definition).

> fantasia and Charles Belov's other thread on this topic points out this is
> going to be a general problem, eg for Greek lists the English pronunciation
> would be alpha, beta, gamma (though US  and British speakers differ on beta)
> whereas the French would be "/ɑ/, /be/, /se/, ".

> Fundamentally it seems this is best left to the expertise of the synthesizer
> vendors.

Yep

> CSS should simply specify that the generated characters a, b, c or
> 1, 2, 3 should be passed unadorned (*) to the synthesizer to do with what it
> will?
> (*) when I say 'unadorned' I don't mean to preclude the very reasonable idea
> of prefixing the counter qith audio icons or words like 'item' as discussed
> in the other thread. But that's a separate issue from how '1' or 'a' should
> be pronounced.

I think that's my preference. There's nothing wrong with hinting at
document or text language, but it should be up to the UA/speech
synthesizer.

Received on Friday, 3 June 2011 00:35:19 UTC