http://lists.w3.org/Archives/Public/public-texttracks/2014May/0064.html

I support the change to the default position. (In fact, I thought this was already in the spec - https://code.google.com/p/chromium/issues/detail?id=342587 ).

I would like to retain positionAlign because it lets the author isolate the interpretation of the position value from the text alignment. This is very helfpul when translating positioned cue, since a change in language may imply a change in text direction, hence a change in alignment. I would prefer to have a way not to require changes to position values when a track is translated.

I don't think I understand the situation completely, do you mean that you have a cue that you always want to occupy (say) the left half of the screen regardless of the cue text direction?

AFAICT align:left size:50% would do that with my suggestion, where position:0% would be implied by align:left.

To be clear, my idea was that position 0% would always mean the left edge, regardless of text direction.

And "auto" should be and actual value for position and part of the IDL interface as for line. Currently there's a "default text track cue text position" concept which isn't used anywhere, so something is missing.

In general, I think your proposal will do the intuitive thing and means that it will be easier to specify cue attributes.

The specific scenario I'm thinking about:

I want to position the cue on the left half of the screen, since that is where the person speaking is located in the video.

I'd like to use align:start, so that ltr languages are left aligned and rtl languages are right aligned.

I'd like there to be a single position value that works for both language directions. I don't think there is one.

Your proposal didn't address the meaning of auto for align:start and align:end. I assume that align:start implies position 0% for ltr languages and position 100% for rtl languages. This will fail in my scenario above.

Thank you, I understand the concern now.

If the use case is a speaker on the left of the screen, I don't understand why you wouldn't just use align:left. If right-alignment is acceptable for left-to-right text, why is left-alignment not acceptable for right-to-left text?

https://www.youtube.com/watch?v=BbqPe-IceP4 does it the way I think makes sense, at least.

Note that if you have two speakers, doing it the way you suggest could result in the two cues both aligned towards the center, which seems pretty bad.

If conversion from another format is the real use case, the software would be converting one file at a time and could just do the right thing.

I've thought more about positionAlign and have an updated proposal.

One problem with positionAlign is that it adds a fourth input (position, size, align, positionAlign) to an algorithm that only has three outputs (left, width, text-align), which means that there will be multiple ways of achieving the same result. That's not *always* bad, but I think I have something that will work with the three inputs we have.

One of odd things about the original spec was that the meaning of position flipped when the text direction (a property calculated from the cue text) changed. That's pretty annoying if you're trying to position something to align with or avoid something on screen. Silvia's spec change got rid of this aspect, but there were other changes as well.

My suggestion is to modify the original spec by using the left-to-right code paths for right-to-left as well. That means that the cue box will stay the same even if the text changes, but it's still possible to use align:start/end to get the direction-dependent alignment within that box.

Here's a demo: http://people.opera.com/philipj/2014/05/vttposition/

(Note that the demo fixes bug 22016 in the way I would have fixed it in the spec, because otherwise rtl is just broken and hard to compare.)

And, on the actual topic of this bug, the auto position would map to an actual position as such:

left/start: 0
right/end: 100
middle: 50

(This fix makes sense in any of the models, really.)

(In reply to Loretta Guarino Reid from comment #2)
> I support the change to the default position. (In fact, I thought this was
> already in the spec -
> https://code.google.com/p/chromium/issues/detail?id=342587 ).

Yes, it is already in the spec and is called "default text track cue text position alignment".


> I would like to retain positionAlign because it lets the author isolate the
> interpretation of the position value from the text alignment. This is very
> helfpul when translating positioned cue, since a change in language may
> imply a change in text direction, hence a change in alignment. I would
> prefer to have a way not to require changes to position values when a track
> is translated.

Agreed. I don't see a need for this change.

(In reply to Philip Jägenstedt from comment #4)
> To be clear, my idea was that position 0% would always mean the left edge,
> regardless of text direction.

It already does. There is an explicit note in the spec that relates to this:

"Even for horizontal cues with right-to-left paragraph direction text, the cue box is positioned from the left edge of the video frame. This allows defining a rendering space template which can be filled with either left-to-right or right-to-left paragraph direction text. If you define such a cue box template with start or end aligned text, make sure to control its size unless you want text to flip from one side of the video frame to the other."

(In reply to Philip Jägenstedt from comment #9)
> Here's a demo: http://people.opera.com/philipj/2014/05/vttposition/

It seems to me that in your implementation the only difference between the "Silvia" and the "Philip" mode is that the cue boxes are not truncated at the edge of the video in the "Silvia" mode. This is a very different problem to the ones you are trying to address.

I'm going to reply on the mailing list thread because I think we need a more in-depth explanation of why the spec is how it is now and how that fixes all the bugs we have thus far talked about.

As for the problem of truncating a box at the edge of the video: when the author decides to make a box that is explicitly 80% big and positions it at the 50% mark, they expect the box to render 30% outside the video. Is this an author error or not? In my thinking it's not: maybe the author has good reasons to make the box that large. Even if it is an authoring error: in HTML we don't protect authors from their errors but render what they tell us to render. I'd prefer we stick to this model here, too.

(In reply to Philip Jägenstedt from comment #5)
> And "auto" should be and actual value for position and part of the IDL
> interface as for line. Currently there's a "default text track cue text
> position" concept which isn't used anywhere, so something is missing.

It's being used, just not referenced.

See point 4 in:
http://dev.w3.org/html5/webvtt/#dfn-parse-the-webvtt-cue-settings

From the mailing list: "For script-created cues, position will always have some specific value and the default logic is never hit. To make it work everywhere, auto needs to be a property of position, and the mapping from alignment to position needs to happen in the rendering section."

(In reply to Philip Jägenstedt from comment #15)
> From the mailing list: "For script-created cues, position will always have
> some specific value and the default logic is never hit. To make it work
> everywhere, auto needs to be a property of position, and the mapping from
> alignment to position needs to happen in the rendering section."

That's a good point - I hadn't checked script creation (though I really can't see it on a mailing list).

However, I don't see the problem. If you have to create a VTTCue by hand and have to actually specify position and positionAlign explicitly, there's no problem, seeing as the default logic only makes sure that these fields get a value.

I am assuming that the weird horizontal position adjustments of point 11 of the rendering algorithm where "the point x% along the width of the bounding box of the boxes in boxes is x% of the way across the width of the video's rendering area" gets removed, since I've not seen a use case for that.


I will, however, say that a "auto" value is useful for the vertical adjustment for lineAlign and bug 24038 actually already suggests adding a value of "auto" to make that feasible.

(In reply to Silvia Pfeiffer from comment #16)
> (In reply to Philip Jägenstedt from comment #15)
> > From the mailing list: "For script-created cues, position will always have
> > some specific value and the default logic is never hit. To make it work
> > everywhere, auto needs to be a property of position, and the mapping from
> > alignment to position needs to happen in the rendering section."
> 
> That's a good point - I hadn't checked script creation (though I really
> can't see it on a mailing list).
> 
> However, I don't see the problem. If you have to create a VTTCue by hand and
> have to actually specify position and positionAlign explicitly, there's no
> problem, seeing as the default logic only makes sure that these fields get a
> value.

The same is true of the parser case: if you just specifiy all the settings there is no problem. We agree that leads to surprising results. Likewise, the following would lead to surprising results:

var cue = new VTTCue(0, 1, 'foo');
cue.align = 'left';
// didn't set cue.position to match

   --- Comment #7 from Philip Jägenstedt <philipj@opera.com> ---
    Thank you, I understand the concern now.

    If the use case is a speaker on the left of the screen, I don't understand why
    you wouldn't just use align:left. If right-alignment is acceptable for
    left-to-right text, why is left-alignment not acceptable for right-to-left
    text?


It might be acceptable, but in general, text is more readability if lines are aligned on the leading edge.

WebVTT seems to be accommodating easy handling of different text directions with align:start and align:end. I don't know of any other format that makes this easy. We could deprecate align:start and align:end, but I would rather see the support finished, if it doesn't add to the complexity too much.


    https://www.youtube.com/watch?v=BbqPe-IceP4 does it the way I think makes
    sense, at least.

    Note that if you have two speakers, doing it the way you suggest could result
    in the two cues both aligned towards the center, which seems pretty bad.


Presumably when tracks are translated from a LTR language to a RTL language, all the captions will be translated, so the cues will all become right-aligned, rather than aligning towards the center.

(In reply to Loretta Guarino Reid from comment #18)
>    --- Comment #7 from Philip Jägenstedt <philipj@opera.com> ---
>     Thank you, I understand the concern now.
> 
>     If the use case is a speaker on the left of the screen, I don't
> understand why
>     you wouldn't just use align:left. If right-alignment is acceptable for
>     left-to-right text, why is left-alignment not acceptable for
> right-to-left
>     text?
> 
> 
> It might be acceptable, but in general, text is more readability if lines
> are aligned on the leading edge.
> 
> WebVTT seems to be accommodating easy handling of different text directions
> with align:start and align:end. I don't know of any other format that makes
> this easy. We could deprecate align:start and align:end, but I would rather
> see the support finished, if it doesn't add to the complexity too much.

Yeah. I don't know that it's super useful, but both what Silvia spec'd and what I'm now suggesting actually makes align:start and align:end make the text alignment change without changing the box.

ok, I think we document it clearly and move on. If we have explicit positionAlign, authors of RTL captions who use align:start but find the default value of position confusing can spell it out explicitly. 

This is definitely preferable to having the box change position. It solves my problem with translated positioned text.

I've prepared a pull request for what I want to implement, which matches the demo I made:
https://github.com/w3c/webvtt/pull/69

positionAlign is useful in this case:

cue setting: position:20% align:middle

This has the expectation that the text is middle aligned on the 20% position and that's what "auto" should do. If instead you want it to middle align on the left or right of it: use positionAlign. In general you do not want to have to recalculate the position and the size attribute values to make a simple box alignment change.

(In reply to Silvia Pfeiffer from comment #22)
> positionAlign is useful in this case:
> 
> cue setting: position:20% align:middle
> 
> This has the expectation that the text is middle aligned on the 20% position
> and that's what "auto" should do.

position would be 20% in this case, which "auto" do you mean?

> If instead you want it to middle align on
> the left or right of it: use positionAlign. In general you do not want to
> have to recalculate the position and the size attribute values to make a
> simple box alignment change.

Assuming that we have size clamping (bug 25660) I think this would be the result:

position:20% align:middle => left:0% width:40%

position:20%,left align:middle => left:20% width:80%

position:20%,right align:middle => left:0% width:20%

If that's what you wanted, you could have done this instead:

position:60% align:middle => left:20% width:80%

position:10% align:middle => left:0% width:20%

The issue isn't whether it is possible to convert between the representations. For any cue setting, this is just algebra.

My issue is that associating the text alignment and interpretation of position makes it much more error prone to repair or translate cues. If I use middle position alignment because I want the captions positioned under the person who is speaking, but with left text alignment because it is easier to read left-aligned text, I don't want a dependency on the width of the cue text. The cue text size may change to fix a typo, or add punctuation, or translate to a difference language. This requires a change to the value of position to keep the cue centered in the correct location.

(In reply to Loretta Guarino Reid from comment #24)
> The issue isn't whether it is possible to convert between the
> representations. For any cue setting, this is just algebra.
> 
> My issue is that associating the text alignment and interpretation of
> position makes it much more error prone to repair or translate cues. If I
> use middle position alignment because I want the captions positioned under
> the person who is speaking, but with left text alignment because it is
> easier to read left-aligned text, I don't want a dependency on the width of
> the cue text. The cue text size may change to fix a typo, or add
> punctuation, or translate to a difference language. This requires a change
> to the value of position to keep the cue centered in the correct location.

OK, this is an interesting case. To rephrase: you have a cue with several short lines and you want their left edges to align. Then you want to position the bounding box of those lines so that it is centered around a fixed point beneath the speaker. Is this understanding correct?

This is something that maybe we should support if it's a common problem, but positionAlign as currently specified doesn't do this, because at no point in the algorithm is the width of the bounding box used.

FWIW, I'm not aware of a way to do the same thing using CSS. Are there other formats which support this and how are you currently implementing them?

    > The issue isn't whether it is possible to convert between the
    > representations. For any cue setting, this is just algebra.
    >
    > My issue is that associating the text alignment and interpretation of
    > position makes it much more error prone to repair or translate cues. If I
    > use middle position alignment because I want the captions positioned under
    > the person who is speaking, but with left text alignment because it is
    > easier to read left-aligned text, I don't want a dependency on the width of
    > the cue text. The cue text size may change to fix a typo, or add
    > punctuation, or translate to a difference language. This requires a change
    > to the value of position to keep the cue centered in the correct location.
    OK, this is an interesting case. To rephrase: you have a cue with several short
    lines and you want their left edges to align. Then you want to position the
    bounding box of those lines so that it is centered around a fixed point beneath
    the speaker. Is this understanding correct?

Yes, that is correct.
 


    This is something that maybe we should support if it's a common problem, but
    positionAlign as currently specified doesn't do this, because at no point in
    the algorithm is the width of the bounding box used.

A good point! We would either need to specify an appropriate width, or (ideally) use some kind of automatic width to derive the width of the bounding box of the text.  I'm not sure there is any format that supports the latter model.


    FWIW, I'm not aware of a way to do the same thing using CSS. Are there other
    formats which support this and how are you currently implementing them?

I believe 708-style positioning achieves this by positioning the bounding box via the anchor point, but specifying the text justification separately.  The size of the bounding box is specified, but basically in terms of ems, that is, the box grows when the font size is changed.

The way I would support that feature (if at all) is to have an additional setting which controls the text alignment without affecting the bounding box of the text. It would have to be a two-pass layout: First lay out the text as usual. Then, calculate the bounding box of the text and shrink the cue box to match. Finally, render the text with its final text alignment.

The net result would be that the longest line stays where it was, but the shorter lines may move. This would degrade fairly well, because no matter what the text would stay in approximate the same place.

If you're interested in such a feature a new bug would be helpful. I don't think repurposing positionAlign to do the job would be very useful, since it wouldn't actually change the position.

(In reply to Philip Jägenstedt from comment #25)
> 
> OK, this is an interesting case. To rephrase: you have a cue with several
> short lines and you want their left edges to align. Then you want to
> position the bounding box of those lines so that it is centered around a
> fixed point beneath the speaker.
> 
> This is something that maybe we should support if it's a common problem, but
> positionAlign as currently specified doesn't do this, because at no point in
> the algorithm is the width of the bounding box used.

The "width of the bounding box" is the calculated "size", which by default is 100%. That's what the "cue box" is. If that is not clear, do propose how to clarify.

(In reply to Philip Jägenstedt from comment #27)
>
> If you're interested in such a feature a new bug would be helpful. I don't
> think repurposing positionAlign to do the job would be very useful, since it
> wouldn't actually change the position.

positionAlign was introduced to align the cue box, which is the bounding box into which the text is rendered. It is exactly produced for the kind of use case Loretta envisions.

The "cue box" in the spec is "a box within which the text of all lines of the cue is to be rendered" and the size setting is "a number giving the size of the cue box".

This is different from the bounding box of the rendered text. As an analogy, a <div> can be much larger than the bounding box of the text within it.

Do you want to file a new bug to make positionAlign do whatever it was intended to do?

Here's how people that I have watched author captions do it: they create the box into which a cue is to be rendered (giving a size), then they position the box, then they put the text into it, and then the decide on left, middle, right alignment in that box.

What the lack of positionAlign forces authors to do is to decide on their alignment first, then the size, and position then has to be adapted from there.

For example, I author a caption that is 80% wide and is supposed to sit at the 20% mark. Now, if all I want is to change the text alignment inside that box, I have to do the following three different cues:

align:middle position:60% size:80%
or
align:left position:position:20% size:80%
or
align:right position:100% size:80%

With positionAlign you follow the natural way of authoring, which enables people to change the alignment without having to consider the side effects:

position:20%,start size:80% align:middle/left/right

Just go to your demo at http://people.opera.com/philipj/2014/05/vttposition/ and try to author a caption cue with a fixed position and size and then try to play with the alignment. It is very unnatural and confusing.

Also, the natural way to position a box is with its left edge aligned to position. If we didn't have to be conformant to past implementations, I would make positionAlign=start the default, independent of text alignment being middle/left/right.

The key change that positionAlign provides us with is that the cue settings become independent dimensions. Right now, if you change alignment, that has adverse effects on both the position at which the cue is rendered, as well as calculated cue box size (in particular when the size wasn't specified). That is a really poor property of our settings. While I can't undo the past (i.e. we have to deal with the situation that by default text align determines cue box alignment and size), the least we can do is to give authors a possibility to break that co-dependency.

For example:

position:60 align:start
creates a cue box that starts at the 60% mark and is 40% wide.

Just changing align to 'end' suddenly creates a cue box that starts at the 0% mark and is 60% wide.
This has a much larger effect on the layout than a non-suspecting author would expect, in particular the text within may not just change alignment, but possibly also change line breaks and the cue box becomes shorter.


Incidentally, the addition of positionAlign fixed bug 19178.

If we're back to positionAlign as syntactic sugar as opposed to the use case in comment 25, then we're just bikeshedding. Most captions are going to use the same text alignment for all cues, and setting the size at all is something you should only do when avoiding overlap. Only rather advanced authors would run into the problems you describe, and they are easy to work around manually or with tooling.

If positionAlign were a new request, I would say "v2" and wait to see what happens in the wild.

(In reply to Philip Jägenstedt from comment #33)
> If we're back to positionAlign as syntactic sugar as opposed to the use case
> in comment 25,

Comment 25 indeed needs a solution and I think it's by defining the "cue box" that I've been using in the spec as the bounding box of the line boxes within a cue. When size is "auto", then the width of the cue box is used for size. Then positionAlign=middle with align=left and size=auto will do exactly what Loretta is after.


> Most captions are going to use
> the same text alignment for all cues, and setting the size at all is
> something you should only do when avoiding overlap.

When explicitly positioning a cue box, it's for the reasons Loretta outlines: putting text under a particular person or a particular spot. So, one typically defines a box to render text into. Then the text is added into this box. Without an auto size, you have explicitly specify the width before you can do a centered cue box, but with left or right aligned text. So, you would do: position="the middle position under the person", positionAlign=middle, align=left, size="width of the largest line". At least, you are able to calculate this positioning roughly when authoring. I assume that's what Loretta has to do right now because we don't have the cue box size "auto" be the width of the bounding boxes. positionAlign is a step towards solving this problem. Taking it away is a step backwards.


> Only rather advanced
> authors would run into the problems you describe, and they are easy to work
> around manually or with tooling.

Basically every author that uses position runs into this problem for the reasons outlined above. Let's resolve the bounding box issues as part of this problem rather than going back to where we weren't even able to position a cue box at a fixed left border with middle aligned text in it.

> If positionAlign were a new request, I would say "v2" and wait to see what
> happens in the wild.

We've already seen what happens in the wild. People have to specify size to get around the problem and they have to change their position setting from where they really want to put it (i.e. under a person) to adapt with the width of the text inside the cue.

The important step that positionAlign takes is to separate the alignment of text from the alignment of the box that the text is rendered into. This is a fundamental property of positioned captions and should not have to wait until "v2".

(In reply to Silvia Pfeiffer from comment #34)
> (In reply to Philip Jägenstedt from comment #33)
> > If we're back to positionAlign as syntactic sugar as opposed to the use case
> > in comment 25,
> 
> Comment 25 indeed needs a solution and I think it's by defining the "cue
> box" that I've been using in the spec as the bounding box of the line boxes
> within a cue. When size is "auto", then the width of the cue box is used for
> size. Then positionAlign=middle with align=left and size=auto will do
> exactly what Loretta is after.

Can you file a new bug if you want to solve that use case? I don't think it makes sense to make it depend on size "auto" since then you can't also use size to prevent overlap with on-screen content.

> > Most captions are going to use
> > the same text alignment for all cues, and setting the size at all is
> > something you should only do when avoiding overlap.
> 
> When explicitly positioning a cue box, it's for the reasons Loretta
> outlines: putting text under a particular person or a particular spot. So,
> one typically defines a box to render text into. Then the text is added into
> this box. Without an auto size, you have explicitly specify the width before
> you can do a centered cue box, but with left or right aligned text. So, you
> would do: position="the middle position under the person",
> positionAlign=middle, align=left, size="width of the largest line". At
> least, you are able to calculate this positioning roughly when authoring. I
> assume that's what Loretta has to do right now because we don't have the cue
> box size "auto" be the width of the bounding boxes. positionAlign is a step
> towards solving this problem. Taking it away is a step backwards.

I've outlined how I would solve the problem in comment #27 in way which doesn't depend on positionAlign and which would degrade better when the new setting isn't supported. I would basically be position="the middle position under the person", textalign="left". The default align (middle) and size (100) would work.

> > Only rather advanced
> > authors would run into the problems you describe, and they are easy to work
> > around manually or with tooling.
> 
> Basically every author that uses position runs into this problem for the
> reasons outlined above. Let's resolve the bounding box issues as part of
> this problem rather than going back to where we weren't even able to
> position a cue box at a fixed left border with middle aligned text in it.
> 
> > If positionAlign were a new request, I would say "v2" and wait to see what
> > happens in the wild.
> 
> We've already seen what happens in the wild. People have to specify size to
> get around the problem and they have to change their position setting from
> where they really want to put it (i.e. under a person) to adapt with the
> width of the text inside the cue.
> 
> The important step that positionAlign takes is to separate the alignment of
> text from the alignment of the box that the text is rendered into. This is a
> fundamental property of positioned captions and should not have to wait
> until "v2".

If you transform positionAlign into something to solve comment #25 then we can discuss if it's v1 or v2. As currently spec'd it doesn't solve any new use case at all, and so I'm not interested in keeping it in the spec or in seeing it implemented.

(In reply to Philip Jägenstedt from comment #35)
> (In reply to Silvia Pfeiffer from comment #34)
> > (In reply to Philip Jägenstedt from comment #33)
> > > If we're back to positionAlign as syntactic sugar as opposed to the use case
> > > in comment 25,
> > 
> > Comment 25 indeed needs a solution and I think it's by defining the "cue
> > box" that I've been using in the spec as the bounding box of the line boxes
> > within a cue. When size is "auto", then the width of the cue box is used for
> > size. Then positionAlign=middle with align=left and size=auto will do
> > exactly what Loretta is after.
> 
> Can you file a new bug if you want to solve that use case? I don't think it
> makes sense to make it depend on size "auto" since then you can't also use
> size to prevent overlap with on-screen content.

See bug 25660 .



> I've outlined how I would solve the problem in comment #27 in way which
> doesn't depend on positionAlign and which would degrade better when the new
> setting isn't supported. I would basically be position="the middle position
> under the person", textalign="left". The default align (middle) and size
> (100) would work.

I don't think your proposal works. In your example, the box's left edge is positioned under the middle of the person and not the middle of the box. You need a way to differentiate the box alignment from the text alignment, which is what positionAlign does.

After discussing this on IRC, the conclusion was that the only thing that positionAlign was ever intended to do is the use case in comment #25. I've filed a separate bug for that and decoupled this bug from the positionAlign removal:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26020
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26021

The default position is not 50% any more, but adjusts to the setting of align. I am closing this bug.