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

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.


>>> Are offline players not willing to implement support for the CSS subset
>>> that
>>> applies to WebVTT?
>>
>>
>> I can't answer that question, since I can't speak for offline players.
>> I do know that I got push-back at VDD. Maybe JB has more to say on
>> this.
>>
>>
>> Actually, I spoke too quickly when I said this is targeted at offline
>> players. Players should indeed support the full WebVTT spec. However,
>> what I meant to say is that this is for conversion tools. For example,
>> owners of caption file collections who want to convert them to WebVTT
>> need to know how to go about styling them. The 608/708 document
>> particularly targets such caption file collection owners who support
>> 608/708 type content (usually SCC files).
>
>
> OK, so it's not expected that the classes do anything without the style
> sheet in some UAs?

No not at all.


> 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'd rather not support line:n% positioning than not supporting
>>> avoid-overlapping. If overlapping is possible, it will happen and that's
>>> bad
>>> user experience.
>>
>>
>> I spoke only with reference to the suggested new region feature. I did
>> not mean to suggest any changes to the existing avoid-overlapping
>> features of cues.
>
>
> Same here.
>
>
>> I'm saying that if an author created a region and expects it to be
>> displayed in a certain location on the video, the browser should not
>> try to move it anywhere, not even to avoid collision with another
>> region, since that is what the author decided to create. The browser
>> should not try to avoid the overlap when it was done intentionally. If
>> the author wants to avoid overlap, they should not use the region
>> feature.
>
>
> 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? Overlap within a region?
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.

Cheers,
Silvia.

Received on Friday, 21 September 2012 11:10:34 UTC