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

Re: on SRT...

From: Janina Sajka <janina@rednote.net>
Date: Thu, 25 Feb 2010 12:08:08 +0100
To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Cc: Philip Jägenstedt <philipj@opera.com>, David Singer <singer@apple.com>, Matt May <mattmay@adobe.com>, HTML Accessibility Task Force <public-html-a11y@w3.org>
Message-ID: <20100225110808.GA22546@sonata.rednote.net>
Please pardon the top posting, but I need to raise a different issue
here.

I don't understand how levels 0 through X are supposed to work in a
standards specification sense. What are you all talking about?

Are you saying Level 0 for Html 5, and level 1 for html 5.1? etc? If
"yes," then we need to focus primarily on whether level 0 is sufficient
to meet currently understood requirements--something not yet well
specified, afaik.

Given the time between html 4.01 and html 5, I'm disinclined to go this
way.

Now, what am I misunderstanding?

Janina

Silvia Pfeiffer writes:
> 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.

-- 

Janina Sajka,	Phone:	+1.443.300.2200
		sip:janina@rednote.net

Chair, Open Accessibility	janina@a11y.org	
Linux Foundation		http://a11y.org

Chair, Protocols & Formats
Web Accessibility Initiative	http://www.w3.org/wai/pf
World Wide Web Consortium (W3C)
Received on Thursday, 25 February 2010 11:09:12 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 04:42:02 GMT