- From: Courtney Kennedy <ckennedy@apple.com>
- Date: Mon, 08 Sep 2014 12:55:10 -0700
- To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Cc: "public-texttracks@w3.org" <public-texttracks@w3.org>
Hi Silvia, I am strongly in favor of Option 1 below, with these features included in V1. I have been working under the assumption that the current draft spec was what would be taken through the standards process for V1. Creating yet another unofficial version of the spec with different syntax and features is will only compound the backwards compatibility problems, in my opinion. Best Regards, Courtney On Sep 7, 2014, at 9:39 PM, Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote: > Hi everyone, > > As you may have noticed, Philip and I had some intensive discussions > about text positioning in general and the "line" and "position" cue > settings in particular over the last 6 months. > > The way I've come to look at text positioning is that the lines in a > cue together form a cue box and get positioned together. The width and > height of the cue box is defined by the smallest box that all line > boxes would fit into (the bounding box) with a width restriction width > given by the "size" setting. Within that cue box, text alignment is > controlled via the "align" setting. > > When we look at the "line" setting (i.e. vertical positioning), in the > past, the "line" setting positioned the first line in a cue (for > snap-to-lines) and the percentage-point of the cue box for a > percentage-point "line" setting. This meant that it was basically > impossible to e.g. position a cue box such that the top of the cue box > was positioned at the center point of the viewport. > > Therefore, we introduced what I called the "line alignment" setting. > It allowed specifying whether the top, the center, or the bottom of > the cue box was aligned to the "line" setting position. > > For example: line:10%,top would align the top of the cue box at the > 10% mark of the video height. > > Similarly, we introduced what I called the "position alignment" > setting, which does the same for the "position" setting: it allows > specifying whether the left, the center or the right of the cue box > was aligned to the "position" setting. This would, e.g. allow left > aligned text in its cue box to be centered in the horizontal middle of > the video. > > Or another example: position:20%,right would right align the cue box > at the 20% mark of the video width (it would still at most be 80% > wide, or less depending on the "size" setting). > > > Now, Philip has pointed out that these specs are not backwards > compatible. Adding a second, comma-separated value to the "position" > and "line" settings basically makes existing implementations of these > fail. E.g. line:10%,middle will not fall back to line:10%, but will > rather fail parsing and result in no explicit "line" setting, > reverting back to the default -1 line. > > We therefore have a choice: > > 1. We can live with this lack of backwards compatibility. If somebody > decides that they need to specify the alignment for the cue box in > relation to the "line" and "position" settings, they will want a full > implementation of that feature anyway. > > 2. We can move these alignments to extra cue settings. Thus, we would > introduce "lineAlign" and "positionAlign" as two new cue settings that > apply to the cue box alignment. This will make sure that we remain > backwards compatible. > > > I'm happy to go with either of these two options, so am curious to > hear what people think. > > Incidentally, there is a second question here: should these be > features of v1 (and thus go down the path towards the REC spec), or is > it sufficient to move these off to v2? > > Opinions? > > Thanks, > Silvia. >
Received on Monday, 8 September 2014 19:55:40 UTC