Re: Unifying the rendering approach

Hi Nigel,

On Tue, Feb 18, 2014 at 11:00 PM, Nigel Megitt <nigel.megitt@bbc.co.uk> wrote:
> On 18/02/2014 10:34, "Silvia Pfeiffer" <silviapfeiffer1@gmail.com> wrote:
>
> WebVTT is opening up new ground here, by allowing a region's dimensions to
> be set without necessarily controlling the text size. TTML doesn't have
> the same issue because all of the responsibility lies with the author.

Once TTML is rendered in browsers through TextTrack mechanisms, it has
the same issue though, since in browsers, users can overrule
rendering. Your raised issues might indeed be more a HTML spec issue
than a WebVTT issue.

> In
> WebVTT client-side styling and rendering can change the presentation and
> therefore create this somewhat over-constrained scenario,

If I understand you correctly, you are particularly thinking about the
case where text overflow happens when the user in the browser changes
the presentation?

Let me just clarify that when the author creates a caption cue with
text that fits on the screen and into a region the cue gets rendered
exactly as authored, even with WebVTT. When the user then decides to
change the font size, the region should allow growing with the font
size (see https://www.w3.org/Bugs/Public/show_bug.cgi?id=23849 and
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23865). Thus, the case
of a cue overflowing its authored number of lines really is an extreme
edge case that we can't control fully.

> whilst also
> potentially offering routes out of it that wouldn't be available in TTML.
> In this case it's important to specify as friendly as possible a fallback
> scenario.
>
> Several fallback scenarios may exist, and I wouldn't like to be too
> prescriptive when others may have better ideas. Some ideas (not
> proposals!) may be:
>
> - a 'shrink text to fit' setting that allows clients to resize or
> re-layout text to fit on the specified number of lines;

That would be extremely problematic since the user is trying to
increase the font size - probably because they are trying to be able
to read the text. If the browser in turn reduced the font size just to
make the text fit into the region, that would be counter-productive.


> - some combination of horizontal and/or vertical scrolling patterns that
> allows the client to maintain a maximum word reading rate specified in the
> document;

Scrollbars on captions? Do you expect the user to interact with them
while watching a video? Thus they would need to pause constantly to
scroll and read?

If the user really wanted this, they could always get a user script to
do this. Since it seems a particularly poor user experience, I
wouldn't want to set this as the default rendering approach.


> - limited ability for client to override region dimensions based on the
> rato of client-specified font size to authored font size;

I think https://www.w3.org/Bugs/Public/show_bug.cgi?id=23865 will
resolve this for us.


> - ability to display some fallback text, specified in the document, in the
> event that text is omitted, e.g. a pseudo-class ::nofit whose visibility
> would typically set to 'visible' on inability to completely render and
> 'hidden' otherwise, and would thereby reveal text in a box, say "Some
> caption text missing". Of course you'd have to find a way to ensure that
> such text itself could be rendered!

I think it would be counter-productive to try to render more text if
there is not enough space to render the cue text in the first place.


In any case, at this point we are only focused on getting the
author-provided rendering right. Let's worry about what happens when
the user changes the rendering/font size in a different thread.

Cheers,
Silvia.

Received on Sunday, 23 February 2014 03:40:20 UTC