Re: Alternative approach to scrolling, with demos

On Tue, Apr 1, 2014 at 10:23 PM, Richard Eyre <rick.eyre@outlook.com> wrote:
> On Mon, Mar 31, 2014 at 11:06 PM, Philip Jägenstedt <philipj@opera.com>
> wrote:
>>
>> Hi Rick! The simple answer is that I still don't know exactly what
>
>
> Hello Philip!
>
>>
>> syntax and API changes I would propose, I'm still trying to figure out
>> precisely what the 608/708 model is at the lowest level and whether or
>> not making that model blend with WebVTT is something I could get
>> behind. However, to support things as in the final absolute.html
>> example, the changes would be something like this:
>>
>>  * Reduce VTTRegion to just scroll and lines
>
>
> How would this work if you want to confine the cues in the region to a
> particular place on the video? If we're removing the width setting then the
> cues within the region could be all kinds of different lengths depending on
> their own settings. How would that be resolved?

My demo resolves it by just setting the same width on the cue that
scroll together. There's nothing that enforces it though.

> Also, one of the use cases for regions was using them to specify a place for
> a set of cues to be displayed on the video regardless if they have a scroll
> setting so that you don't have to write the same syntax for the,
> potentially, hundreds of cues being displayed in that area. It sounds like
> you're planning on removing this feature?

The default settings proposal is somewhat related:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=15024

Since regions isn't just syntactic sugar like default settings would
be, they're not directly comparable, though. I'm assuming that
hand-authoring scrolling captions in a non-live setting is extremely
rare and not worth optimizing for.

>>  * Make scrolling part of the overlap avoidance algorithms
>
>
> I think this is an awesome idea. The algorithm already has a lot of the
> necessary pieces needed to make this happen. It's just a few tweaks to get
> this new behaviour as well.

I'm glad you like it, this is the core thing that I started thinking
about at FOMS that would make regions less special in terms of
rendering.

>>  * Maybe some change to how backgrounds are handled
>>  * A mode of clipping scrolling cues that is more complex that the
>> current spec, which AFAICT is necessary to make cues keep scrolling
>> once the region is full.
>
>
> I think this is a good idea as well. I feel like when and where cues should
> be clipped is a little hard to tell and slightly ambiguous in the current
> spec. Clarification would be good.

Yeah. To be fair my "necessary" is probably an overstatement, I think
if one looks hard enough there's a way to make this work when moving a
group of cues together as well, but that's not where "scrolling is
overlap avoidance" leads to.

>> To avoid later being accused of less-than-fair play, I'll note that I
>> still think it's more sane for this stuff to be done using JavaScript,
>> but I'm hedging my bets in case some browser vendor feel obligated to
>> support these features declaratively. (If so, speak up!)
>
>
> Good thing Firefox is using JavaScript! Chrome JavaScript that is ;-). More
> seriously though, I get what you're saying. I do think scroll up is a good
> feature to have. Especially when we want to start doing live WebVTT, if that
> ever happens.
>
> I think taking a minimal approach like this to modifying the current spec as
> little as possible for region support is a good tradeoff to be compliant
> with 608/708.

I'm still pretty ignorant about 608/708, but I think the most we could
ever aim for is non-pixel-perfect support for a commonly used subset
of those formats. 608 seems to be a stream of commands to control a
state machine, which seems unlikely to always map to text cues with a
start and end time, especially when overlap avoidance is involved.

Philip

Received on Wednesday, 2 April 2014 21:35:17 UTC