Re: Default Display for Voice Tags

On Wed, 26 Jun 2013 01:14:33 +0200, Rick Eyre <rick.eyre@hotmail.com>  
wrote:

>> The DOM construction rules are only relevant for getCueAsHTML(), not for
>> rendering the cues. The rendering rules don't use a DOM at all and don't
>> mention "title" attributes or tooltips.
>
> Okay I see.
>
> What's the reason for having getCueAsHTML() separate from the actual CSS  
> specifications applied to nodes when rendering them as subtitles? Why  
> not just use getCueAsHTML() for subtitles as well?

IIRC Hixie didn't want to define the rendering in terms of a DOM because  
it would be cheaper to create CSS boxes directly, or some such. I'm not  
sure it was a great idea though.

>> The spec is unambiguous, as far as I can tell. The voice isn't rendered  
>> by
>> default, and there's no tooltip.
>>
>> I think the voice is basically supposed to be a semantic version of
>> colored lines, which are commonly used for separating voices. However  
>> it's
>> currently up to the author to provide CSS to get the colors.
>>
>> We could change the spec, of course, if there are good reasons.
>
> My first thought is that there should be some kind of default display  
> for voice text. If it's something that people are going to be wanting to  
> use a lot, which I would think it is, then it would make sense to have  
> some kind of default that people don't have to worry about it.

I don't really disagree. However, if the default is something that people  
*don't* want, then that might be worse, since authors might not figure out  
how to undo it and instead avoid using voices.

-- 
Simon Pieters
Opera Software

Received on Tuesday, 25 June 2013 23:42:34 UTC