- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Fri, 24 Jan 2014 16:26:10 +1100
- To: "public-texttracks@w3.org" <public-texttracks@w3.org>
Hi all, The introduction of regions created a second code path in the rendering spec with some duplication. At FOMS, several people voiced that they are unhappy about it. We discussed if it was possible to unify that. The proposal that we came up with was to put *all* cues into regions. A region is thus basically the background box into which cues are rendered. Cues that have no region reference will be put into an anonymous region that has: * no identifier, * the dimensions of the viewport (vw, vh), * no scroll, * a region anchor of (0,100), * a region viewport anchor of (0,100). The intent is to allow us to create a single rendering path for all cues. However, there are differences between cues that are currently rendered without a region and those that are rendered into a region and we have to work these out. We can either try to retain the previous behaviour or come up with a better, more integrated way of doing it. So, I've gone through and tried to identify the differences. * overlap avoidance: cues without a region have a means to deal with overlap and move cue positions. The approach here is different between snap-to-line positioned cues and percentage positioned cues. I'd like to come up with an algorithm that deals the same with all cues. Also, it needs to be deterministic for the JavaScript developer so they can potentially do even more repositioning if necessary. So, my thoughts are that we should just avoid placing cues into lines (for horizontal cues; rows for vertical cues) that are already occupied by another cue. That's basically the algorithm for snap-to-line positioned cues. It wouldn't apply to scrolling regions, but to all other ones. (BTW: I think we need two levels of overlap avoidance: one within a track and one that optimizes between all tracks, not just VTT tracks. So, we may need to create an algorithm for the HTML spec for this, too. But this is a discussion for another day.) * snap-to-lines: cues in a region don't have snap-to-lines positioning. When we place such cues into anonymous regions, we calculate the number of lines from the size of the region, which for an anonymous region is the size of the viewport. So, this should be fine. * title area: right now we have a means to specify a "title area" for snap-to-lines cues. I think we can remove that because we now have padding on the cue background box (which will be the region in future), so we have that covered for all types of cues. Are there any other issues I have overlooked? Thanks, Silvia.
Received on Friday, 24 January 2014 05:27:02 UTC