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

On Thu, 06 Sep 2012 23:02:20 +0200, David Singer <singer@apple.com> wrote:

>> CSS allows several selectors per ruleset.
>>
>> ::cue-region(#foo), ::cue-region(#bar) { background:blue }
>
> I think I am failing to explain myself.  I need it to be possible that  
> there is a 'general purpose' spreadsheet that defines "this style gives  
> you a window with a red fill color", "this style gives you a window with  
> a blue fill color" and so on, and then be able to apply those styles to  
> regions, and that two distinct regions with the same fill color have  
> distinct names,
>
> Why?  That general-purpose stylesheet can be embedded, in effect, in UAs  
> that don't implement CSS, so that it can be used -- just like the red  
> text in the example here
> http://www.w3.org/community/texttracks/wiki/608_to_WebVTT#4._CHARACTER_STYLE_CONVERSION

Woah! I was unaware of that wiki page.

Why can't such UAs just support the subset of CSS that they want to  
support, like 'color' and 'background-color'? WebVTT already subsets which  
CSS properties apply, so full CSS support is not needed for WebVTT. Sure,  
you need a CSS parser, but that's pretty easy and even has a state machine  
tokenizer and parser spec now. http://dev.w3.org/csswg/css3-syntax/


>> 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.
>
> Oh boy, I am failing to explain again.  I'm saying yes, the default is  
> 433ms, and for implementations that support full-on CSS, it would be  
> good to have a syntax that provided an explicit transition on the  
> y-position of the lines of a cue, so that, when they moved up, that  
> transition would be used.

OK.

>> Ah. Is that necessary? Does FCC require that to be supported?
>
> 708 positioning is within the region, yes.

OK. Good to know.

>> 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 follow you at all here.  What I suggest seems pretty much like  
> laying out nested divs, doesn't it, and then putting text into those  
> divs?

The WebVTT rendering rules don't really work like "divs" at all.

The rendering rules do things like avoid overlapping. What happens if a  
rollup cue and a positioned cue within a region overlap?

-- 
Simon Pieters
Opera Software

Received on Thursday, 6 September 2012 22:03:26 UTC