Re: Unifying the rendering approach

On Mon, Mar 17, 2014 at 6:42 PM, Silvia Pfeiffer
<silviapfeiffer1@gmail.com> wrote:
>
> On 7 Mar 2014 20:34, "Philip Jägenstedt" <philipj@opera.com> wrote:
>>
>> Sorry for the late reply, I always put off thinking about regions
>> until it gets embarrassing.
>
> It's my turn to say sorry for the delay. I've still got to reply to your
> other email with the list of issues. Just a quick one to some things in here
> for now.
>
>
>> On Mon, Feb 24, 2014 at 11:33 AM, Silvia Pfeiffer
>> <silviapfeiffer1@gmail.com> wrote:
>> > On Sun, Feb 23, 2014 at 6:48 PM, Philip Jägenstedt <philipj@opera.com>
>> > wrote:
>> >> On Sun, Feb 23, 2014 at 12:44 PM, Silvia Pfeiffer
>> >> <silviapfeiffer1@gmail.com> wrote:
>> >>> On Sun, Feb 23, 2014 at 4:14 PM, Philip Jägenstedt <philipj@opera.com>
>> >>> wrote:
>> >>>> I'd
>> >>>> like us to have an internal concept of constraining the size
>> >>>> available
>> >>>> for layout that is honored for snap-to-line cues and that a region
>> >>>> simply establishes such a constraint. We don't need an anonymous
>> >>>> region because lack of a region is simply a lack of such a
>> >>>> constraint...
>> >>>
>> >>> Are you suggesting to completely drop the region rendering path and
>> >>> try to reconstruct it within the normal layout algorithm by
>> >>> constraining the available size for layout for snap-to-line cues? That
>> >>> would mean that this is the only difference between regions and
>> >>> non-regions? However, what do you do with the other "constraints":
>> >>> width, region anchor, viewport anchor, and the scrolling? You can't
>> >>> replicate scrolling unless you have an explicit box for the cues and
>> >>> for the regions. Just restricting the size for the background box
>> >>> doesn't resolve this IMO.
>> >>
>> >> Yes, the details are fuzzy, but that's exactly the path I think we
>> >> should take. As I've outlined in another mail, I think that scrolling
>> >> should be a property of individual cues, not something that they get
>> >> from being in a region.
>> >
>> > I think you're referring to:
>> > http://lists.w3.org/Archives/Public/public-texttracks/2013Nov/0012.html
>> > and
>> > http://lists.w3.org/Archives/Public/public-texttracks/2014Jan/0025.html
>> >
>> > I've previously given feedback in
>> > http://lists.w3.org/Archives/Public/public-texttracks/2014Jan/0038.html
>> > , but I am not sure I understood your approach correctly. I don't
>> > believe we should attribute scrolling to individual cues, but instead
>> > keep scrolling behaviour a property of a region as is the intent of
>> > what is currently specified. Let me see if I can explain.
>> >
>> > You wrote:
>> > "First position the cue in its preferred location. If it
>> > overlaps any other cue, it move it down until it does not overlap.
>> > Then it would be moved up, pushing along with it as many cues as are
>> > necessary to not cause (new) overlap. This "push" may be animated or
>> > not, subject to author stylesheet and user preference."
>> >
>> > Let me ask some clarifying questions based on an example of this.
>> >
>> > Rendered situation at which cue2 comes along:
>> > ---------
>> > |
>> > |
>> > |
>> > | cue1
>> > ---------
>> >
>> > cue2 it is moved "down" until it doesn't overlap any more, resulting
>> > in, I assume, a position off screen below cue1 (outside the viewport)
>> > as the first "free" position?
>> >
>> > Next it moves up into position -1, moving cue1 up, I assume resulting
>> > in:
>> > ---------
>> > |
>> > |
>> > | cue1
>> > | cue2
>> > ---------
>> >
>> > Question: which of the cues has a "scroll" setting? cue1? or cue2? or
>> > both? What happens if one of them doesn't have a "scroll" setting,
>> > e.g. cue1 doesn't have a scroll setting, but cue2 has? Will cue2 get
>> > stuck off screen or will it be displayed?
>>
>> It is the properties of the cue being positioned that would determine
>> how overlap is handled, and since I want scrolling to be a mode of
>> overlap handling, this means that if cue2 has a overlap:scroll or
>> whatever setting, it would cause any overlapping cues (cue1) to move.
>
> We can't have cues that are rendered in a fixed location to be able to be
> pushed away by scrolling cues. So this won't work.

The alternative would be to just let them overlap. I think that's
definitely worse, but it would be trivial to do. I think the ideal
thing would be for it to work exactly as if non-scrolling snap-to-line
cues came to overlap non-snap-to-line cues. There's a bug for that:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=22029

>> Note that making the scroll setting per-cue isn't integral to the
>> change I'd like to make, if it turns out that it would in any way
>> complicate layout (I don't think it would) then one could keep it per
>> region.
>
> The purpose of the region is to define an area in which a group of cues that
> are defined as scrollable can scroll independently of other cues. The group
> of cues can also share a background color around their bounding box, and can
> be moved together eventually. Making the scroll-setting per-cue is
> counter-productive to all of this. It also introduces complexities such as
> mixed scrolling / non-scrolling cues.
>
> To be frank: there would need to be extremely compelling reasons and full
> satisfaction of all region use cases before I would reconsider changing the
> region syntax. We have discussed that region syntax for more than 1.5 years
> and this syntax has proven to work well. The point of this thread was to
> change the rendering part of the algorithm, but not the syntax.

Thank you, I will also be frank.

Regions were designed to match the 608 model, so I do not doubt that
people interested in mapping 608 to WebVTT would say that it works
well.

I am approaching this as a browser developer who expects to maintain
WebVTT for a long time. To me, the size of feature in terms of syntax,
API and rendering rules looks out of proportion to the size of the use
case. Because it started out as an extension spec, all of the
functionality is tied to VTTRegion instead of being separate pieces.
Specifically:

 * The rendering section fork, obviously.
 * The syntax and API still make it look like you could position cues
arbitrarily within regions.
 * Styling of cue backgrounds is lacking generally, we should fix it
generally and not just for regions.
 * If scrolling is useful, it would be useful together with the
classical WebVTT positioning model as well, not just for regions.
 * The default font size of regions is different than without regions.
(Just weird, not hard.)
 * WebVTT still isn't a subset of 608, so there's even more complexity
down the road.

Regions has been implemented once, now forked into WebKit and Blink.
It has never been shipped and I do not want to see it shipped in Blink
in its current state. The purpose of my demos [1] is to explore what
simplifications are feasible. To my untrained eye it seems hopeful,
but if the this group insists on making WebVTT a pixel-perfect
superset of 608 then it will have been a futile exercise.

[1] http://lists.w3.org/Archives/Public/public-texttracks/2014Mar/0035.html

Philip

Received on Sunday, 30 March 2014 16:34:59 UTC