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