RE: ISSUE-176 (extent and origin on blocks): Adding support for extent and origin attributes on block elements [DFXP v.next]

Some thoughts on this in advance of the 21st....

I am supportive of this new feature, so don't interpret these comments as being opposed.  It's just important to get all the details correct.

As I understand the proposal:
http://www.w3.org/wiki/TTML/changeProposal002 
the presence of tts:origin and/or tts:extent on a block element will cause an anonymous region to be created. There are some things to consider about this:

1. Is the anonymous region triggered by just origin, either origin or extent, just extent, or are both required?

2. [as discussed in a recent call, but captured here for completeness] The proposal needs normative prose description of the intended behavior on the affected elements and attributes. Although good, it is not sufficient to just add text to 9.3.3, Step 6 and provide an informative example.

3. It does not appear to be possible to apply attributes that are defined to only have semantics on <region> or can't be inherited,  e.g. tts:opacity, tts:showBackground, etc.  It seems that we would have to change all these attribute descriptions to explain how they can be applied to anonymous regions. I don't think it would be acceptable to preclude their use.

4. Without an identifier (xml:id), there doesn't appear to be any way to animate these anonymous regions. Maybe it is not needed (in which case we should explicitly note the shortfall).  But if it is, perhaps we could come up with some derived region id's such as the <p> id appended with a number or something - e.g. using the example, the first anonymous region would be "p1.1".

5. When are these regions active exactly?  Do they inherit begin/end/dur including settings on the block element that invokes the creation of the region?

6. When are these regions visible exactly?  Are they the same as explicit regions (and thus under control of tts:showBackground - see #3 above)?  This would imply that (using the initial value of showBackground) that they are visible for the entire duration of the document per an external timeline. This means a presentation processor will need to scan the <body> and actually create all the regions in advance of dealing with the active timing, just as if they were in the <head>.

Regards,

 Mike 

-----Original Message-----
From: Timed Text Working Group Issue Tracker [mailto:sysbot+tracker@w3.org] 
Sent: Thursday, August 23, 2012 3:08 AM
To: public-tt@w3.org
Subject: ISSUE-176 (extent and origin on blocks): Adding support for extent and origin attributes on block elements [DFXP v.next]

ISSUE-176 (extent and origin on blocks): Adding support for extent and origin attributes on block elements [DFXP v.next]

http://www.w3.org/AudioVideo/TT/tracker/issues/176

Raised by: Sean Hayes
On product: DFXP v.next

It has become common practice to use the extent and origin attributes directly on block elements (specifically <p>), as this greatly simplifies authoring and conversion process. This is essentially akin to creating 'anonymous' regions for each block, or relative positioning in CSS.

The TTML 1.0 spec allows this syntactically but did not specify any meaning. We should resolve this by supplying reference semantics for the practice.

Received on Friday, 7 September 2012 17:19:43 UTC