- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Mon, 12 May 2014 18:24:28 +1000
- To: Philip Jägenstedt <philipj@opera.com>
- Cc: Christian Vogler <christian.vogler@gallaudet.edu>, David Singer <singer@apple.com>, "public-texttracks@w3.org" <public-texttracks@w3.org>
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. > 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. > However, if the background needs to be unchanging over time What do you mean by "unchanging"? Silvia. > 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 >
Received on Monday, 12 May 2014 08:25:16 UTC