Re: Scrolling as overlap avoidance (Re: Alternative approach to scrolling, with demos)

It's important not to lose the '+padding' detail that Christian mentioned
- is it possible to ensure that when the background is drawn behind the
text only its width can be extended by a specified amount, on all lines on
which it is displayed? This greatly enhances readability by not putting
the background box edge very close to the text edge.

One way to achieve the 'on all lines' requirement is to use
box-decoration-break: clone. It may be helpful to see the example of the
HTML/CSS mapping of the proposed TTML2 feature to add this effect, which
can be seen at [1]. A mechanism to achieve a similar effect should be
available in WebVTT, if it isn't already.

[1] https://www.w3.org/wiki/TTML/changeProposal015#box-decoration-break

Nigel


On 09/05/2014 02:51, "Silvia Pfeiffer" <silviapfeiffer1@gmail.com> wrote:

>It's the latter one: only the background behind the text is coloured.
>Silvia.
>
>
>On Fri, May 9, 2014 at 9:50 AM, Christian Vogler
><christian.vogler@gallaudet.edu> wrote:
>> Thanks. It would be good to get definite answers on these things,
>>because I
>> suspect that this ultimately will determine what consumers think about
>>the
>> impact of the rendering simplification proposals.
>>
>> Christian
>>
>>
>> On Thu, May 8, 2014 at 7:47 PM, Silvia Pfeiffer
>><silviapfeiffer1@gmail.com>
>> wrote:
>>>
>>>
>>> On 9 May 2014 09:08, "Christian Vogler"
>>><christian.vogler@gallaudet.edu>
>>> wrote:
>>> >
>>> > Hmm, ok, I see a potential problem with the use case under point #10
>>>in
>>> > http://www.dcmp.org/captioningkey/text.html - for the purpose of
>>>showing as
>>> > much image as possible, you want the background width to be no
>>>larger than
>>> > the actual text width + padding. That is what is shown in this image
>>>(and
>>> > also in #9). But if you scale the font, you eventually need to wrap
>>>around
>>> > when the left/right cues grow too close to each other.
>>> >
>>> > That leaves two options:
>>> >
>>> > 1. explicitly specify cue width, and have the background extend all
>>>the
>>> > way across the width. That covers more image than you should, and
>>>also
>>> > doesn't look very pleasing aesthetically if you have a large
>>> > black/translucent bar with no text in it.
>>> >
>>> > 2. force some kind of maximum width, after which you wrap around -
>>>but
>>> > the cue width can be smaller than the max depending on font metrics.
>>>And the
>>> > background extends only across the real cue width.
>>> >
>>> > I'm not yet fully up to speed - does WebVTT cover #2? Or are there
>>> > alternatives that could give the desired behavior?
>>>
>>> Yes, vtt does #2.
>>>
>>> These are two cues: one under each speaker. Since you don't want them
>>>to
>>> run into each other, you specify the size (I.e. width) of the cue that
>>>they
>>> go into. That provides the display that #10 shows. Then you increase
>>>the
>>> font size. When the text gets bigger than the cue width, it wraps.
>>>
>>> > Christian
>>> >
>>> >
>>> > On Thu, May 8, 2014 at 6:58 PM, Silvia Pfeiffer
>>> > <silviapfeiffer1@gmail.com> wrote:
>>> >>
>>> >> On Fri, May 9, 2014 at 3:25 AM, Christian Vogler
>>> >> <christian.vogler@gallaudet.edu> wrote:
>>> >> > Just checking here, what does this mean for text background? Say,
>>>you
>>> >> > have
>>> >> > white text on black background - will the black extend only to the
>>> >> > width of
>>> >> > the actual text plus padding?
>>> >>
>>> >> In the non-region case:
>>> >>
>>> >> If you explicitly specify the width of your cue and the text is much
>>> >> smaller than the width, the background will still cover the fully
>>> >> specified width.
>>>
>>> Actually, I might have been wrong on this. I'd have to check (on a
>>>train
>>> now). The cue box has the size as width, but I think background may
>>>still
>>> only be rendered on the actual text. Let me get back to you on this.
>>>
>>> Silvia.
>>>
>>> >> If you do not specify a width, then the cue with is determined
>>> >> automatically based on the text width and the background will only
>>>be
>>> >> on the width of the text.
>>> >>
>>> >>
>>> >> In the region case:
>>> >>
>>> >> The non-region case background on ::cue still applies.
>>> >>
>>> >> However, there is now also a region box whose size is explicitly
>>> >> determined (width/height). You can set a background color on that
>>>box
>>> >> with ::cue-region . That background covers the full width of the
>>> >> region no matter the width of the cues or cue text inside.
>>> >> As for the height: in the case of scrolling regions, the height is
>>> >> dynamic and depends on the number of lines that are being rendered.
>>> >> For non-scrolling regions the height is fixed, so a non-scrolling
>>> >> region without cues inside with a red background will be a red
>>> >> rectangle on screen.
>>> >>
>>> >>
>>> >> Hope that clarifies it?
>>> >>
>>> >> Silvia.
>>> >
>>> >
>>> >
>>> >
>>> > --
>>> > 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
>



-----------------------------
http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and 
may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in 
error, please delete it from your system.
Do not use, copy or disclose the 
information in any way nor act in reliance on it and notify the sender 
immediately.
Please note that the BBC monitors e-mails 
sent or received.
Further communication will signify your consent to 
this.
-----------------------------

Received on Friday, 9 May 2014 09:59:20 UTC