Re: Absolute region positioning (was Re: Alternative approach to scrolling, with demos)

On 06/05/2014 23:20, "Philip Jägenstedt" <philipj@opera.com> wrote:

>On Tue, May 6, 2014 at 4:45 PM, Nigel Megitt <nigel.megitt@bbc.co.uk>
>wrote:
>> On 06/05/2014 14:17, "Philip Jägenstedt" <philipj@opera.com> wrote:
>>
>>>On Tue, May 6, 2014 at 12:19 PM, Nigel Megitt <nigel.megitt@bbc.co.uk>
>>>wrote:
>>>>
>>>> On 05/05/2014 15:14, "Philip Jägenstedt" <philipj@opera.com> wrote:
>>>>
>>>>>On Mon, May 5, 2014 at 2:50 PM, Silvia Pfeiffer
>>>>><silviapfeiffer1@gmail.com> wrote:
>>>>>
>>>>>> NB: Incidentally, following CEA708 rendering as exactly as possible
>>>>>>is
>>>>>> inline with what the US law prescribes, namely identical rendering
>>>>>> between TV and Online. Though, to be honest, there is a line of
>>>>>>"rough
>>>>>> identity" that I am prepared to accept and I would call overlap
>>>>>> avoidance an optimisation of sorts, which is why I'm not really
>>>>>> accepting this as an argument.
>>>>>
>>>>>What will we do if the European Union introduces similar legislation
>>>>>and broadcasters say that their existing content is EBU-TT, a TTML
>>>>>flavor? Should the TTML model be added to WebVTT?
>>>>
>>>> I don't know about adding the TTML model precisely but I do think it
>>>>would
>>>> be worth considering the logical semantics encapsulated in TTML for
>>>>region
>>>> definition and overlap processing, which has an accepted mapping from
>>>> CEA708 already, and has therefore tackled these questions. Given that
>>>> WebVTT is on Rec track in the TTWG and one of the deliverables is a
>>>>VTT
>>>> <--> TTML mapping it would make everyones' lives easier in creating
>>>>that
>>>> deliverable if the regions models are as closely coincident as we can
>>>>make
>>>> them, accepting the differences in rendering approach and syntax
>>>>between
>>>> the two formats.
>>>>
>>>> I haven't seen anything in the discussion so far that looks like a
>>>>CEA708
>>>> requirement that can not already be met using TTML regions. If you
>>>>want
>>>> region overlap avoidance that would be different, but I suspect that
>>>>isn't
>>>> actually needed, and in any case would be a separate case from the
>>>>z-index
>>>> overlap order definition: I can't see how both approaches could apply
>>>>to
>>>> the same content simultaneously.
>>>
>>>So, my question was actually rhetorical. I don't think it should be a
>>>goal in itself to map other formats to WebVTT, or for WebVTT to be one
>>>format to rule them all.
>>
>> Sorry I didn't spot the <rhetorical> tag! In any case there is a point
>>to
>> discuss there. I agree that format mapping isn't an end in itself, but
>>in
>> this case we know that some form of mapping will be generated and we can
>> aim to make life easier by reducing the size of the task. To be clear,
>> there is a TTWG goal to map between WebVTT and TTML - it is in the
>>group's
>> charter.
>
>If the required changes are trivial or are supported by common use
>cases then that would be valuable feedback like any other. It is
>making non-trivial changes for no other purpose than format mapping
>that I am wary of, because it is a road with no apparent end, and one
>that we don't need to walk if we take advantage of the fact that
>WebVTT is a part of the Web platform where less common use cases (a
>judgement call) can be left to custom rendering using JavaScript.

The end is defined by the scope of the specifications. In this case the
discussion is for how to define something new to WebVTT that has already
been defined elsewhere. Reuse can make our lives easier, is all. I would
expect significant differences in syntax, some differences in semantics
and hope for mostly overlap in the underlying model. Right now it looks
like there's partial overlap on the model but a possible need to bring
some more concepts in.

To be more concrete on the model, we're talking about defining a rectangle
which can be positioned, sized and styled, usually for the purpose of
containing timed text rendered within it (though it could be intentionally
empty). The presentation start and duration for that rectangle may be
defined independently or based on when there is active text within it. The
rectangle can carry an identifier and metadata that apply to it rather
than its contents. The styling is a mix of styling that applies to the
rendering of the rectangle itself (line colour, background colour, padding
etc) and that will be inherited by text rendered within it, in the absence
of styling applied directly to that text.

There is a use case for making positioning and sizing of regions variable:
captions need to move around for a variety of reasons including avoiding
underlying [video] content that is editorially important. There are
multiple ways to achieve this: move text around within its region; define
multiple regions and put text for a given moment in the appropriate
region(s); or move the region itself. Especially for the commonly used
display style where there is a 'fixed' region with a painted background in
which the caption text is rendered when present, and which remains visible
even when there is no text, the region should be no bigger than necessary,
so this doesn't suit a big region within which text is moved around. If it
needs to have the appearance of being moved, I guess the simplest way is
simply to redefine its origin 'on the fly'.

I assume that the application of styles to regions in WebVTT would follow
the CSS-like approach that is used for text styling, and there would be no
need explicitly to define inheritance of styles from regions to text
contained within them.

So what are the model features that may need to be brought into WebVTT? In
no particular order:
1. Independent timing of regions, e.g. so that they can be painted even
when they don't contain text.
2. Ability to select for styling purposes regions including setting
background and line painting colors, padding and zIndex (to define
painting order if multiple regions overlap). The ::cue-region
pseudo-element appears to partially fulfil this already.
3. Ability to select for styling purposes text contained within a
particular region.
4. Ability to assign metadata additional to identifiers for regions. (need
use cases for this in a WebVTT context)

I think that's it, you may spot others.

Nigel


>>>If other formats have features that address common use cases that
>>>WebVTT is missing then we should consider supporting those use cases,
>>>of course.
>>
>> I get the impression this is about FCC-mandated requirements rather than
>> usage frequency. It makes sense to do as little as possible to meet
>>those
>> requirements and expand & enhance later if people want to use it in new
>> ways. Lifting the existing region model from TTML would probably fit
>>that
>> description.
>
>As far as I am aware the FCC doesn't require using a specific
>technology to meet the requirements. However, I'm having trouble
>getting clear answers on this topic from legal, and don't know the
>plans of any browser company.
>
>Philip



-----------------------------
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 Wednesday, 7 May 2014 09:46:57 UTC