- From: Philip Jägenstedt <philipj@opera.com>
- Date: Mon, 5 May 2014 14:16:27 +0200
- To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Cc: "public-texttracks@w3.org" <public-texttracks@w3.org>
On Mon, May 5, 2014 at 1:38 PM, Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote: > On Mon, May 5, 2014 at 9:17 PM, Philip Jägenstedt <philipj@opera.com> wrote: >> On Tue, Apr 8, 2014 at 9:21 AM, Silvia Pfeiffer >> <silviapfeiffer1@gmail.com> wrote: >>> On Sun, Mar 30, 2014 at 4:41 PM, Philip Jägenstedt <philipj@opera.com> wrote: >>>> >>>> == Absolute positioning and scrolling == >>>> >>>> Demo: http://people.opera.com/philipj/2014/03/vttscroll/absolute.html >>>> >>>> Finally, an idea for how scrolling might work with absolutely >>>> positioned cues. You simply position all the cues at the point where >>>> scrolling should begin, and they'll scroll up from there. >>> >>> I've attached a vtt file for you with two "regions". The cues should >>> each get limited to their "region". >>> >>> You can see for yourself how this breaks down with 2 regions present. >>> >>> I think it's quite clear that the concept of cue groups codified in >>> regions is a more appropriate approach than building ad-hoc groups of >>> captions by trying to group them based on them overlapping each other. >> >> For simplicity in the demo, I scrolled all the cues by the same amount >> without checking if they actually overlap, which of course falls apart >> when you have two groups of cues. If implemented properly, I don't see >> that cues scrolling in different parts of the video would be a >> problem. If scrolling implemented as overlap avoidance, the situation >> has to be handled anyway. >> >> How are overlapping regions handled? Not at all AFAICT, some text >> would simply be obscured. > > Indeed, we're not currently handling overlapping regions. I don't > think we need to either, because not even CEA708 has an overlap > avoidance algorithm. Instead, it specifies z-index (called "priority") > so the author can determine which cue sits in front if overlap > happens. > > I don't mind that actually, because it provides an alternative to the > default cues which do overlap avoidance. I do mind. Why should we accept this deficiency just because CEA708 has it? Unless the video is entirely filled with text (unlikely) there will be a way to show all of it without overlap, so why not deal with the situation since WebVTT already has overlap avoidance? Philip
Received on Monday, 5 May 2014 12:16:54 UTC