Re: Unifying the rendering approach

Hi Silvia,

On 23/02/2014 03:39, "Silvia Pfeiffer" <silviapfeiffer1@gmail.com> wrote:

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

If browsers render style and layout differently from how the TTML
specifies then that would appear to be non-compliant presentation.

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

Yes.

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

Exactly.

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

This choice seems to be between reading text that is smaller than ideal or
reading text that isn't visible at all. I'd bet it's easier to read small
text than invisible text.

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

I wasn't thinking of scrollbars but automatic scrolling, e.g. text scrolls
right to left on a single line without user intervention (i.e. smooth
animation with the first words on the line disappearing off the end to
make way for the later words), at a rate determined to make it somewhat
readable. It may well be that users would object to this also. Could do a
similar thing vertically, with lines scrolling, be it by smooth animation
or discrete animation.

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

Only at the expense of having the cues potentially render over editorially
important video content, such as mouths, the player with the ball etc.
It's tough to force the user to trade one aspect of accessibility for
another.

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

I meant to render this when unable to render the cue text, i.e. instead of
it, not additionally.

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

Okay, as long as we don't lose the issue.

Kind regards,

Nigel


>
>Cheers,
>Silvia.



-----------------------------
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 Monday, 24 February 2014 14:30:24 UTC