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

To me, it boils down to groups of cues. If we don't need to support groups
of cues, then I don't see the need for regions, either, because then the
default behavior of the background box should be to encompass the bounding
rectangle of the text + padding.

If you look at my earlier email, that is why I asked about the decision to
support roll-up via groups of cues and overlap avoidance. As far as I am
concerned, that looks like over-engineering to me, and if there is a better
way to do it that avoids all these complications, we should consider it.

Specifying a cue box AND a region for a pop-on caption makes no sense to
me, and I don't think any casual caption author would understand it. So, we
need to make sure that the desired behavior can happen without explicitly
specifying a region. And if we do that, then again: what is the use case
for regions, other than dealing with a group of cues -- which brings us
back to my question above.

Christian


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

> On Mon, May 12, 2014 at 2:25 PM, Silvia Pfeiffer
> <silviapfeiffer1@gmail.com> wrote:
> > On Mon, May 12, 2014 at 10:16 PM, Philip Jägenstedt <philipj@opera.com>
> wrote:
> >> On Mon, May 12, 2014 at 10:24 AM, Silvia Pfeiffer
> >> <silviapfeiffer1@gmail.com> wrote:
> >>> On Mon, May 12, 2014 at 6:12 PM, 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
> >>>
> >>> There's a difference: you're putting a background on the individual
> >>> cues while the background on the region is putting a background on the
> >>> group of cues in one go. There is no chance of a gap appearing between
> >>> the cues because of this.
> >>
> >> Yes, that is true. (Trying to emulate a grid-based format should have
> >> similar problems.)
> >>
> >>>> 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.
> >>>
> >>> That's what the region is for.
> >>
> >> Doesn't regions have exactly the problem I describe? Not that I have a
> >> solution, I don't know how this could be made reliably when fonts and
> >> their sizes is under user control...
> >
> > Yes, the bounding box around a couple of lines/captions is always big
> > and has some whitespace in it. That's, however, not a problem, but
> > rather expected, IIUC.
>
> Leaving room for doubling the font size requires that the area of the
> background box is quadrupled. Is this really what is done in practice,
> or does it simply break down when you try to increase the font size
> more than a few percent?
>
> > Also, Christian just made a very good point about why such a bounding
> > box is important: it allows users to override the background on the
> > group of captions with a single setting (
> > ::cue-region(){background-color: red;} ).
>
> If it's important that users be able to override this background, then
> we need to figure out what to do when regions are not used. As I asked
> in another mail, is it possible to *not* use windows in 708?
>
> >>>> However, if the background needs to be unchanging over time
> >>>
> >>> What do you mean by "unchanging"?
> >>
> >> I mean a background which isn't just the bounding box of the cues
> >> current showing, but those that will be shown. The author cannot know
> >> what that box is, and calculating it at runtime would require
> >> rendering all cues once and assuming scripts won't change them...
> >
> > I don't think I've seen that requirement nor did I read that out of
> > CEA708 nor the FCC.
>
> See Nigel's mail. I have no idea if it's important to end users or not.
>
> Philip
>



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