- From: Courtney Kennedy <ckennedy@apple.com>
- Date: Wed, 08 Oct 2014 12:51:27 -0700
- To: Philip Jägenstedt <philipj@opera.com>
- Cc: Silvia Pfeiffer <silviapfeiffer1@gmail.com>, "public-texttracks@w3.org" <public-texttracks@w3.org>
Hi Philip, Apple’s Video Player App and any third party video players that build upon Apple's AVFoundation APIs support the full current version of the WebVTT spec in iOS 8. Webkit does not yet. Courtney > On Oct 8, 2014, at 12:32 PM, Philip Jägenstedt <philipj@opera.com> wrote: > > Hi Courtney, > > That would indeed qualify as strong interest. > > I can't find any trace of this implementation in WebKit: > https://trac.webkit.org/browser/trunk/Source/WebCore/html/track/VTTCue.idl > (no lineAlign/positionAlign) > https://trac.webkit.org/browser/trunk/Source/WebCore/html/track/VTTCue.cpp > (nothing relevant in setCueSettings) > > Searching the Web for "WebVTT iOS8" also doesn't find anything useful. > > I guess it's still in Apple's non-public repo and not widely known > yet? Since I don't have an iOS device to test with, can you provide > some details on which bits have been implemented? > > Thanks! > > Philip > > On Wed, Oct 8, 2014 at 7:56 PM, Courtney Kennedy <ckennedy@apple.com> wrote: >> Hi Philip, >> >> As I stated in my response to Silvia on September 8th, I am strongly in favor of having the current version of the spec become V1, with these features in place. Apple implemented support for these features in iOS8, so there is an existing implementation available now. I think that qualifies as strong implementor interest. >> >> Best Regards, >> Courtney Kennedy >> >>> On Oct 8, 2014, at 5:49 AM, Philip Jägenstedt <philipj@opera.com> wrote: >>> >>> On Mon, Sep 8, 2014 at 6:39 AM, 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? >>> >>> My preference is separate settings in the syntax, which would map >>> better to the IDL interface. Chaning the syntax will make it trickier >>> to write markup that works OK-ish in both old and new parsers. For the >>> same reason, it would also be good if the new settings moves the cues >>> around as little as possible, so that even if the alignment isn't >>> correct they're still on the same place on screen. >>> >>> Of course, I must admit that part of the reason is that I'm still on >>> the fence about whether this is worth implementing at all. I think >>> this should be a v2 feature or wontfix, unless we have some strong >>> implementor interest elsewhere. >>> >>> Philip >>> >>
Received on Wednesday, 8 October 2014 19:51:56 UTC