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

I thought I had replied to this, but I can't find that reply. Here's
another one.

On Mon, May 12, 2014 at 4:57 PM, Christian Vogler
<christian.vogler@gallaudet.edu> wrote:
> 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.

I picked a bad demo, that demo doesn't actually use the bounding box.
This one also doesn't, but it looks like it does:
http://people.opera.com/philipj/2014/03/vttscroll/background.html

I just wanted to illustrate the difference that clipping makes. Left
alignment is supported, no problem.

>> 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%.

That's interesting. It sounds like there an assumption that lines will
always be short and thus never break, so that one cue is one line. If
that's true I wonder if we couldn't just give a region a maximum
number of active cues instead of a maximum number of lines. That would
have the same effect for well-authored content, but for the cases
where line wrapping is necessary the region would just grow as much as
it needs.

I've filed a bug to follow up on that idea:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25705

>> > 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 existing overlap avoidance doesn't let you do anything that
resembles roll-up, that's clear. With the demo I intended to show that
an algorithm very similar to overlap avoidance could be a part of
implementing roll-up, but I guess that point is not obvious unless you
read the implementation.

Perhaps this idea was discussed/discarded in 2012, but I was not aware
of it. This is an interesting wiki page from those days:
http://www.w3.org/community/texttracks/wiki/RollupCaptions

> 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.

I initially thought that a font-relative unit would solve the problem,
but I don't think it will. The text will still eventually be as wide
as the video itself, at which point it needs to wrap lines and grow
vertically instead.

The obvious thing to do with font-relative units is to create a region
that just barely holds the text within it. If that's the use case, we
should just provide a way of shrink-wrapping a background around the
cues directly. Otherwise, changing the font can introduce line breaks
even though there's actually lots of horizontal room left to grow in,
as illustrated by http://jsfiddle.net/zLB3N/

Philip

Received on Wednesday, 14 May 2014 12:29:19 UTC