W3C home > Mailing lists > Public > public-texttracks@w3.org > September 2012

Re: Yet Another Scroll-Up Idea (YASUI) in VTT

From: Simon Pieters <simonp@opera.com>
Date: Fri, 21 Sep 2012 13:18:52 +0200
To: "Silvia Pfeiffer" <silviapfeiffer1@gmail.com>
Cc: public-texttracks <public-texttracks@w3.org>, "David Singer" <singer@apple.com>
Message-ID: <op.wkzgdqrxidj3kv@device-23f190>
On Fri, 21 Sep 2012 13:09:43 +0200, Silvia Pfeiffer  
<silviapfeiffer1@gmail.com> wrote:

> On Fri, Sep 21, 2012 at 8:08 PM, Simon Pieters <simonp@opera.com> wrote:
>> On Fri, 21 Sep 2012 11:02:11 +0200, Silvia Pfeiffer
>> <silviapfeiffer1@gmail.com> wrote:
>>
>>> This is for a particular subclass of users that all want to convert
>>> their scc files from 607/708 to WebVTT. It helps them to create the
>>> conversion software rather than having to come up with the solutions
>>> by themselves. It also provides them with a style sheet that they can
>>> just cut and paste to deliver with their WebVTT file to Web browsers.
>>
>>
>> If it's for conversion software, such software can always include the  
>> style
>> sheet (assuming we add support for inline styles), right?
>
> Yes, absolutely. This is just to make it easier.
>
> The wording in that document may not be sufficient to understand this.
> I'll try to update.

OK.


>> OK, so it's not expected that the classes do anything without the style
>> sheet in some UAs?
>
> No not at all.

Great!

>> I'm getting mixed messages. On the one hand, you say that players should
>> support the full spec. On the other hand, the style sheet is only for  
>> Web
>> browsers?
>
> I think it's conceivable that some players may only implement the
> 608/708 conformant part of it and not support style sheets. They can
> then directly interpret the classes rather than having to go through a
> CSS interpretation. I don't expect any browser to do that. But I can
> envision for example a settop-box player not wanting to support CSS.

I can envision such a situation to end up being problematic for Web  
browsers.


>> The issue at hand was the interaction between a rollup cue and a  
>> positioned
>> cue within a region. The conclusion so far, AFAICT, is that the sanest  
>> thing
>> is to not support % line positioning within regions but still support
>> avoid-overlapping.
>
> Using the "position" cue setting?

No, line. Using %.

> Overlap within a region?

Yes.

> It should not lead to the overlap of lines in a region, but only do an  
> indent.
> I don't think we should allow "size" or "line" position settings
> within a region.

David said line positioning (but only whole lines) within a region is a  
requirement.

-- 
Simon Pieters
Opera Software
Received on Friday, 21 September 2012 11:19:31 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 8 May 2014 13:18:52 UTC