Add #region-timing feature designation (#169).

[skynavga]

Closes #169.

[nigelmegitt]

This looks good to me as it stands but I think we need to go further, considering the #timing feature. That feature is not specific about which elements have supported timing, and we do not have the converse of #region-timing such as #content-timing - if we had that then we could make #timing be the union of #content-timing and #region-timing.

@skynavga what would you think about adding #content-timing? (I'm not stuck on that name by the way, if you can think of a better one - I'm aware that "content" is a bit vague)

[skynavga]

On Fri, May 19, 2017 at 3:56 AM, Nigel Megitt ***@***.***> wrote: ***@***.**** commented on this pull request. This looks good to me as it stands but I think we need to go further, considering the #timing feature. That feature is not specific about which elements have supported timing, and we do not have the converse of #region-timing such as #content-timing - if we had that then we could make #timing be the union of #content-timing and #region-timing. @skynavga <https://github.com/skynavga> what would you think about adding #content-timing? (I'm not stuck on that name by the way, if you can think of a better one - I'm aware that "content" is a bit vague)

I'm operating on a presumption that wee cannot change the definitions of existing TTML1 feature designators. So, for example, I have introduced the feature #animation-2 to define an extended form of #animation.

…

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#317 (review)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAXCb3g5rG0WgfsdLwD02NLEqUYnkFGvks5r7Wc6gaJpZM4NeSa2> .