RE: ISSUE-258 (extent value of auto): extent value auto, potential conflict with css [TTML 1.0]

Yes I’m not saying what we have is ambiguous or  isn’t clear. What I’m saying is that we have left “some assembly required” on the part of the implementer since we don’t give the appropriate semantic mapping to make this happen. I want to make the semantic mapping clear in the first instance, so that its obvious what values need to be passed to the render model.

For the extension, I did originally think of adding a totally separate property, however I couldn’t come up with a good name for it. And really in the CSS/XSL model extent is in fact defined by top, left, right and bottom; and origin and extent are already pretty embroiled with these traits, therefore  in the end it did make sense to me for these values to go in there. Its backwards compatible and compact too.

OTOH I’m more interested in the semantics than the syntax, so if there’s a more preferred way to express it I’m not necessarily against it.

From: Glenn Adams [mailto:glenn@skynav.com]
Sent: 19 June 2013 14:24
To: Sean Hayes
Cc: Timed Text Working Group
Subject: Re: ISSUE-258 (extent value of auto): extent value auto, potential conflict with css [TTML 1.0]

In my mind, there is nothing ambiguous about our intentions. extent auto on region means the same as the root container region's extent. How we mapped that to XSL-FO may have some issues, which I will need to ponder a bit. On the surface, I'm leery about having extent express left, right, top, bottom, since that is another way of expressing origin and extent. In other words, I don't want to mix up origin and extent with left, right, top, bottom. If we want to express the latter in a shorthand, I'd want to name it something else like "edges", and not mix its semantics with extent.

On Wed, Jun 19, 2013 at 8:06 PM, Sean Hayes <Sean.Hayes@microsoft.com<mailto:Sean.Hayes@microsoft.com>> wrote:
Yes, we made it up so we can do what we want, but currently for our reference visual semantics  we map to:
an fo:block-container element with an absolute-position attribute with value absolute, and where the region's position and extent are mapped to equivalent top, left, width, and height attributes;

And if absolute-position is absolute:
         The area's position (and possibly size) is specified with the "left", "right", "top", and "bottom" properties. These properties specify offsets with respect to the area's nearest ancestor reference area.

But since we don’t map right or bottom to anything explicitly, IMO we have to explain the translation a little better since in this case width=auto and right=auto so we have an under-constrained geometry, and our specified behavior does not fall out from the reference semantics.

I don’t think XSL 5.3.4 Overconstrained Geometry applies here, so it seems to me the CSS rules win. Which would cause the shrink-to-fit to happen. If we don’t want the CSS rules to win (although I would argue that we do), then we need to give a value for right/bottom that makes this come out the way we want it. Which would mean in the mapping we need to explicitly set right and bottom to zero (not auto), or actually if we want the literal reading, to –left and –top; although that seems not helpful.

I think the shrink to fit behavior is actually useful, as is the ability to position a region wrt its bottom and right (not origin); thus I’m proposing in 1.1 we give the author the ability to set bottom and right to something other than zero, so for example:

<region tts:origin=”15% auto“ tts:extent=”auto 3em 15% 10%” />

Would create a (centered) region which is 15% in from the left, and right borders, 10% from the bottom and 3em high – regardless of the aspect ratio of the video; the ‘top’ value would be computed based on the font height.

<region tts:origin=”10% 70%“ tts:extent=”auto auto auto auto” />

Would give the CSS shrink to fit behavior.

Make sense?

Sean.

From: Glenn Adams [mailto:glenn@skynav.com<mailto:glenn@skynav.com>]
Sent: 19 June 2013 11:56
To: Timed Text Working Group
Subject: Re: ISSUE-258 (extent value of auto): extent value auto, potential conflict with css [TTML 1.0]

Since extent is a property we invented (as a shorthand for width/height), there is no conflict. It is whatever we say it is. This is only a translation issue IMO.

On Wed, Jun 19, 2013 at 6:24 PM, Timed Text Working Group Issue Tracker <sysbot+tracker@w3.org<mailto:sysbot+tracker@w3.org>> wrote:
ISSUE-258 (extent value of auto): extent value auto, potential conflict with css [TTML 1.0]

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


Raised by: Sean Hayes
On product: TTML 1.0

The current text specifies that for extent (which maps to width and height)

"If the value of this attribute is auto, then the initial value of the style property must be considered to be the same as the extent of the Root Container Region."

I'm not sure if this is what XSL:FO would do, but this behavior conflicts with the value auto in CSS, which works in concert with top, bottom, left and right to satisfy the constraint that, for example (ignoring margin etc for now):

'left' + 'width' + 'right' = width of containing block

If only origin is given we have the situation that both width and right would be auto, which according to CSS would give: width = shrink-to-fit and solve for 'right'

This in my mind would actually be much more useful behavior than the current specified behavior (although is a breaking change), especially in the case where origin is non zero.


shrink-to-fit width is: min(max(preferred minimum width, available width), preferred width).

If we don't do this, at minimum we have to have some rules here that explain why right, bottom should not be considered to have default = auto (but presumably zero in this case)

But my preference would be to adopt the shrink to fit concept when width/height is auto. I also believe we should consider extending extent to allow optional additional values to set right and bottom.

If we want to preserve the existing behavior for backwards compat, we might consider some kind of parameter that allows the setting of the assumed right position, this would also help with line-stacking etc too.