Re: What is the use case for two levels of background colors?

If the concern is that the cue box might be sized too small, why would a
max width setting not solve this? If we put the cue in a bounded region,
wouldn't we end up with the same problem again, unless we again specify a
max width?

After reading this, I am not sure if we may not be overthinking things
here. In general terms, here are the use cases that I see:

1. for non-positioned captions, leave the width at auto, and text align at
centered by default. That should allow the background to grow, and the text
to wrap as much or as little as needed.

2. for most positioned captions, you do not need to set a fixed bounding
box, either, as long as the text anchor is centered on the person. You
expand to the left and right, until you *on one side* hit the edge of the
safe area (which is 95% of the video area). Then you wrap. Doing so would
preserve the symmetry of the positioning to the left and right.

3. for the more rare case of simultaneous positioned cues, you do need to
set left and right of the bounding box. If this, in conjunction with a
suitable anchor, were specified as max width, rather than absolute width,
it still would give the cue room to grow and expand if the font is too
small to run into the width setting.

One thing that I do see as important is that the choice of having a uniform
rectangular background around the screen real estate that the caption
currently uses (and no more) should be a user-overridable setting, and it
must work even if the author didn't set a background area (as in cases #1
and #2). That's what one of the FCC rules we discussed earlier really is
about, and implementing that behavior would, in my view, satisfy the spirit
of it. I believe that this is also what iOS 7 does.

I have to confess that I have never seen the use case that Nigel mentioned
- to leave an empty background on-screen. Nor I am sure that the people I
know would care about this situation. The authoring standards that they
prefer state that for extended portions of silence, you should provide a
"[no audio]" caption.

Christian



On Mon, May 12, 2014 at 4:12 AM, Philip Jägenstedt <philipj@opera.com>wrote:

> Using the cue box as the background box was what I did in
> http://people.opera.com/philipj/2014/03/vttscroll/background.html
>
> However, I've realized that this creates a bit of a tension between
> two goals: in order to "look nice" the background should not be much
> bigger than the cue text, but to give the cue size to grow when the
> font size changes, it should be as big as possible.
>
> This would likely cause authors to create boxes that are too small,
> causing unnecessary line wrapping when the font size increases. Note
> that using a font-relative unit like em doesn't eliminate the problem,
> as illustrated here:
> http://jsfiddle.net/zLB3N/
>
> If the use case was to provide a common background for a number of
> lines (possibly from different cues) simply taking the bounding box of
> those lines and adding some padding would be enough.
>
> However, if the background needs to be unchanging over time the
> algorithm would have to be much more complicated, and I don't know how
> to solve it. Letting the author set a fixed size will result in text
> becoming unreadable in some cases, even if font-relative units are
> used.
>
> Philip
>
> On Sat, May 10, 2014 at 11:20 PM, Christian Vogler
> <christian.vogler@gallaudet.edu> wrote:
> > Maybe I am off-track here, but to me it seems that the cue box
> (especially
> > with an auto width and height) is the logical place for having this
> visually
> > stable background. This should work just fine for pop-on captions, but
> > breaks down with roll-up, because in roll-up, each new line/addition is a
> > separate cue.
> >
> > I'm not sure why this decision was made, to have a separate cue of its
> own
> > for each new roll-up line, other than the desire to employ WebVTT's
> overlap
> > avoidance algorithms. Hypothetically speaking, couldn't the same use
> cases
> > be solved with overflow properties on cue boxes? If so, I don't see any
> need
> > for regions anymore. What am I missing?
> >
> > Christian
> >
> >
> > On Sat, May 10, 2014 at 5:10 PM, Philip Jägenstedt <philipj@opera.com>
> > wrote:
> >>
> >> Thanks David!
> >>
> >> If "visual stability" can be important to the end user, what should be
> >> done in the case where regions aren't used by the caption author? In
> >> 708, is it possible to have captions outside of windows?
> >>
> >> (Note that a VTTRegion background grows and shrinks with the cues
> >> within it, but it sounds like you had something slightly different in
> >> mind.)
> >>
> >> Philip
> >>
> >> On Fri, May 9, 2014 at 10:09 PM, David Singer <singer@apple.com> wrote:
> >> > I am not sure that they are useful together, but don’t they have
> >> > different visual effects?
> >> >
> >> > The background for a region causes a stable rectangular area to be
> >> > painted in that color, no mater what text (if any) is inside it.
> >> >
> >> > the background for text is only drawn around the actual characters.
> >> >
> >> > the first has the advantage of visual stability, while the second
> >> > minimizes the amount of the scene obscured.
> >> >
> >> > On May 9, 2014, at 7:07 , Philip Jägenstedt <philipj@opera.com>
> wrote:
> >> >
> >> >> Hi all,
> >> >>
> >> >> Does anyone know the use case for having two levels of background
> >> >> colors, specifically one background color on the individual lines of
> >> >> text and another on the region/window?
> >> >>
> >> >> The only thing I can think of is that it could make the text more
> >> >> readable for some people. However, if that is the real use case I
> >> >> think relying on regions for it is unacceptable, because the author
> >> >> may not have used regions at all. A robust solution would require the
> >> >> user agent always add that extra layer behind all cues.
> >> >>
> >> >> Thoughts?
> >> >>
> >> >> Philip
> >> >>
> >> >
> >> > David Singer
> >> > Manager, Software Standards, Apple Inc.
> >> >
> >>
> >
> >
> >
> > --
> > Christian Vogler, PhD
> > Director, Technology Access Program
> > Department of Communication Studies
> > SLCC 1116
> > Gallaudet University
> > http://tap.gallaudet.edu/
> > VP: 202-250-2795
>



-- 
Christian Vogler, PhD
Director, Technology Access Program
Department of Communication Studies
SLCC 1116
Gallaudet University
http://tap.gallaudet.edu/
VP: 202-250-2795