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 15:08:18 -0700
Message-id: <B050933B-F9A4-4717-B803-287098B38A4F@apple.com>
To: public-texttracks <public-texttracks@w3.org>

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

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

I think the amount of work to support general CSS parsing and so on is not insignificant.  It's like trying to pull one thread of spaghetti off your plate…you very easily end up with all of it in your lap :-(

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

But regions could work pretty much like them (in a restricted sense).

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


At the moment, what I wrote was that when text is addressed into line N of a roll-up region, then the (each) line of arriving text causes the contents of lines N and above to move up a line; can collision still occur?

David Singer
Multimedia and Software Standards, Apple Inc.
Received on Thursday, 6 September 2012 22:08:46 UTC

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