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 12:08:23 +0200
To: "Silvia Pfeiffer" <silviapfeiffer1@gmail.com>
Cc: public-texttracks <public-texttracks@w3.org>, "David Singer" <singer@apple.com>
Message-ID: <op.wkzc39tmidj3kv@device-23f190>
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?

>> 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?

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  

>> 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.

Simon Pieters
Opera Software
Received on Friday, 21 September 2012 10:09:09 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:27:20 UTC