Re: on SRT...

Hi Janina,

You understood correctly.

Indeed, the level 0 has to be specified sufficiently to meet currently
understood requirements.

And also: there is no level 0 specified yet - it will take time and
effort to specify it such that
1. browser vendors are happy to implement support for it, and
2. currently understood accessibility requirements are met.
It will be a balance act - a typical standards body's work. :-)

As for the time it takes - well, DFXP isn't even in CR yet, so I don't
know how long it will take to specify the levels. Assuming it can be
done fairly quickly, we can require browser vendors to support level 0
for this version of HTML and encourage them to support higher levels.
Nothing will hold them back from implementing higher levels before
another standard comes out. In this way, if all browser vendors charge
ahead, HTML 5.1 could e.g. already require e.g. level 3 out of 4.

What I am proposing here is a viable path forwards. If we try to push
for a full support of DFXP at this stage, we will get nothing - I
haven't heard of a single browser vendor who could be encouraged to
implementing full DFXP - they'd rather not implement it at all. It is
clear to me that a compromise is required. The staged approach that I
am proposing is this compromise.

If others have different ideas for a compromise, please do not
hesitate to offer them.

Cheers,
Silvia.


On Thu, Feb 25, 2010 at 10:08 PM, Janina Sajka <janina@rednote.net> wrote:
> 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 12:29:41 UTC