23404 2013-10-01 02:30:14 +0000 Redesign cue box position settings 2014-02-13 07:51:31 +0000 1 1 1 Unclassified TextTracks CG WebVTT unspecified PC All RESOLVED FIXED v1 P2 normal --- 1 silviapfeiffer1 silviapfeiffer1 lorettaguarino mike philipj public-texttracks rick.eyre dave.null oldest_to_newest 94057 0 silviapfeiffer1 2013-10-01 02:30:14 +0000 In bug 20037 we've redesigned text position settings. This bug is about the "line" cue setting. "line" settings position lines of text off the top of the video. With snap-to-lines set (i.e. non-percentage values) the video viewport is divided into lines and the positioning is by line number. With percentage, users expect 0% to refer to the top of the cue box, 50% refer to the center of the cue box, and 100% refer to the bottom of the cue box. Right now the rendering algorithm does so by positioning the x% point of the cue box at x% of the video viewport's height (for horizontal cues; width for vertical cues). However, this leads to hard to authoring content, e.g. to position the top of a cue box exactly 20% down the video viewport, an author needs to make complicated calculations to determine the "line" value that position equates to. 94058 1 silviapfeiffer1 2013-10-01 02:30:51 +0000 Proposal: In addition to having line:x% specified, we also need to specify what end of the cue box the line position refers to. I'm therefore suggesting introduction of a box-align setting to contain "top", "middle" and "bottom" as values. I'm not sure about the name of the setting yet. Suggestions welcome. We could also extend the meaning of "align" to become a double value setting, something like "align:middle,top" to mean: * main direction: middle align * cross direction: top align Main direction being horizontal by default and vertical if the cue has a "vertical" cue setting; cross direction being the other direction. 94063 2 philipj 2013-10-01 08:21:52 +0000 Would the order matter? It would have to for align:start,end to mean something... 94159 3 silviapfeiffer1 2013-10-02 07:49:46 +0000 (In reply to Philip Jägenstedt from comment #2) > Would the order matter? It would have to for align:start,end to mean > something... Yes it would. After looking at bug 20037 yesterday, I further thought that maybe we should leave "align" to represent the text-align withing the box, and then have a new cue-align property to do the position/line alignments. 94359 4 lorettaguarino 2013-10-05 00:38:55 +0000 I like the proposal in https://www.w3.org/Bugs/Public/show_bug.cgi?id=20037#c57, which would allow a top/middle/bottom value to be specified with the line percentage, to indicate which anchor position is being specified. 95650 5 silviapfeiffer1 2013-11-01 00:23:31 +0000 Spec proposal: 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. Values would be: left, middle, right, top, bottom. Possibly also: auto 95659 6 philipj 2013-11-01 08:59:11 +0000 What would the DOM API look like? Having to read and write the comma-separated values as strings wouldn't be awesome. 95732 7 silviapfeiffer1 2013-11-02 21:08:48 +0000 (In reply to Philip Jägenstedt from comment #6) > What would the DOM API look like? Having to read and write the > comma-separated values as strings wouldn't be awesome. Good point. Maybe two new fields called positionAlign and lineAlign? 95733 8 philipj 2013-11-02 22:41:15 +0000 (In reply to Silvia Pfeiffer from comment #7) > (In reply to Philip Jägenstedt from comment #6) > > What would the DOM API look like? Having to read and write the > > comma-separated values as strings wouldn't be awesome. > > Good point. Maybe two new fields called positionAlign and lineAlign? Do you mean a comma-separated value in the file format but two (or three?) properties in the DOM API? That doesn't sound ideal, TBH. Given that there's both horizontal and vertical alignment, wouldn't there need to be positionHorizontalAlign and positionVerticalAlign, or is the idea that one can only pick one dimension? The initial comment in this bug only argues for the need for line alignment, are we sure that position alignment is currently hard enough to warrant more settings? Left, center and right alignment is already easy (0%, 50%, 100%), is something like "make this box 50% of the video width with its left edge inset 20% into the video". I suppose I should ask the same about line positioning. I don't dispute that it's hard to do exact positioning right now, but are we sure that's a problem for authors? (Playing the devil's advocate here so we don't complicate things prematurely.) 95737 9 silviapfeiffer1 2013-11-03 09:13:50 +0000 (In reply to Philip Jägenstedt from comment #8) > > Do you mean a comma-separated value in the file format but two (or three?) > properties in the DOM API? That doesn't sound ideal, TBH. Yes, I was thinking that. Similar to how CSS sometimes has aggregate values, but individual DOM style attributes for it, e.g. background and backgroundColor. > > Given that there's both horizontal and vertical alignment, wouldn't there > need to be positionHorizontalAlign and positionVerticalAlign, or is the idea > that one can only pick one dimension? Every cue has only one dimension, i.e. either horizontal (the default) or vertical (through the "vertical" cue setting). The "position" cue setting goes with the main dimension (i.e. horizontal by default), while the "line" cue setting goes with the orthogonal dimension (i.e. vertical by default). Thus, there is positionAlign and lineAlign - no need for Horizonal/Vertical on position. > The initial comment in this bug only argues for the need for line alignment, > are we sure that position alignment is currently hard enough to warrant more > settings? Left, center and right alignment is already easy (0%, 50%, 100%), > is something like "make this box 50% of the video width with its left edge > inset 20% into the video". There's a difference between the alignment of the box into which the text is rendered and the alignment of the text inside the box for "position". For the "line" direction we only care about the box alignment. We need to care about that for the "position" direction too. > I suppose I should ask the same about line positioning. I don't dispute that > it's hard to do exact positioning right now, but are we sure that's a > problem for authors? > > (Playing the devil's advocate here so we don't complicate things > prematurely.) It's a big problem for authors, because it's not possible to position cues accurately, e.g. if you want middle aligned text in a box that is left aligned at, say, 20%. I know Loretta has several more examples. 95742 10 silviapfeiffer1 2013-11-03 22:36:29 +0000 To be clear what this means, here are some examples: Cue setting: align:end implies: position:100%,right Also: line:-1 unless changed by overlap avoidance Cue setting: align:start implies: position:0%,left Also: line:-1 unless changed by overlap avoidance Cue setting: align:middle implies: position:50%,middle Also: line:-1 unless changed by overlap avoidance Cue setting: line:20% implies: line:20%,top i.e. the top of the box is at the 20% mark - this is backwards compatible. Cue setting: line:100%,bottom This allows authors to specify cues to always sit at the bottom of the video viewport (e.g. even if a cue gets broken into muliple lines.) Here's where we need to make a decision: Cue setting: align:middle position:20% implies: position:20%,auto Now, how do we interpret "auto"? Here are some options: 1.) "auto" follows "align" - in this case: "middle" - (and is by default "middle") -> this would be backwards compatible with the previous spec 2.) "auto" positions the 20% mark of the cue box at the 20% mark of the video viewport -> I proposed this earlier, but am not a fan of it any longer. 3.) "auto" is always "left" -> this is compatible with how the "line" cue setting also always interprets the percentage as a percentage offset from the top of the video I'm inclined to pick 3.) and not have an "auto" value. While this breaks backwards compatibility in the few cases where authors have used "align:{middle,end}" with "position", I like that it makes "line" and "position" work the same. Opinions? 95748 11 silviapfeiffer1 2013-11-04 02:44:43 +0000 As it turns out - I can do 1.) easily. I just started by patching the data model and introducing an examle, see https://dvcs.w3.org/hg/text-tracks/rev/74c7166d0199 and https://dvcs.w3.org/hg/text-tracks/raw-file/default/webvtt/webvtt.html 95749 12 silviapfeiffer1 2013-11-04 02:48:17 +0000 Sorry, had to fix the example to use the actual values I defined: start - for alignment to either left or top of the cue box middle - for center alignment end - for alignment to either right or bottom See: https://dvcs.w3.org/hg/text-tracks/rev/1760787c4037 95755 13 philipj 2013-11-04 08:13:58 +0000 (In reply to Silvia Pfeiffer from comment #9) > (In reply to Philip Jägenstedt from comment #8) > > > > Do you mean a comma-separated value in the file format but two (or three?) > > properties in the DOM API? That doesn't sound ideal, TBH. > > Yes, I was thinking that. Similar to how CSS sometimes has aggregate values, > but individual DOM style attributes for it, e.g. background and > backgroundColor. Well, except that a CSS shorthand foo usually expand to two or more foo-bar/baz properties, not foo and foo-bar which is the case here. I guess it still works, though. > > Given that there's both horizontal and vertical alignment, wouldn't there > > need to be positionHorizontalAlign and positionVerticalAlign, or is the idea > > that one can only pick one dimension? > > Every cue has only one dimension, i.e. either horizontal (the default) or > vertical (through the "vertical" cue setting). The "position" cue setting > goes with the main dimension (i.e. horizontal by default), while the "line" > cue setting goes with the orthogonal dimension (i.e. vertical by default). > Thus, there is positionAlign and lineAlign - no need for Horizonal/Vertical > on position. Oh, right :) 95756 14 philipj 2013-11-04 08:25:47 +0000 So it looks like "text track cue position alignment" is the new concept introduced by this change, but it looks like it doesn't actually do anything? Assuming that the default behavior of position:20% with no specified alignment is still aligning the 20% mark of the cue box with the 20% mark of the video, what is position:20%,middle supposed to do? Is it just to align the 50% mark of the cue box with the 20% mark of the video? I don't think that maps to anything (simple) in CSS, is it really useful? 95759 15 silviapfeiffer1 2013-11-04 12:25:19 +0000 (In reply to Philip Jägenstedt from comment #14) > So it looks like "text track cue position alignment" is the new concept > introduced by this change, Yes, and also line position alignment. > but it looks like it doesn't actually do anything? I haven't written the syntax and parsing part yet. > Assuming that the default behavior of position:20% with no specified > alignment is still aligning the 20% mark of the cue box with the 20% mark of > the video, No, that's not the default behavior actually (not in the old spec either - I actually had to check that today). The default behavior of position:20% is to align the center of the cue text (because the text is by default align:middle) with the 20% mark of the video. > what is position:20%,middle supposed to do? Is it just to align > the 50% mark of the cue box with the 20% mark of the video? Yes, and that's identical to what is currently implemented in webkit & blink. > I don't think > that maps to anything (simple) in CSS, is it really useful? It's simple in CSS, because all you need is to calculate the left offset by using the size of the cue box. Apart from providing backwards compatible, it's also useful for when you have a person on the left and you want to center text underneath that person (say: at the 20% mark of video width). 95762 16 philipj 2013-11-04 13:49:53 +0000 I seem to misremember how things used to work, but testing in Opera (Presto) indeed shows that position:1% tries to fit a cue into a tiny column at the left edge, which wouldn't be the case if positioning worked the way I thought it did. Will there be an align value which makes things work the way I thought they already did? 95781 17 silviapfeiffer1 2013-11-05 01:10:54 +0000 (In reply to Philip Jägenstedt from comment #16) > > Will there be an align value which makes things work the way I thought they > already did? You mean 2.) in https://www.w3.org/Bugs/Public/show_bug.cgi?id=23404#c10 ? While that's what I considered doing first, I don't actually think it's that useful in practice. Do you have a use case that is not covered by start, middle or end alignment of the cue box to the position value? 95790 18 philipj 2013-11-05 07:46:25 +0000 (In reply to Silvia Pfeiffer from comment #17) > (In reply to Philip Jägenstedt from comment #16) > > > > Will there be an align value which makes things work the way I thought they > > already did? > > You mean 2.) in https://www.w3.org/Bugs/Public/show_bug.cgi?id=23404#c10 ? > > While that's what I considered doing first, I don't actually think it's that > useful in practice. Do you have a use case that is not covered by start, > middle or end alignment of the cue box to the position value? At first I thought it should make right-aligning a box of size 50% easier, but only if it was the default so that "size:50% position:100%" would have that effect. If it's not the default and additional settings are needed, then "size:50% position:100%,right" works just fine I think, no need for an additional mode. 95835 19 silviapfeiffer1 2013-11-06 03:04:17 +0000 (In reply to Philip Jägenstedt from comment #18) > > At first I thought it should make right-aligning a box of size 50% easier, > but only if it was the default so that "size:50% position:100%" would have > that effect. If it's not the default and additional settings are needed, > then "size:50% position:100%,right" works just fine I think, no need for an > additional mode. Yes, that would be it. 95850 20 philipj 2013-11-06 09:43:47 +0000 OK, please go forth and spec what you think is good, and I'll complain later if I've misunderstood something :) 100468 21 silviapfeiffer1 2014-02-13 07:51:31 +0000 The following patches introduced a new line positioning mechanism: Examples: https://dvcs.w3.org/hg/text-tracks/rev/74c7166d0199 Syntax: https://dvcs.w3.org/hg/text-tracks/rev/cf22782db631 Parsing: https://dvcs.w3.org/hg/text-tracks/rev/886e55d6a733 https://dvcs.w3.org/hg/text-tracks/rev/cc5c4041bc4e VTTCue API: https://dvcs.w3.org/hg/text-tracks/rev/7db213a21a17 Rendering: https://dvcs.w3.org/hg/text-tracks/rev/06fb21f577f4 Further changes to the rendering section are being discussed on list.