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