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