[whatwg] Introduction of media accessibility features

On Thu, Apr 15, 2010 at 3:19 AM, Tab Atkins Jr. <jackalmage at gmail.com> wrote:
> On Tue, Apr 13, 2010 at 11:33 PM, Silvia Pfeiffer
> <silviapfeiffer1 at gmail.com> wrote:
>> On Wed, Apr 14, 2010 at 1:28 PM, Robert O'Callahan <robert at ocallahan.org> wrote:
>>> On Mon, Apr 12, 2010 at 12:47 PM, Silvia Pfeiffer
>>> <silviapfeiffer1 at gmail.com> wrote:
>>>>
>>>> Understood. But what is actually the cost of implementing all of TTML?
>>>> The features in TTML all map onto existing Web technology, so all it
>>>> takes is a bit more parsing code over time.
>>>
>>> When implementing one complex spec (TTML + XSL-FO) in terms of another
>>> complex spec (HTML + CSS), you have to be very very lucky to find that all
>>> the features map perfectly, even if the specs were designed to work together
>>> that way, which in this case they are not. Even if you're lucky today,
>>> evolution of the specs could easily accidentally break things.
>>
>> I believe it is possible today, but of course cannot prove it right
>> now. Also, future evolution of TTML will be directed by the Web in the
>> future if it gets integrated, as it would be its main use. Also: it's
>> a W3C standard, so probably would have the requirement not to break
>> the Web. So, I don't buy that latter argument. But I guess until there
>> is a mapping for all of DFXP, there probably aren't enough facts to
>> support/reject DFXP.
>
> I'd rather not be in charge of keeping them aligned perfectly. ?I'd
> also never want to be put in a situation where someone objects to a
> useful change in CSS because it doesn't work for TTML. ?Just
> integrating CSS and SVG is a pain, and there's measurable *benefit*
> there.

If TTML creates specs that cannot be mapped, then those are ignored.
All we are basically committing to would be that a best effort is done
on the mapping. Just like with SRT we would do a best effort on the
mapping - there are SRT files now that have more than just plain text
in them. But we would not commit to interpreting every special markup
that some author came up with that worked in his particular player.

I think the dependencies between external timed text formats and HTML5
are much less than e.g. the dependency on SVG. TTML is not supposed to
be a native Web format in my eyes. It is just interpreted for the Web.


>>> We could make that problem go away by normatively defining something that
>>> looks like TTML in terms of a translation to HTML + CSS. It wouldn't really
>>> be TTML though, and where's the added value for authors?
>>>
>>> I understand the deep political problems here, but I think it's most logical
>>> for styled content for the Web to use (possibly a subset of) HTML and CSS.
>>> Server-side tools to translate between TTML and HTML+CSS would be one way to
>>> address the desire to interoperate with TTML.
>>
>> I personally have no issue with introducing a new format - even
>> experimented with one some time ago, see
>> http://wiki.xiph.org/Timed_Divs_HTML . There are challenges with this,
>> too, and they are not only political. For example, I think we would
>> need to restrict some things from appearing in timed sections: e.g.
>> would we really want to allow multiple layers of video rendered on top
>> of video? But we could develop a new format - just like we have
>> developed microdata.
>>
>> Introducing a new format would indeed be mainly a political problem.
>> Not just would it go "against" all other existing formats. It would
>> also be a challenge to get other applications to support it, in
>> particular applications that do not contain a Web framework.
>>
>> Thus, my thinking was that what we do internally is basically HTML+CSS
>> on time sections. And all formats that we read from externally will be
>> mapped to that. We would already do that with SRT, too.
>
> +1 to Henry's suggestion of just using two formats: SRT, and SRT +
> (possibly some subset of) HTML+CSS, where the latter is simply a
> normal SRT file with HTML allowed where it would normally only allow
> plaintext for the caption.
>
> That seems to be the minimal change that can address this case, and
> appears to be a fairly logical extension of an existing widespread
> format.

A spec would need to be written for this new extended SRT format.
Also, if we are introducing HTML markup inside SRT time cues, then it
would make sense to turn the complete SRT file into markup, not just
the part inside the time cue. Further, SRT has no way to specify which
language it is written in and further such general mechanisms that
already exist for HTML.

I don't think SRT is the right base format to start extending from.
That extension doesn't give us anything anyway, since no existing SRT
application would be able to do much with it. It is not hard to
replicate the SRT functionality in something new. If we really want to
do "SRT + HTML + CSS", then we should start completely from a blank
page.

Cheers,
Silvia.

Received on Wednesday, 14 April 2010 17:59:06 UTC