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: Thu, 06 Sep 2012 22:02:56 +0200
To: "David Singer" <singer@apple.com>
Cc: public-texttracks <public-texttracks@w3.org>
Message-ID: <op.wj8cm6i3idj3kv@simons-macbook-pro.local>
On Thu, 06 Sep 2012 18:23:13 +0200, David Singer <singer@apple.com> wrote:

>> We discussed rollup at the FOMS workshop earlier this week. We looked  
>> at the requirements and concluded that something like #8 or #10 above,  
>> i.e. using named windows (or regions), would address the requirements  
>> best.
>
> Great!  Good to hear we're roughly on the same page.  Sorry we missed  
> FOMS… :-(  Thanks for all these carefully thought-out comments.  Keep  
> them coming!
>
>> What I'd like to do is for the first version try to trim it down to the  
>> absolute minimum and then add more features (if needed) when the first  
>> version has implementation experience.
>
> Sure, some of what I wrote was to make sure there weren't awkward  
> problems left (well, I am sure there are some, there always are, but  
> make sure of obvious edges).
>
>> Which features are "nice to have" rather than "addresses the  
>> requirements"?
>
>
>> For instance, height with number of lines is required but height with %  
>> is, I think, not.
>
> Right, but on the other hand, it's good to have uniform 'vertical  
> addressing' (for lines and regions) and I can't think what else % could  
> mean.

Yeah.

>> Also, the class seems unnecessary if we make the ID selectable from CSS.
>
> We wanted to make sure that CSS was optional and that coloring windows  
> was possible.  Silvia has a blog started on mapping 6/708 to VTT, and in  
> there she suggests that UAs be able to behave 'as if' a 708 style sheet  
> were available.  We don't want two windows with the same ID but we might  
> want two with the same color, so that suggested that the class name  
> should be possible.

CSS allows several selectors per ruleset.

::cue-region(#foo), ::cue-region(#bar) { background:blue }

> (It might be good to allow zero or more class names, in fact, if we want  
> to be able to talk about border, shadow, etc. as separate 'CSS' classes.)

I don't follow, you can apply the same styles for IDs as for classes.

border isn't allowed for cues but outline is.

>> (Cues are selectable from their ID but don't have a class.)
>
> But text can.

Well, elements can. Cues have a background box object for which you can  
change the background color. They only have IDs, not classes.

>> Do we need to support multiple scrolling directions or just up?
>
> I think up is at least the 90% case.

Excellent. That's certainly enough. :-)

> I am not sure if anyone needs horizontal scrolling of vertical text (or  
> even vertical text at all), and I agree, what I sketched for 'in  
> character progression direction' scrolling is well under-specified, so I  
> would prefer leaving that to a future version.  I wrote that paragraph  
> merely to suggest that future specification of 'ticker tape' behavior  
> was not completely excluded by this proposal.

OK.

> There are some text effects that scroll down (e.g. sometimes credits  
> do).  And…what goes up :-)

Credits are usually burned in in my experience, unless they are credits  
for the subtitles themselves, but I have never seen those scroll at all.

>> Do we need to be able to specify the layer or can we rely on implicit  
>> layering from the order of which the regions are defined?
>
> Maybe implicit will do for now,

Excellent.

> but it's probably easier for editors if it can be explicit.  Textual  
> order can be a pain on occasion; but that's what we suggest for two  
> regions with the same explicit or implicit layer anyway.

Let's wait for *authoring* experience with it before adding explicit  
layers. :-)

>> Do we need to be able to change the scrolling speed or can we use just  
>> e.g. 433 ms?
>
> I think allowing an implementation that has CSS to make the transition  
> explicit (using CSS transitions) is acceptable, and in the absence of  
> either the stylesheet or the CSS engine, using 708 timing makes sense.

WebVTT cue positioning doesn't use CSS rendering rules, so it's not  
necessarily the case that it makes sense to support CSS transitions for  
normal cue positioning in the first place. However, maybe cues within a  
region could use CSS rendering rules. But what would we transition? The  
'height' of the newest cue? CSS doesn't support transitioning to height  
'auto' yet, AFAIK.

>> If a cues both specifies a region and uses positioning settings, should  
>> we ignore the positioning settings or ignore the region setting?
>
> I tried to make that clear:  we propose that the positioning setting is  
> *within the region*.  When no region is supplied, the region is the  
> implicit 'whole viewport' region.

Ah. Is that necessary? Does FCC require that to be supported? I imagine  
the scrolling mechanism and the WebVTT positioning rules would have a  
messy interaction. It would also mean we can't use CSS rules for laying  
out the cues within the region, thus maybe can't use CSS transitions.

>> I don't understand this part:
>>
>> "(+) existing files remain completely valid"
>>
>> All proposals do that, surely (since existing files don't use the  
>> proposed syntax)? Or did you mean something else?
>
> No, just that some people had said that introducing regions (windows)  
> would invalidate existing files, and I wanted to say that that was not  
> the case. Nothing more complex than that.

OK.

-- 
Simon Pieters
Opera Software
Received on Thursday, 6 September 2012 20:03:40 UTC

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