[whatwg] Introduction of media accessibility features

On Wed, Apr 14, 2010 at 9:00 PM, Silvia Pfeiffer
<silviapfeiffer1 at gmail.com> wrote:
> On Thu, Apr 15, 2010 at 1:08 PM, Jonas Sicking <jonas at sicking.cc> wrote:
>> On Wed, Apr 14, 2010 at 5:59 PM, Silvia Pfeiffer
>> <silviapfeiffer1 at gmail.com> wrote:
>>> On Thu, Apr 15, 2010 at 3:19 AM, Tab Atkins Jr. <jackalmage at gmail.com> wrote:
>>>
>>> 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.
>>
>> I'm not sure I understand what you mean by "TTML is not supposed to be
>> a native Web format"? Once browsers add support for it, it becomes a
>> native web format.
>
> Would you call SRT a native Web format, too?

If we were to implement it directly in browsers, yes.

> Are RSS and ATOM native Web formats?

Most definitely.

I guess it comes down to a matter of definition of "native web
format". As a browser implementor I think of it as anything that I
have to implement and maintain to the level of quality that we want
the web to work. As a web author I think of it as any format that I am
able to use.

>> No matter if the implementation behind the scenes
>> map xsl:fo to CSS or through some other means. Netscape 4 implemented
>> CSS by mapping it to JSSS [1], however for all any web developer ever
>> knew, Netscape 4 supported CSS. Poorly.
>
> CSS is much tighter linked to HTML than a timed text format. If your
> UA happens to not support TTML, only one feature will be missing, i.e.
> timed text on your video. That doesn't destroy your Web page. But lack
> of CSS support does.

I guess I don't fully agree with you, but I think we've gotten side
tracked as I don't think this matters to the question at hand.

>> I really do hate to come up with a new format. But I think TTML is
>> severely off the mark for what we want. Am I wrong in that marking up
>> dialogue vs. sound effects vs. narrator vs. descriptions is important?
>> Or at least more useful than for example the ability to set the text
>> outline blur radius?
>
> I don't think your requirement is off the mark. I think it is
> something that current caption formats don't do, since there hasn't
> been a need and nobody has really looked at them from a Web
> background. Therefore it wasn't included in TTML. I also have multiple
> requirements that are not satisfied by TTML. I was under the
> impression that we can fix up TTML with such extensions. But if people
> prefer to develop a new format, that's fine by me.
>
> That doesn't mean though that we can ignore TTML. For what it has been
> developed - for use in captions in all sorts of environment, which
> include for example digital TV and mobile devices - it has been good
> and its use is spreading.

That's unfortunate to hear indeed. If there is a substantial body of
content produced in TTML, and this body of content gets published on
the web, then I agree that we indeed will have to reconsider.

/ Jonas

Received on Wednesday, 14 April 2010 21:31:16 UTC