W3C home > Mailing lists > Public > public-tt@w3.org > May 2013

RE: TTML Agenda for 15/05/13

From: Michael Dolan <mdolan@newtbt.com>
Date: Wed, 15 May 2013 12:34:44 -0700
To: <public-tt@w3.org>
Message-ID: <01fb01ce51a3$427b0280$c7710780$@newtbt.com>
Your agenda says: "Approval of....", hence my advance concern.  Plans are

Re Proposal #2 (in addition to the AI I thought Glenn still had about flow):

Although there was email discussion about them being anonymous regions, how
is that inferred from the proposal language? Even if it is normatively
inferred, it might be good to informatively note that explicitly as it is
crucial to understanding the basic behavior.

What styles do they inherit?  I think the styles would need to be inherited
from the "current" region, not the styles from the near-proximity parent
elements.  More on this and other things in the attached email from last
summer, which I don't recall resolution on.

Unrelated, can we add an agenda item to accept the old liaison requests from
SMPTE and thus enable work on specific proposals?


-----Original Message-----
From: Sean Hayes [mailto:Sean.Hayes@microsoft.com] 
Sent: Wednesday, May 15, 2013 11:09 AM
To: Michael Dolan; public-tt@w3.org
Subject: RE: TTML Agenda for 15/05/13

Yes CP5 is not up for approval at this time, I only wrote it today as per my
AI form last week; so I'll just be going over whats there.

CP 1 & 2 have been out there for a long time and no discussion, so we need
to make progress on them it's not so much that I expect to approve them this
week, although that would be nice, but more that I want to know specifically
what the action plan is for doing so.

As to the defined behavior, I believe the mapping is well defined to
intermediate anonymous region, so that the text flow issues are as well
defined as text flows are in any region however I will go back and check
that in advance of the discussion tomorrow.

-----Original Message-----
From: Michael Dolan [mailto:mdolan@newtbt.com]
Sent: 15 May 2013 18:59
To: public-tt@w3.org
Subject: RE: TTML Agenda for 15/05/13

Some advance thoughts:

1. Proposal 1 (extension to set) is OK with me.

2. Proposal 2 (origin and extent semantics for <p>) - although I am
cautiously supportive of exploring this, I thought we previously agreed that
it is still lacking defined behavior for how text would flow within the
region, including wrap behavior, as well as the behavior of CR, LF and TAB
when content is randomly placed like this.  I think flow examples would be
needed just to better understand the ramifications, as this will be complex.
An alternative might be to define a non-flow region? (Just an idea - the use
cases that this addresses do not generally involve "rollup" captions).  A
minor comment on the first bullet of the "Impact" - the fact that there are
attributes that have no semantic meaning on some elements is a very general
issue and therefore the fact that the XML schema (properly) represents the
permitted syntaxes on <p> is not really relevant or specific to the affected
element and attributes. Suggest it be deleted. 

3. Proposal 5 - Although we discussed this generally, I don't recall seeing
these details before. I'm not opposed, but it seems like it would be
premature to approve it tomorrow.



-----Original Message-----
From: Sean Hayes [mailto:Sean.Hayes@microsoft.com]
Sent: Wednesday, May 15, 2013 10:04 AM
To: 'public-tt@w3.org'
Subject: TTML Agenda for 15/05/13

our teleconference is scheduled with reference to Boston Time, the correct
time of this teleconference in your locale may change. Please check

Thursdays 10:00am-11:00am Boston local

 Zakim Bridge +1.617.761.6200, conference 8865 ("TTML")
IRC: server: irc.w3.org, port: 6665, channel: #tt Web gateway to

Chair: Sean Hayes

Agenda+ Assign Scribe

Agenda+ Proposed updates to charter :

Agenda+ Progress on publication of SE

Agenda+ HTML5 mapping (now as change proposal [1])

Agenda+ Approval of 1.1 Change proposals [2] and [3].


Tracker (Issues and Actions): http://www.w3.org/AudioVideo/TT/tracker
Profile draft:  http://dvcs.w3.org/hg/ttml/raw-file/tip/ttml10-sdp-us

Change proposals:
[1] http://www.w3.org/wiki/TTML/changeProposal005
[2] http://www.w3.org/wiki/TTML/changeProposal001
[2] http://www.w3.org/wiki/TTML/changeProposal002 


Second edition draft: 


attached mail follows:

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:
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>.



-----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]


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 Wednesday, 15 May 2013 19:35:32 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 5 October 2017 18:24:09 UTC