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

Comments inline

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

> There are (at least) two ways of thinking about this. One is to let a
> region have a position, width and height of its own and lay out the
> cues in that region. When the cues can't fit, something happens,
> hopefully something other than simply clipping.
>
> The other way is to let the region have no size of its own, but simply
> be the bounding box, growing and shrinking as needed. That's pretty
> much what I did in this demo:
> http://people.opera.com/philipj/2014/03/vttscroll/simple.html
>
>
In this link above, for the scenario where no uniform background is
desired, to maximize viewable video area, the only thing that doesn't look
acceptable about it is the lack of left and right padding (while viewing
with Chrome). It may also be desirable to align to the left with respect to
a left anchor, rather than center, but that's already supported, isn't it?

If you want a uniform background, then you need to do a bit more work; more
comments below.

That didn't look great, so some extra magic clipping was needed:
> http://people.opera.com/philipj/2014/03/vttscroll/clip.html
>
>
The way I would approach this link is to have a uniform background extend
over some width that is relative to the font size (e.g. in units of em). If
there are also constraints with positioning, then this might need to be
limited by a maximum possible absolute width in pixels or screen
percentage, but I suspect that this is an edge case that is rare.

If you happen to have a line overflow because of maximum width, that could
be a problem. I'm not sure how common such a scenario would be, and if we
should worry about it, given the other problems that overly large font
sizes could cause. With respect to roll-up, caption line lengths in the US
on TV are pretty limited, and I've never seen a potential issue with font
sizes up to 200%.

> 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.
>
> If you're referring to the demos I posted, those are only ideas so
> far, the spec has not been changed.
>

I know, but the discussions about roll-up and employing overlap avoidance
are far older than this. They date back to early 2012 or so, and one of the
earliest bugs filed stated essentially that the overlap avoidance behavior
didn't support the roll-up use case. There was a lot of argument about
supporting them at all back then, but given the needs of the community,
support for roll-up can't be avoided.

The problem, for me, is not the overlap avoidance per se, but the thinking
about roll-ups fitting as a cue group use case. I might be wrong, but my
impression from this discussion as a whole is that this is the main use
case driver for regions, and where the complications stem from.


> Well, if it's acceptable that the background box changes in size as
> cues come and go then the bounding-box way would mostly work. Roll-up
> complicates things, but given enough effort perhaps an automatic
> clipping algorithm could be written as well. That's for now,
> though.
>

I think that's just using the bounding box of the cue(s), which would
> work fine. Having a fixed-size region which you quadruple just to be
> safe would leave lots of unused area in the common case, and I wonder
> if this is actually how any real system works.
>

If you make a region size relative to font size for roll-up or other fixed
size region use cases, that would seem the most logical from an authoring
point of view. If you quadruple because you double the font size, chances
are that you are in the group of people to whom the ensuing uniformity of
background matters. And if it doesn't, you have the option of turning off
the uniform background.

 Christian

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

Received on Monday, 12 May 2014 14:57:28 UTC