This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The %-based positioning mechanism needs redesigning. (The snap-to-lines feature, for the line dimension, is out of scope for this bug.)
*** Bug 15859 has been marked as a duplicate of this bug. ***
*** Bug 18769 has been marked as a duplicate of this bug. ***
*** Bug 18501 has been marked as a duplicate of this bug. ***
*** Bug 19178 has been marked as a duplicate of this bug. ***
Seems to me that (assuming horizontal ltr cues)... align:middle position:25% line:25% size:25% should appear with the cue from 25% to 50% of the way across, with the cue 25% of the way down, either vertically centered over 25% or (probably better) with the 25% point vertically aligned at 25%. align:right should be a right-aligned full-width cue align:right position:10% should be right-aligned with the right edge 90% across from the left align:start position:100% no idea what this should do. Nothing useful? align:start position:50% should be left-aligned half-way across align:middle position:50% should be centered between 50% and 100% from the left align:start size:25% should be left-aligned between 0% and 25% from the left align:right size:75% should be right-aligned between 25% and 100% from the left align:middle size:20% should be middle-aligned between 40% and 60% from the left
Proposal: - Default is: size:100% position:0% align:middle - First the cue is positioned: For left, ltr start, and rtl end horizontal cues: Text position percentages measure from the left. Anchor point is the left edge of the cue. For right, rtl start, and ltr end horizontal cues: Text position percentages measure from the right. Anchor point is the right edge of the cue. For middle horizontal cues: Text position percentages measure from the left. Anchor point is in the horizontal middle of the cue. For left and start vertical cues: Percentages measure from the top. Anchor point is the top of the cue. For right and end vertical cues: Percentages measure from the bottom. Anchor point is the bottom of the cue. For middle vertical cues: Percentages measure from the top. Anchor point is the vertical middle of the cue. - If the cue doesn't fit at the given position given its specified size, the cue is truncated so that it doesn't overlap the edge it is overlapping. (So e.g. align:left position:1% size:100% is treated as size:99%.) - Line positioning for horizontal cues measures from the top. Line positioning for vertical-lr cues measures from the left. Line positioning for vertical-rl cues measures from the right. - The line position anchor point for percentage positions is the same percentage down the cue as the percentage anchor point (so 0% puts the top at the top and 100% puts the bottom at the bottom). I *think* this handles all the cases in the previous comment except the last one (align:middle size:20%), which ends up covering 0% to 20% from the left. Maybe specifying align:middle should override the default position somehow? Maybe set it to 50%-size/2 ?
(In reply to comment #5) > Seems to me that (assuming horizontal ltr cues)... > > align:middle position:25% line:25% size:25% > should appear with the cue from 25% to 50% of the way across, with > the cue 25% of the way down, either vertically centered over 25% or > (probably better) with the 25% point vertically aligned at 25%. Did you mean horizontally here? I can see from the proposal in #6 that you are horizontally aligning the text in the center of the cue, with which I agree. What should happen to the text vertically (still assuming a horizontal cue)? Would the top of the line be at 25% down? Or the middle of the text for "middle" aligned cues? I'm asking because how would you specify a cue that should always be smack bang in the middle of the video no matter how much text is in it. > align:right > should be a right-aligned full-width cue Agree. > align:right position:10% > should be right-aligned with the right edge 90% across from the left Agree. > align:start position:100% > no idea what this should do. Nothing useful? Yes, author error for positioning off the right edge of the video. > align:start position:50% > should be left-aligned half-way across Agree. > align:middle position:50% > should be centered between 50% and 100% from the left Agree. > align:start size:25% > should be left-aligned between 0% and 25% from the left Agree. > align:right size:75% > should be right-aligned between 25% and 100% from the left Agree. > align:middle size:20% > should be middle-aligned between 40% and 60% from the left Agree. See my note above: you may also need to say something special about what to do with the vertical position of this.
Looks generally good. Some selective questions. (In reply to comment #6) > Proposal: > > - Default is: size:100% position:0% align:middle Should position not rather be in the middle by default? position:50% Also, we should by default put cues at the bottom of the video? That would be something like: line:100% - cue height ? > - If the cue doesn't fit at the given position given its specified size, the > cue is truncated so that it doesn't overlap the edge it is overlapping. > (So e.g. align:left position:1% size:100% is treated as size:99%.) Nice. However, size adjustments can only be made if they make sense. e.g. align:left position:100% size:50% will not work for any size adjustment. > - The line position anchor point for percentage positions is the same > percentage > down the cue as the percentage anchor point (so 0% puts the top at the top > and > 100% puts the bottom at the bottom). This probably addresses my concern from comment #7. This also means we should be able to specify: - Default is: size:100% position:50% align:middle line:50% > I *think* this handles all the cases in the previous comment except the last > one (align:middle size:20%), which ends up covering 0% to 20% from the left. > > Maybe specifying align:middle should override the default position somehow? > Maybe set it to 50%-size/2 ? Since you have defined that for "align: middle" the "Anchor point is in the horizontal middle of the cue." isn't "position" calculated as the middle of the cue already, so we only need "position:50%" and not "position:50%-size/2"?
(In reply to comment #8) > > - Default is: size:100% position:50% align:middle line:50% sorry: should be "line:100%"
(In reply to comment #5) > Seems to me that (assuming horizontal ltr cues)... > > align:middle position:25% line:25% size:25% > should appear with the cue from 25% to 50% of the way across, with > the cue 25% of the way down, either vertically centered over 25% or > (probably better) with the 25% point vertically aligned at 25%. I can handle the position for align:middle either specifying the midpoint or the left point of the cue. > > align:right > should be a right-aligned full-width cue Agreed. > > align:right position:10% > should be right-aligned with the right edge 90% across from the left I find this more confusing than specifying the right edge but continuing to measure from the left (for ltr). I would rather see this specified as position:90%. We already change the interpretation of the percentage based on language direction. The more factors that go into the interpretation, the harder it is to understand and use reliably. > > align:start position:100% > no idea what this should do. Nothing useful? Agreed. > > align:start position:50% > should be left-aligned half-way across Agreed. > > align:middle position:50% > should be centered between 50% and 100% from the left Agreed. > > align:start size:25% > should be left-aligned between 0% and 25% from the left Agreed. > > align:right size:75% > should be right-aligned between 25% and 100% from the left Agreed. > > align:middle size:20% > should be middle-aligned between 40% and 60% from the left Yes, but this probably argues for interpreting the position for align:middle as the midpoint.
(In reply to comment #6) > Proposal: > > - Default is: size:100% position:0% align:middle See my previous comments: I think percentage values should always be interpreted as from the left for ltr text and as from the right for rtl text. Anchor points should change with the alignment. > > - First the cue is positioned: > For left, ltr start, and rtl end horizontal cues: > Text position percentages measure from the left. > Anchor point is the left edge of the cue. > For right, rtl start, and ltr end horizontal cues: > Text position percentages measure from the right. > Anchor point is the right edge of the cue. > For middle horizontal cues: > Text position percentages measure from the left. > Anchor point is in the horizontal middle of the cue. > For left and start vertical cues: > Percentages measure from the top. > Anchor point is the top of the cue. > For right and end vertical cues: > Percentages measure from the bottom. > Anchor point is the bottom of the cue. > For middle vertical cues: > Percentages measure from the top. > Anchor point is the vertical middle of the cue. > > - If the cue doesn't fit at the given position given its specified size, the > cue is truncated so that it doesn't overlap the edge it is overlapping. > (So e.g. align:left position:1% size:100% is treated as size:99%.) > > - Line positioning for horizontal cues measures from the top. > Line positioning for vertical-lr cues measures from the left. > Line positioning for vertical-rl cues measures from the right. > - The line position anchor point for percentage positions is the same > percentage > down the cue as the percentage anchor point (so 0% puts the top at the top > and > 100% puts the bottom at the bottom). This kind of works for 0% and 100%, but becomes hopelessly confusing for everything else. If I want to position a cue so that the top of the cue is at 20%, it is impossible to determine what position value to use; it will depend on the height of the cue, hence on the font size. Please separate the position information from the anchor information (just as we do horizontally with position and alignment. > > I *think* this handles all the cases in the previous comment except the last > one (align:middle size:20%), which ends up covering 0% to 20% from the left. I think we can only accomplish this by specifying that for align:middle, the position is the anchor point rather than the left edge. > > Maybe specifying align:middle should override the default position somehow? > Maybe set it to 50%-size/2 ?
(In reply to comment #8) > Looks generally good. Some selective questions. > > (In reply to comment #6) > > Proposal: > > > > - Default is: size:100% position:0% align:middle > > Should position not rather be in the middle by default? position:50% 0% makes sense if the position for align:middle specifies the left edge; 50% makes sense if it specifies the anchor point. I think this highlights that it may be impossible to specify a set of defaults that always produces the intuitive result when just one or two of the attributes is specified. > > Also, we should by default put cues at the bottom of the video? That would > be something like: line:100% - cue height ? > > > > - If the cue doesn't fit at the given position given its specified size, the > > cue is truncated so that it doesn't overlap the edge it is overlapping. > > (So e.g. align:left position:1% size:100% is treated as size:99%.) > > Nice. However, size adjustments can only be made if they make sense. > e.g. align:left position:100% size:50% will not work for any size adjustment. > > > - The line position anchor point for percentage positions is the same > > percentage > > down the cue as the percentage anchor point (so 0% puts the top at the top > > and > > 100% puts the bottom at the bottom). > > This probably addresses my concern from comment #7. This also means we > should be able to specify: > > - Default is: size:100% position:50% align:middle line:50% > > > > I *think* this handles all the cases in the previous comment except the last > > one (align:middle size:20%), which ends up covering 0% to 20% from the left. > > > > Maybe specifying align:middle should override the default position somehow? > > Maybe set it to 50%-size/2 ? > > Since you have defined that for "align: middle" the > "Anchor point is in the horizontal middle of the cue." > isn't "position" calculated as the middle of the cue already, so we only > need "position:50%" and not "position:50%-size/2"?
My recollection is that people prefer that position works the same regardless of alignment. That disagrees with: (In reply to comment #5) > align:right position:10% > should be right-aligned with the right edge 90% across from the left If we want to decouple alignment and positioning, we might have to introduce a setting for the anchor point (has been proposed before) or have two settings for positioning (e.g. 'start' and 'end').
Having more settings seems even worse than coupling them.
Here is a new proposal that should simplify all this. We have to deal with the idea of an "anchor point", but we can make it implicit rather than explicitly set. If anybody wants more flexibility in anchoring text at certain points within a rendering block, they can already do that by defining a region. My proposal is as follows (always assuming horizontal ltr cues): * the setting of "align" implicitly defines the "anchor point" for the text: for left align it's the start of the text, for middle it's the center of the text, for right align it's the end of the text * the position of that "anchor point" can be manipulated by the "position" setting; the default position setting is different depending on alignment: left aligned text has implied position=0%, middle aligned text position=50% and right aligned text position=100% * the width of the cue (the "size" setting) is always defined as a percentage of video width * if positioning, size and alignment happen to make text disappear off the edge of the video, then this an authoring error and it just overflows hidden (such as: left aligned text positioned at 100%) * the width is not auto-corrected (e.g. a 50% wide cue left aligned at 80% will only have the first 20% part visible) in case this is part of a page where the author wants to make the text overlap onto the page in a controlled way (and possibly change the text-overflow property to "visible") * default is: align:middle (which implies position:50%) size:100% Line positioning is orthogonal to this, but here is how I view that: * percentage line positioning y%: has the point at y% of the cue text height coinciding with the point at y% of the video height (anchoring the cue in the opposite direction to position) * default is: line:100% (which positions the cue's bottom text row at the bottom of the video) Here are some example results of this: no settings: cue is middle aligned at the bottom, the text center is positioned in the middle (implied: position:50%), and the text uses the full video width to be rendered size:50% cue is middle aligned at the bottom, the text center is positioned in the middle, and the text uses 50% of video width to be rendered align:start cue is left aligned at the bottom, the text start is positioned at the left (implied: position:0%), and the text uses the full video width to be rendered align:end size:50% cue is right aligned at the bottom, the text end is positioned at the right (implied: position:100%), and the text uses 50% of the video width to be rendered (i.e. from middle to right edge) align:start position:25% cue is left aligned at the bottom, the text start is positioned at 25% video width from the left, and the text uses 100% of video width to be rendered (i.e. a quarter is potentially invisible off-viewport) align:end position:75% size:50% cue is right aligned at the bottom, the text end is positioned at 75% video width from the left, and the text uses 50% of video width to be rendered (i.e. the middle of the video) align:middle position:25% cue is middle aligned at the bottom, the text middle is positioned at 25% video width from the left, and the text uses 100% of video width to be rendered (i.e. a quarter is potentially invisible off-viewport) align:middle position:25% line:25% size:25% cue is middle aligned, the text middle is positioned at 25% video width from the left, the text uses 25% of the video width around middle point, and the cue is positioned 25% from the top of the screen (the 25% mark being anchored at 25% of its height)
*** Bug 22016 has been marked as a duplicate of this bug. ***
I like this proposal. I think it is more intuitive. I If I am interpreting it correctly, the use of align:start vs align:left will be the same for ltr languages, but different for rtl languages. This lets the author determine which is more appropriate or easier to work with. For example, if text will be translated between rtl and ltr languages, the use of align:left and align:right means that only the text, and not the cue values, needs to be changed. I still find the interpretation of percentage line positioning hard to work with: "percentage line positioning y%: has the point at y% of the cue text height coinciding with the point at y% of the video height (anchoring the cue in the opposite direction to position)" The fact that the anchor point changes with the line position value makes it difficult to determine, for instance, what line position to use when converting 608 PAC addresses. It is no longer the values listed in the table in https://dvcs.w3.org/hg/text-tracks/raw-file/default/608toVTT/608toVTT.html, since those values should be the position of the top of the row. They would need to be adjusted to compensate for the adjustment that will be made to the anchor position. I don't have any great solutions to this. It would be easier, if less elegant, just to pick an anchor position, such as the top of the line. This would make it harder to describe the default position at the bottom of the viewport, since you would need to know the line height. Alternatively, there could be another cue setting to control vertical anchor position. The current behavior could be the default, but there would be a way to set a fixed anchor point for situations where that is clearer.
(In reply to comment #17) > > If I am interpreting it correctly, the use of align:start vs align:left will > be the same for ltr languages, but different for rtl languages. This lets > the author determine which is more appropriate or easier to work with. For > example, if text will be translated between rtl and ltr languages, the use > of align:left and align:right means that only the text, and not the cue > values, needs to be changed. Correct. BTW: that was in the spec beforehand already. > I still find the interpretation of percentage line positioning hard to work > with: "percentage line positioning y%: has the point at y% of the cue text > height coinciding with the point at y% of the video height (anchoring the > cue in the opposite direction to position)" Yes, I struggled with the line positioning and it's not consistent with https://dvcs.w3.org/hg/text-tracks/raw-file/default/608toVTT/608toVTT.html . > I don't have any great solutions to this. It would be easier, if less > elegant, just to pick an anchor position, such as the top of the line. This > would make it harder to describe the default position at the bottom of the > viewport, since you would need to know the line height. I wanted to make line position=0% be top aligned and line position=100% be bottom aligned. I can't think of a simple way to achieve this other than what I proposed. > Alternatively, there could be another cue setting to control vertical anchor > position. The current behavior could be the default, but there would be a > way to set a fixed anchor point for situations where that is clearer. Maybe we can make the top of the box the anchor point for line settings smaller than 50%, the middle for 50% and the bottom for line settings larger than 50%?
> > Alternatively, there could be another cue setting to control vertical anchor > > position. The current behavior could be the default, but there would be a > > way to set a fixed anchor point for situations where that is clearer. > > Maybe we can make the top of the box the anchor point for line settings > smaller than 50%, the middle for 50% and the bottom for line settings larger > than 50%? Or perhaps we should use the same hack as line numbers and interpret positive and negative percentage values differently. Positive percentage values are anchored to the top of the cue and negative percentage values are anchored to the bottom. This wouldn't give you 100% meaning bottom aligned, but -100% would.
(In reply to comment #19) > > Or perhaps we should use the same hack as line numbers and interpret > positive and negative percentage values differently. Positive percentage > values are anchored to the top of the cue and negative percentage values are > anchored to the bottom. This wouldn't give you 100% meaning bottom aligned, > but -100% would. Nice idea. If we do this, I would turn it around, though. I'd make the positive numbers anchor at the bottom of the text box and the negative at the top, so we have a default line:100% position.
LGTM (comment 15 + comment 20)
Awesome, thanks for the feedback. I'll specify it in the next few days and prepare a draft for review.
(In reply to comment #21) > LGTM (comment 15 + comment 20) This looks good to me as well.
I've staged changes to the text positioning in dvcs: https://dvcs.w3.org/hg/text-tracks/raw-file/default/webvtt/webvtt.html This was quite a big patch, so do give the new rendering algorithm at https://dvcs.w3.org/hg/text-tracks/raw-file/default/webvtt/webvtt.html#processing-model a good read. I have not yet addressed the line dimension, which should go into a separate bug anyway.
This looks good. I am a little puzzled by +/- percentages for height. If +ve numbers anchor the bottom, and -ve the top, and positive measure down from the top, and negative up from the bottom -- what happens with zero, which is neither? Line numbers have line 0 as the line that has its top at the top of the screen, but the percentage numbers don't depend on line height, so it would logically mean that if zero is non-negative, the bottom of the text is at the top of the screen, and if it's non-positive, the top of the text at the bottom of the screen -- neither very helpful.
Indeed 0% would mean outside the viewport regardless of whether we say it's positive or negative (we could support both but since it makes no difference...). One thing that seems impossible to do is position text vertically centered, since the anchor point can't be in the middle of the cue.
Indeed. The negative percentages just doesn't seem right. That's why I haven't made the change yet. So, I'm wondering if we should rather introduce an explicit setting for anchoring the line position. How about a new cue setting that allows us to specify top/middle/bottom of a cue box as the offset point for line positions? Default would be "bottom", so it's backwards compatible with the default 100% line position. Now about the name... cue-offset? box-offset? line-align? cross-align (as in: cross-axis to the align feature)? line-anchor? I don't really like any of them - any better suggestions around?
(In reply to comment #27) > Default would be "bottom", so it's backwards compatible with the > default 100% line position. I thought the default was -1 with snap-to-lines set, not 100%. If you want backcompat with the current behavior, there should probably be a way to get the current behavior, maybe call that value "auto".
(In reply to comment #28) > (In reply to comment #27) > > Default would be "bottom", so it's backwards compatible with the > > default 100% line position. > > I thought the default was -1 with snap-to-lines set, not 100%. > > If you want backcompat with the current behavior, there should probably be a > way to get the current behavior, maybe call that value "auto". Good idea. Any preferences for naming the new cue setting?
We're thinking again on this one, and here is an alternative that we'd like to explore. We also think we should explore compatibility with: * the current spec. * the ways people have understood/implemented the current spec. * the Region definition * the way CSS does positioning * the way TTML does positioning * the way 608 does positioning Overall, we don't think we should tie the determination of the text BOX to the alignment of text WITHIN the box. So, position and size should determine the 'horizontal' box, and then the text should be aligned within it. This seems compatible with at least CSS and probably TTML etc. The simplest is that the position is the left-offset (for horizontal text) or top (for vertical text). The size (width) should default to 100%-position. (The default position would then be 0%, and align middle as now). examples: centered text that fills the screen (all defaults): (with position: 0% size: 100% align: center as default) left-aligned text across the whole screen: align: left (with position: 0% size: 100% as default) right-aligned text: align: right (with position: 0% size: 100% as default) getting a 10% margin on each side: position: 10% size: 80% (any alignment is possible) Now, maybe for better backward compatibility, we need position to be the mid-point, so the box extends from position-(size/2) to position+(size/2), rather than from position to position+size. The default size would then need to be 2*min(position, 100-position). Is this easier to understand, implement (esp. if using a CSS layout engine), etc.?
David, how are you suggesting that the position percentage work? Is it the position of the left (for LTR) edge of the text box (like left in CSS) or is it a scale from 0% to 100% where 100% align the right (for LTR) edge of the text box with the right edge of the container (like background-position and object-position in CSS). It looks like you mean the former, but did you consider the pros and cons of making it more like background-position? When I was working with WebVTT I was a bit annoyed with having to change both position and size when wanting to (e.g.) change the width of a right-aligned box.
(In reply to comment #31) > David, how are you suggesting that the position percentage work? Is it the > position of the left (for LTR) edge of the text box (like left in CSS) or is > it a scale from 0% to 100% where 100% align the right (for LTR) edge of the > text box with the right edge of the container (like background-position and > object-position in CSS). I am not sure that we have nearly enough boxes/concepts in VTT to make a big difference here. But I envisaged it to be like 'left'. > > It looks like you mean the former, but did you consider the pros and cons of > making it more like background-position? When I was working with WebVTT I > was a bit annoyed with having to change both position and size when wanting > to (e.g.) change the width of a right-aligned box. Ah, right. That ought to be easy, and what we wrote meant you had to think. So, the obvious fix is to allow negative position values, which position the opposite edge: so position: 10% -- left edge at 10% position: -10% -- right edge at 10% position: 10% vertical: rl|lr -- top is 10% down position: -10% vertical: rl|lr -- bottom is 10% up default size then has to be 100% - abs(position). If using CSS as a layout engine, these tell you whether to translate to left, right, top, or bottom. I hope it makes other translations easy as well.
(In reply to comment #32) > (In reply to comment #31) > > David, how are you suggesting that the position percentage work? Is it the > > position of the left (for LTR) edge of the text box (like left in CSS) or is > > it a scale from 0% to 100% where 100% align the right (for LTR) edge of the > > text box with the right edge of the container (like background-position and > > object-position in CSS). > > I am not sure that we have nearly enough boxes/concepts in VTT to make a big > difference here. But I envisaged it to be like 'left'. > > > > > It looks like you mean the former, but did you consider the pros and cons of > > making it more like background-position? When I was working with WebVTT I > > was a bit annoyed with having to change both position and size when wanting > > to (e.g.) change the width of a right-aligned box. > > Ah, right. That ought to be easy, and what we wrote meant you had to think. > So, the obvious fix is to allow negative position values, which position the > opposite edge: Unless the parser remembers the negative in -0%, how would you align with the right edge in this model?
"Unless the parser remembers the negative in -0%, how would you align with the right edge in this model?" How about we also allow -ve sizes? That would mean that the box extends "the other way" from the indicated position (e.g. to the left, rather than to the right). So: position: 10% size: 50% -- a box 10% from the left edge, extending to 60% position: -10% size: -40% -- a box at 90%, with left edge at 50% position: 100% size: -50% -- what you were asking for and similarly for vertical?
I shoulda said, that -ve sizes are an alternative, as zero size doesn't happen.
(In reply to David Singer from comment #30) > We're thinking again on this one, and here is an alternative that we'd like > to explore. We also think we should explore compatibility with: > > > * the current spec. > * the ways people have understood/implemented the current spec. > * the Region definition > * the way CSS does positioning > * the way TTML does positioning > * the way 608 does positioning > > Overall, we don't think we should tie the determination of the text BOX to > the alignment of text WITHIN the box. So, position and size should > determine the 'horizontal' box, and then the text should be aligned within > it. This seems compatible with at least CSS and probably TTML etc. > > > The simplest is that the position is the left-offset (for horizontal text) > or top (for vertical text). The size (width) should default to > 100%-position. (The default position would then be 0%, and align middle as > now). > > examples: > > centered text that fills the screen (all defaults): > (with position: 0% size: 100% align: center as default) > > left-aligned text across the whole screen: > align: left (with position: 0% size: 100% as default) > > right-aligned text: > align: right (with position: 0% size: 100% as default) > > getting a 10% margin on each side: > position: 10% size: 80% (any alignment is possible) You're using only simple examples. Try specifying right-aligned text that is positioned 10% off the right edge. Try specifying middle-aligned text at the 30% marker using 30% of the video width. > Is this easier to understand, implement (esp. if using a CSS layout engine), > etc.? The proposed solution in #c15 is not easier or harder to implement in CSS than your proposal. But it satisfies the CEA608/708 use cases and user expectations.
(In reply to Silvia Pfeiffer from comment #36) > > You're using only simple examples. > > Try specifying right-aligned text that is positioned 10% off the right edge. OK, as we say, the *position* extent of the box should have no relationship to the alignment of the text within it. A box size:50% position:60% will be 10% off the right edge, and if you say align:right then the text will start 10% past the right edge. > > Try specifying middle-aligned text at the 30% marker using 30% of the video > width. position: 35% size: 30% and then choose whatever alignment you like in that; align: middle gets the effect you want. > > > > Is this easier to understand, implement (esp. if using a CSS layout engine), > > etc.? > > The proposed solution in #c15 is not easier or harder to implement in CSS > than your proposal. But it satisfies the CEA608/708 use cases and user > expectations. But c15 ties positioning to text alignment, which causes serious issues. Imagine, for example, you are translating captions from english to hebrew. You're captioning an interview, with two people on screen, one on the left, and one on the right. That caption boxes are positioned under the correct person. The natural thing to do is to translate the text, and since hebrew flows right to left, change the places which have align: left to align: right. In the c15 proposal, that will flip the two boxes to the other sides of the screen, so the captions are now under the wrong person. This is wrong.
(In reply to David Singer from comment #37) > The natural thing to do is to translate the text, and since hebrew flows > right to left, change the places which have align: left to align: right. In > the c15 proposal, that will flip the two boxes to the other sides of the > screen, so the captions are now under the wrong person. This is wrong. I didn't realize that comment 15 already has the semantics of position that I have been wanting. Silvia, can you confirm that it's intended to be like background-position and object-position? To fix the Hebrew translation problem, can't we simply make position always behave like it does in CSS, i.e. having no relation to the text direction?
(In reply to Silvia Pfeiffer from comment #15) I don't think text alignment being tied to the position of the box makes sense. I think it makes most sense to specify a box with position + size and then have a text-alignment in that box of whatever, not related. I think this is a more intuitive way. It's the same way it's done in CSS. (In reply to David Singer from comment #30) I like this suggestion. We can just make -0% an invalid value in the parser to deal with it.
OK, it looks like we're converging. Let me try to summarize. Rather than using negative offsets, since -0% is hard to propagate, I suggest negative sizes, since we don't care which way you think a size of 0 extends, since it doesn't extend, and it doesn't matter whether it's x% from the left or right edge, since you can't see it. position: x% size: y% 4 cases: y +ve, orientation is default horizontal: x is the distance from the left edge of the area to the left edge of the text box; y is the distance the text box extends to the right from there y -ve, orientation is default horizontal: x is the distance from the right edge of the area to the right edge of the text box; abs(y) is the distance the text box extends to the left from there y +ve, orientation vertical: x is the distance from the top edge of the area to the top edge of the text box; y is the distance the text box extends downwards from there y -ve, orientation vertical: x is the distance from the bottom edge of the area to the bottom edge of the text box; abs(y) is the distance the text box extends upwards from there you may now align: as you like within that defined box. This has positioning independent of text direction, as in CSS etc. and is easily mapped to CSS etc.
(In reply to David Singer from comment #40) > OK, it looks like we're converging. Let me try to summarize. > > Rather than using negative offsets, since -0% is hard to propagate, I > suggest negative sizes, since we don't care which way you think a size of 0 > extends, since it doesn't extend, and it doesn't matter whether it's x% from > the left or right edge, since you can't see it. > > position: x% size: y% > > 4 cases: > y +ve, orientation is default horizontal: > x is the distance from the left edge of the area to the left edge of > the text box; > y is the distance the text box extends to the right from there > y -ve, orientation is default horizontal: > x is the distance from the right edge of the area to the right edge of > the text box; > abs(y) is the distance the text box extends to the left from there > > y +ve, orientation vertical: > x is the distance from the top edge of the area to the top edge of the > text box; > y is the distance the text box extends downwards from there > y -ve, orientation vertical: > x is the distance from the bottom edge of the area to the bottom edge > of the text box; > abs(y) is the distance the text box extends upwards from there > > you may now align: as you like within that defined box. This has > positioning independent of text direction, as in CSS etc. and is easily > mapped to CSS etc. I'm not sure if having position interpreted by whether or not size is negative or positive is a good idea. That seems to me like it might cause confusion. Why not just always have position be the percentage from the left or top edges of the area to where the box will extend from. If the size is negative in a horizontal orientation the position is the distance from the left edge of the box to the right edge of the area: position: x% size: y% orientation horizontal y -ve x is the distance from the left edge of the box to the right edge of the area and size extends to the left from there. y +ve x is the distance from the left edge of the box to the left edge of the area and size extends to the right from there The same would go for vertically oriented boxes. This is clearer because you don't have to worry about flipping the reference point for position if you switch size to negative. Position is always a percentage value from the left or top and size extends negatively or positively from there.
What would we do for values that when computed extend over the rendering area? For example: position:90% size:30% left: 90vw, width:30vw Would we cut the box off at the right edge of the area or let it continue over the edge? I'm partial to just clipping the text at the edge of the area like has been suggested before.
(In reply to Rick Eyre from comment #42) > What would we do for values that when computed extend over the rendering > area? > > For example: > > position:90% size:30% > > left: 90vw, width:30vw > > Would we cut the box off at the right edge of the area or let it continue > over the edge? I'm partial to just clipping the text at the edge of the area > like has been suggested before. In #c15 I suggested: * if positioning, size and alignment happen to make text disappear off the edge of the video, then this an authoring error and it just overflows hidden (such as: left aligned text positioned at 100%) In #32 David seems to also agree with that. It has the advantage of exactly knowing where the text will appear and as a clever Web Dev you can make some fancy designs with text continuations off the side of the video. I just added this in https://dvcs.w3.org/hg/text-tracks/raw-file/default/webvtt/webvtt.html#applying-css-properties-to-webvtt-node-objects to the WebVTT cue background box, since I only had that for regions.
(In reply to David Singer from comment #37) > (In reply to Silvia Pfeiffer from comment #36) > > > You're using only simple examples. > > > > Try specifying right-aligned text that is positioned 10% off the right edge. > > OK, as we say, the *position* extent of the box should have no relationship > to the alignment of the text within it. A box size:50% position:60% will be > 10% off the right edge, and if you say align:right then the text will start > 10% past the right edge. With "off" I meant: 10% within the video from the right edge. With your logic, I assume it would be align:right position:-10% or align:right size:90% position:0%. With my proposal, you would do: align:right position:90%. > > Try specifying middle-aligned text at the 30% marker using 30% of the video > > width. > > position: 35% size: 30% and then choose whatever alignment you like in > that; align: middle gets the effect you want. IIUC with your logic, that does not center the text around the 30% mark, but around the 50% mark. You probably want position:15% size:30% align:middle ? But isn't it more obvious to say: align:middle position:30% size:30% (exactly following the text of the requested placement)? With my spec you don't even need to provide a size - just say position:30% align:middle, which is even more natural, and because align:middle is default, you only need to say position:30%. Here is another one: the example in the spec has a cue that has "align:end size:50%" . The implicit user assumption is that the box would be aligned at the end of the video viewport. With my implicit position:100% , that would happen, but in your case, you would position this cue within the first 50% of the video's width (since position:0%), which isn't really what users would expect. The issues that my approach deals better with are the lack of specification of "size" and the implicit expectation of users that right alignment means alignment to the right edge of the video viewport. > But c15 ties positioning to text alignment, which causes serious issues. > Imagine, for example, you are translating captions from english to hebrew. > You're captioning an interview, with two people on screen, one on the left, > and one on the right. That caption boxes are positioned under the correct > person. > > The natural thing to do is to translate the text, and since hebrew flows > right to left, change the places which have align: left to align: right. The text in the cue already is internationalized, so will automatically flow from the other edge of the box if you use align:start . That would be more appropriate and less effort for the author in this case. > In > the c15 proposal, that will flip the two boxes to the other sides of the > screen, so the captions are now under the wrong person. This is wrong. Right. I think you have a point - I didn't intend a change of position to be necessary for internationalizing text. Let's see if we can fix that. If we separate the text directionality from the align setting, i.e. change the align setting from referring to the text anchoring to referring to a box anchoring, I think that would work. I believe that's the same proposal that Philip made in #c38 . BTW: the way CSS background-position works was exactly as we had it before and that caused problems, because in contrast to background images, text can be left, middle or right aligned within its box. We need all the 0-100% positions of background position at work for all 3 positions of the box. So, we need text directionality to work independent of position. E.g., a start aligned text box can still have rtl text aligned at the right edge of the box, but with box anchoring at the left edge.
(In reply to Silvia Pfeiffer from comment #15) I've been looking at this and there is a problem. How do you detect when a position has been requested vs when it hasn't (since we have defaults): align:left positioning:50% (box will start at position 50% and extend to the left from there with half of it invisible off the viewport) align:left (implied positioning 100% box will extend from there to the left the full width of the video) These two cases from looking at the settings after being parsed are indistinguishable, but they behave in different ways.
Wait disregard this. I see that you've updated the text position to have default positions based on the alignment.
To check my proposed changes, please read https://dvcs.w3.org/hg/text-tracks/raw-file/default/webvtt/webvtt.html and not http://dev.w3.org/html5/webvtt/
(In reply to Silvia Pfeiffer from comment #47) > To check my proposed changes, please read > https://dvcs.w3.org/hg/text-tracks/raw-file/default/webvtt/webvtt.html and > not http://dev.w3.org/html5/webvtt/ If the default text position is dependent on the alignment and paragraph direction of the cue then we'll have to know the paragraph direction at the time of setting the default values. Right now the paragraph direction is only computed when the processing model runs which is after the default position has been set. (In reply to Silvia Pfeiffer from comment #44) > If we separate the text directionality from the align setting, i.e. change > the align setting from referring to the text anchoring to referring to a box > anchoring, I think that would work. I believe that's the same proposal that > Philip made in #c38 . IIUC this will solve the above problem?
(In reply to Rick Eyre from comment #48) > (In reply to Silvia Pfeiffer from comment #47) > > To check my proposed changes, please read > > https://dvcs.w3.org/hg/text-tracks/raw-file/default/webvtt/webvtt.html and > > not http://dev.w3.org/html5/webvtt/ > > If the default text position is dependent on the alignment and paragraph > direction of the cue then we'll have to know the paragraph direction at the > time of setting the default values. Right now the paragraph direction is > only computed when the processing model runs which is after the default > position has been set. > > (In reply to Silvia Pfeiffer from comment #44) > > > If we separate the text directionality from the align setting, i.e. change > > the align setting from referring to the text anchoring to referring to a box > > anchoring, I think that would work. I believe that's the same proposal that > > Philip made in #c38 . > > IIUC this will solve the above problem? Indeed.
(In reply to Silvia Pfeiffer from comment #27) > Indeed. The negative percentages just doesn't seem right. That's why I > haven't made the change yet. > > So, I'm wondering if we should rather introduce an explicit setting for > anchoring the line position. How about a new cue setting that allows us to > specify top/middle/bottom of a cue box as the offset point for line > positions? Default would be "bottom", so it's backwards compatible with the > default 100% line position. > > Now about the name... cue-offset? box-offset? line-align? cross-align (as > in: cross-axis to the align feature)? line-anchor? > > I don't really like any of them - any better suggestions around? I've created a new bug for discussing the "line" positioning: bug 23404
I'm now looking at the outstanding problems of this bug voiced in #c30 , #c37 , #c38 , #c40 , #c41 , #c44 and I think we can move forward by integrating some of the ideas of David into what was proposed and spec-ed in #c15 . The key problem is that "align" currently does two things: * it provides an alignment point for the cue box at the "position" setting and * it aligns the text withing the cue box E.g. position:30% align:middle means: * middle of the cue box is at 30% of the video viewport * text is aligned in the middle David's suggestion to resolve this was to make positive position values align to the left end of the box and negative ones to the right end. However, that make it impossible to center a cue box with a position value around a certain point. Also, negative percentages seem unnatural. Here's a proposal: * make "align" refer to where to align the cue box with the "position" setting with values: left, middle, right * introduce a "text-align" setting (similar to CSS) - with values: left, center, right, justify, start, end I hate to have to introduce a new cue setting, but I think this is the cleanest approach.
My proposal would be: * make "position" behave like CSS background-position or object-position, so that it's not possible to have a combination of size and position that causes the box to extend outside the video viewport. This would make position:50% always center the box regardless of the size, and position 100% always right-align the box for LTR text. * make "align" refer to text alignment within the box only. Would this work, and if not, why not?
I can't remember where I originally posted this, but these two images illustrate one of the things which are broken about the current spec: http://people.opera.com/philipj/2012/08/webvtt/position-opera-next.png http://people.opera.com/philipj/2012/08/webvtt/position-opera-hack.png The first is per spec and the second is according to some change that I thought made sense at the time, but I don't remember what exactly it was...
(In reply to Philip Jägenstedt from comment #53) > I can't remember where I originally posted this, but these two images > illustrate one of the things which are broken about the current spec: > > http://people.opera.com/philipj/2012/08/webvtt/position-opera-next.png > http://people.opera.com/philipj/2012/08/webvtt/position-opera-hack.png > > The first is per spec and the second is according to some change that I > thought made sense at the time, but I don't remember what exactly it was... Right. The updated spec with the fix from comment has actually fixed this and is following your second picture.
(In reply to Philip Jägenstedt from comment #52) > My proposal would be: > > * make "position" behave like CSS background-position or object-position, so > that it's not possible to have a combination of size and position that > causes the box to extend outside the video viewport. This would make > position:50% always center the box regardless of the size, and position 100% > always right-align the box for LTR text. The combination of "position" and "line" when used with percentage values is identical to the old definition of these, with the x% position of the cue box being x% across from the video viewport width. This ends up causing the problems that I explained in comment 51. My proposal in comment 51 essentially extends the ability to exactly position to cue box through "position" and "line" by using the constants left/middle/right and top/middle/bottom as positions at which the "position" and "line" values are measures. This is different from background-position, where these are alternative positions to the percentage positions rather than providing additional flexibility. I think we need this because we don't have px based positioning and thus exact positioning of the top of the cue box is not possible otherwise. > * make "align" refer to text alignment within the box only. Right, I agree. In bug 23404, I now propose to keep "align" for text-alignment and use a new "cue-align" setting to provide the left/middle/right and top/middle/bottom cue box positioning points. So, the only changes that we need to make are the introduction of this cue-align setting, e.g. cue-align:middle,top , and some reformulations that ensure "align" has the meaning of CSS text-align.
Silvia (nessy) and I (foolip) discussed some of these issues on IRC today: http://krijnhoetmer.nl/irc-logs/whatwg/20131002#l-375 In summary, one (the only?) remaining issue is that of de-tangling the align property, which currently aligns both the cue box and the text within it. For text, there is only one dimension, and it can be expressed as a single start/center/end value. For the cue alignment together with percentages, one *might* want to specify an alignment point in both dimensions. If so, then there are two alignment properties here. There are many solutions which could express these three properties, here are some: 1. New text-align, vertical-align and horizontal-align properties, with the old align property simply mapping to these, like a shorthand property. 2. Keeping align for text alignment and adding new properties for cue alignment. 3. Keeping align for cue alignment and adding a new property for text alignment. 4. Stick with just a single align property, but make it a comma-separated list of values. For 2 and 3, maybe the defaults for the new properties should depend on the existing align property. It's not clear to me if the problem being solved is important enough to warrant this complexity, but there you have it :)
Here's another option: 5. Keep align for text alignment and add a second value (comma-separated) each to "position" and "line" (for percentage-values of line), which signifies the cue alignment. E.g. position:20%,left line:30%,top . Default would be the way in which background-position works currently, which is backwards compatible. Opinions? Preferences?
Do we need to have an attribute for box-align? Surely it's fairly easy to calculate it yourself. For example, you want a box that's centered on the 30% mark, and is 40% of the width of the area, you simple say position: 10% size: 40% or are there cases where the units used in one attribute are not the same as the other, so the calculation (e.g. here, position = center-width/2) cannot be done?
(In reply to Silvia Pfeiffer from comment #57) > Here's another option: > > 5. Keep align for text alignment and add a second value (comma-separated) > each to "position" and "line" (for percentage-values of line), which > signifies the cue alignment. E.g. position:20%,left line:30%,top . > Default would be the way in which background-position works currently, which > is backwards compatible. > > Opinions? Preferences? I like this proposal. It makes it clearer that the two values are interpreted together, and cuts down on the number of attributes.
(In reply to David Singer from comment #58) > Do we need to have an attribute for box-align? Surely it's fairly easy to > calculate it yourself. For example, you want a box that's centered on the > 30% mark, and is 40% of the width of the area, you simple say > > position: 10% size: 40% That doesn't work because the box has just moved 10% of its own width in, so you're actually centered around the 34% mark. That's what I meant by "it's difficult to calculate". > or are there cases where the units used in one attribute are not the same as > the other, so the calculation (e.g. here, position = center-width/2) cannot > be done? Think of a box's right edge is aligned on the 80% mark and the text is centered and the size is not given (or 80%).
(In reply to Loretta Guarino Reid from comment #59) > (In reply to Silvia Pfeiffer from comment #57) > > Here's another option: > > > > 5. Keep align for text alignment and add a second value (comma-separated) > > each to "position" and "line" (for percentage-values of line), which > > signifies the cue alignment. E.g. position:20%,left line:30%,top . > > Default would be the way in which background-position works currently, which > > is backwards compatible. > > > > Opinions? Preferences? > > I like this proposal. It makes it clearer that the two values are > interpreted together, and cuts down on the number of attributes. That were my initial thoughts, too. However, what if the text is vertical: then we need to be able to use position:20%,top rather than position:20%,left . Maybe a new cue-position attribute is the better option?
(In reply to Silvia Pfeiffer from comment #61) > (In reply to Loretta Guarino Reid from comment #59) > > (In reply to Silvia Pfeiffer from comment #57) > > > Here's another option: > > > > > > 5. Keep align for text alignment and add a second value (comma-separated) > > > each to "position" and "line" (for percentage-values of line), which > > > signifies the cue alignment. E.g. position:20%,left line:30%,top . > > > Default would be the way in which background-position works currently, which > > > is backwards compatible. > > > > > > Opinions? Preferences? > > > > I like this proposal. It makes it clearer that the two values are > > interpreted together, and cuts down on the number of attributes. > > That were my initial thoughts, too. However, what if the text is vertical: > then we need to be able to use position:20%,top rather than > position:20%,left . > > Maybe a new cue-position attribute is the better option? Allowing top and bottom, as well as left and right and middle, is ok. Presumably a cue-position attribute would need a similar range of values.
(In reply to Loretta Guarino Reid from comment #62) > > Allowing top and bottom, as well as left and right and middle, is ok. Fair enough. > Presumably a cue-position attribute would need a similar range of values. It could always have the horizontal position first and the vertical one second.
(In reply to Loretta Guarino Reid from comment #59) > (In reply to Silvia Pfeiffer from comment #57) > > Here's another option: > > > > 5. Keep align for text alignment and add a second value (comma-separated) > > each to "position" and "line" (for percentage-values of line), which > > signifies the cue alignment. E.g. position:20%,left line:30%,top . > > Default would be the way in which background-position works currently, which > > is backwards compatible. > > > > Opinions? Preferences? > > I like this proposal. It makes it clearer that the two values are > interpreted together, and cuts down on the number of attributes. I'm going to specify this proposal now.
(In reply to Silvia Pfeiffer from comment #64) > > > Here's another option: > > > > > > 5. Keep align for text alignment and add a second value (comma-separated) > > > each to "position" and "line" (for percentage-values of line), which > > > signifies the cue alignment. E.g. position:20%,left line:30%,top . > > > Default would be the way in which background-position works currently, which > > > is backwards compatible. > > I'm going to specify this proposal now. Please follow progress on this in bug 23404 .
(In reply to Silvia Pfeiffer from comment #44) > (In reply to David Singer from comment #37) > > In > > the c15 proposal, that will flip the two boxes to the other sides of the > > screen, so the captions are now under the wrong person. This is wrong. > > Right. I think you have a point - I didn't intend a change of position to be > necessary for internationalizing text. Let's see if we can fix that. > > If we separate the text directionality from the align setting, i.e. change > the align setting from referring to the text anchoring to referring to a box > anchoring, I think that would work. I believe that's the same proposal that > Philip made in #c38 . > > BTW: the way CSS background-position works was exactly as we had it before > and that caused problems, because in contrast to background images, text can > be left, middle or right aligned within its box. We need all the 0-100% > positions of background position at work for all 3 positions of the box. > > So, we need text directionality to work independent of position. E.g., a > start aligned text box can still have rtl text aligned at the right edge of > the box, but with box anchoring at the left edge. I have just committed a change that resolves this and makes "text position" refer to the position of the cue box: https://dvcs.w3.org/hg/text-tracks/rev/bb753d2a2739 This now means the following: * the cue box is positioned within the video viewport like CSS background-position but at all 0-100% of the viewport. This is as it was in the old version of the spec (the one Ian [1] wrote) with the position referring to a x% point within the cue box when positioning at x% of the video viewport. This is for backwards compatibility. Bug 23404 will give us other options for positioning (left, center, right edge of cue box for measurement). [1] Last version of WebVTT spec as written by Ian: http://dev.w3.org/cvsweb/html5/webvtt/Overview.html?rev=1.62;content-type=text%2Fhtml * the positioning is independent of the alignment, except that if no positioning is given, the default depends on alignment. * note that if you choose to create a cue box "template" into which you will render either ltr or rtl text and your box is not 100% width and you are not specifying "middle" as the alignment, it is indeed possible that your box may flip sides. This is expected, since you are leaving positioning within the full width of the viewport up to the browser. You need to provide an explicit position to get the cue box into a fixed place. This closes this bug (minus any typos I have introduced). All changes made in this bug can be seen in: http://dev.w3.org/cvsweb/html5/webvtt/Overview.html.diff?r1=text&tr1=1.75&r2=text&tr2=1.74 In the interest of readability, please open a new bug if you come across any further issues or disagree with the patches etc. 66 comments is a lot to scroll through. ;-)
Follow-up bug: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25632