Re: Absolute region positioning (was Re: Alternative approach to scrolling, with demos)

On Mon, May 5, 2014 at 10:16 PM, Philip Jägenstedt <philipj@opera.com> wrote:
> 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?

I don't see it as a deficiency. I actually think it's a strength
knowing exactly where ones content ends up being rendered on screen
without the browser interfering with positioning. What if I'd like to
author my cues such that they overlap? Maybe it's because it's the
lesser evil than overlapping other content on the screen? I really
think we may be over engineering the overlap avoidance issues if we're
trying to avoid overlap at all cost.

Cheers,
Silvia.

NB: Incidentally, following CEA708 rendering as exactly as possible is
inline with what the US law prescribes, namely identical rendering
between TV and Online. Though, to be honest, there is a line of "rough
identity" that I am prepared to accept and I would call overlap
avoidance an optimisation of sorts, which is why I'm not really
accepting this as an argument.

Received on Monday, 5 May 2014 12:50:48 UTC