W3C home > Mailing lists > Public > public-html-a11y@w3.org > February 2010

Re: on SRT...

From: Philip Jägenstedt <philipj@opera.com>
Date: Thu, 25 Feb 2010 16:07:39 +0800
To: "David Singer" <singer@apple.com>, "Silvia Pfeiffer" <silviapfeiffer1@gmail.com>
Cc: "Matt May" <mattmay@adobe.com>, "HTML Accessibility Task Force" <public-html-a11y@w3.org>
Message-ID: <op.u8obi1sfatwj1d@philip-pc.oslo.opera.com>
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?

Philip Jägenstedt
Core Developer
Opera Software
Received on Thursday, 25 February 2010 08:08:32 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:05:09 UTC