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

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

From: David Singer <singer@apple.com>
Date: Thu, 06 Sep 2012 14:02:20 -0700
Message-id: <3CFAB1CB-35A2-4776-BB73-61484FB3B2D1@apple.com>
To: public-texttracks <public-texttracks@w3.org>

On Sep 6, 2012, at 13:02 , Simon Pieters <simonp@opera.com> wrote:

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

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

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

OK, it's a taste call, but it can be a pain to get lexical ordering right.

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

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.

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

708 positioning is within the region, yes.

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

David Singer
Multimedia and Software Standards, Apple Inc.
Received on Thursday, 6 September 2012 21:02:49 UTC

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