Re: Unifying the rendering approach

On Mon, Mar 3, 2014 at 12:11 PM, Silvia Pfeiffer
<silviapfeiffer1@gmail.com> wrote:
> Thanks for the quick answer.
>
> On Mon, Mar 3, 2014 at 8:41 PM, Victor Carbune <victor.carbune@gmail.com> wrote:
>>>
>>>>>> This approach has the following advantages:
>>>>>> *) We avoid weird absolute-positioned cues in absolute-positioned regions.
>>>>>
>>>>> What's the problem here?
>>>>
>>>> I don't see any use case for this, thus why support it? It just looks
>>>> like it enhances 'chaos' in a region. Just snapping lines within
>>>> regions covers all the use-cases, IMO.
>>>
>>> OK.... But you can snap a line in a region. E.g. in a 3-line region
>>> you can position it in line 1, 2, or 3, right? Then you still have to
>>> position these lines absolutely inside the region, don't you?
>>
>> Yes. I am (maybe mistakenly) using the term "absolute" positioning
>> only when both horizontal and vertical attribute are percentages
>> (non-snap-to-lines case).
>
> Ah right.
>
>
>> I'm supporting line-snapping within regions (mentioned this from the
>> first email on this thread [1])
>> http://lists.w3.org/Archives/Public/public-texttracks/2014Jan/0043.html
>
> I didn't remember this. That's interesting and could work, I guess.
>
>
>>>> Having absolute-positioned cues makes me conceptually transform the
>>>> cue text into a box, and position it within another box, which is the
>>>> region. I'd like to think that the only boxes we will have in this
>>>> spec will be the regions. The cues will just be some wrapped text
>>>> lines, automatic or due to author line breaks (should be treated the
>>>> same).
>>>
>>> Right, I see why you want to put anonymous regions around every single
>>> non-region cue. You just want positioned boxes that are either
>>> positioned to contain a single cue, or positioned to contain scrolling
>>> cues or automatically positioned cues. You don't want to extend
>>> regions to contain explicit line positioning.
>>
>> I don't want percentage-positioned cues within regions. They don't make sense.
>>
>> When we have a percentage-positioned cues, I just want to wrap it in
>> an anonymous region and set the positioning attributes of the regions
>> such as we have backward compatibility for non-snap-to-lines case.
>
> Yes, I think I now follow and it makes sense to me.
>
>
>>>> The last aspect is the anonymous region of the size of the video,
>>>> while I'm not entirely happy about it, I already mentioned that I like
>>>> it because it keeps the simplicity of VTT - you can have a cue with
>>>> text and line index and you're done.
>>>
>>> Now I am confused. Where do we now have anonymous regions of the size
>>> of the video in your model?
>>
>> I'll just rewrite:
>> *) An anonymous region with video width & height for all the cues that
>> have snap-to-lines=true and no region specifier.
>> *) One anonymous region with auto width & height wrapping each
>> snap-to-lines=false cue that has no region specifier
>
> Aha! I see. The first case is so as to keep the line counting correct
> for snap-to-lines cues, I assume? Couldn't we make these two cases
> into a single case if the line positioning both for snap-to-lines and
> for non-snap-to-lines is done on the anonymous region that wraps each
> cue? What's the advantage of splitting these two cases?

If we throw non-snap-to-lines cues within regions it means that we
need to support a rendering case for these cues within regions, and
also support named regions on them.

The advantage of not having non-snap-to-lines cues within regions are:
*) Simple rendering steps within a region (pretty much everything that
currently is for snap-to-lines will just be moved within a region).
*) No need to think what happens if some percentage-positioned cue
overlaps a line-positioned cue (see "underspecced overlapping
positioning" bug)
*) No boxes in boxes. Only the text lines generated by CSS wrapping or
manual author wrapping (snapped into numerical lines of a region).
*) Better abstraction: author can already obtain exactly the same
positioning using regions that they can with percentage-positioned
cues. Why integrate two different elements solving the same problem
together, if we can keep only one?

>> *) User-defined regions & cues with region identifier and snap-to-lines=true.
>>
>> So there's no cue with snap-to-lines=false that ends up in a region.
>
> A named region, I assume. Since the second case has
> snap-to-lines=false cues in an anonymous region.

As I mentioned above, I don't see any value in having
non-snap-to-lines and snap-to-line cues in a single region, no matter
if it is the large default anonymous region for snap-to-lines cues or
a named region. It means you have to specify a rendering algorithm
that combines both.

A more personal comment: I feel that non-snap-to-lines cues are hard
to use for authors that want to actually position things precisely on
top of the video, and I'm not aware of other use-cases for it, so I
would even go as far as removing them as soon as we support regions.
But since they are already here, we can easily keep them for
backwards-compatible purposes with wrapped anonymous regions
fulfilling the same positioning behavior.

Victor

Received on Monday, 3 March 2014 11:42:00 UTC