Re: on SRT...

On Thu, Feb 25, 2010 at 7:07 PM, Philip Jägenstedt <philipj@opera.com> wrote:
> On Wed, 24 Feb 2010 06:38:57 +0800, Silvia Pfeiffer
> <silviapfeiffer1@gmail.com> wrote:
>
>> On Wed, Feb 24, 2010 at 3:38 AM, David Singer <singer@apple.com> wrote:
>>>
>>> I don't have a problem with DFXP, but I think we'll need to profile it --
>>> it contains elements for support of (for example) 3GPP Timed Text, such as
>>> scroll-in, and also for out-of-time-order sequencing, neither of which I
>>> think we want in this case, do we?
>>>
>>
>> I agree about the need for profiling. I don't mind about the scroll-in
>> as long as we can map the 3GPP markup to some javascript action for
>> the browser. But this is definitely a feature of the more complex
>> kind.
>>
>> Most of the DFXP files I have seen so far in the wild are really simple.
>>
>> For example this one from Apple:
>>
>> http://www.apple.com/media/us/mac/imac/2009/tours/apple-imac-design_video-cc-us-20091111_cc.xml
>> which relates to http://www.apple.com/imac/
>> is basically a SRT file with a default display style. (Ignore the
>> metadata element which they are using and which incidentally has
>> non-standard attributes).
>>
>> That default display style can easily be mapped onto a div and css, so
>> I would regard this as not very hard to implement. This markup could
>> be a level 0 profile.
>>
>> There is also some html formatting markup inside the <p> elements,
>> such as <br/>, <b> and <i>, which can just be kept for HTML (obivously
>> needs to be well parsed and filtered so as not to create security
>> issues). But we could also consider that as part of level 0.
>>
>> Then, level 0 provides the ability for externally provided styling and
>> for prettier text - a good improvement over SRT and not overly
>> challenging to implement I would think.
>>
>> Next, we can go through DFXP and add selective features that make
>> sense to create a level 1,2, and maybe make level 3 the full DFXP
>> spec.
>>
>> I would consider this as a viable way to create a path towards
>> introducing DFXP support in steps, which do not ask too much
>> implementation requirements of the browser vendors in one go. I'd be
>> curious what the browser vendors think about this!
>
> Does the spec allow for such profiling, or would partial implementations
> simply be non-conforming?

I would say that the "baseline text codecs" that the <track> elements
support should be SRT and some profile of DFXP that still needs to be
defined. Then, if a browser supports higher levels, that's a bonus.
It's not guaranteed to work everywhere though, because it goes beyond
the baseline. The baseline would be conforming.

I would avoid calling profiles "partial" implementations though. Yes,
they may be a subpart of the full spec, but they are fully functional
for use, so by no means "partial". That word choice would create the
wrong impressions IMO.

It may be better to regard it as a potential upgrade path. If over
time browser vendors find that they need to support a higher profile,
because users are asking for it, they would implement support for that
higher profile. And then maybe the baseline in the standard can be
elevated in the next version of HTML (HTML6?), too, should that be
common consensus.

Cheers,
Silvia.

Received on Thursday, 25 February 2010 10:18:26 UTC