Re: Scrolling as overlap avoidance (Re: Alternative approach to scrolling, with demos)

Excellent. Thanks.


On Thu, May 8, 2014 at 7:43 AM, Philip Jägenstedt <philipj@opera.com> wrote:

> On Thu, May 8, 2014 at 4:27 PM, Loretta Guarino Reid
> <lorettaguarino@google.com> wrote:
> >
> >
> >
> > On Thu, May 8, 2014 at 7:09 AM, Philip Jägenstedt <philipj@opera.com>
> wrote:
> >>
> >> Thanks for digging that up, Loretta!
> >>
> >> In this example, there are single cues which are positioned, not
> >> groups of cues, so I don't think regions should be required to achieve
> >> the same result.
> >>
> >> With pre-regions WebVTT this could be reproduced by using the align
> >> setting and a suitably positioned cue box, it seems.
> >>
> >> Note that lineAlign:bottom only controls the alignment of the first
> >> line, so if a cue wraps then lineAlign can't be used to provide an
> >> anchor point for the cue as a whole, in particular you couldn't use it
> >> to avoid overlapping text just below the cue.
> >
> >
> > Then I have seriously misunderstood lineAlign. It isn't clear to me that
> > controlling the alignment of the first line is useful for anything. I
> > thought it positioned the cue based on the bottom of the cue box.  This
> is
> > an issue for multi-line cues, as well.
> >
> > If lineAlign only controls the position of the first line, then regions
> > become necessary for many more use cases.
>
> Sorry, I am the one who misunderstood, it's called "text track cue
> line alignment" internally and I didn't notice which box it was using.
> (This isn't implemented yet, so I'm not the expert I should be.)
>
> What it actually does is adjust the y-position of the box by
> subtracting either half or all of the cue box height, not the first
> line box as I thought.
>
> Philip
>