Re: Unifying the rendering approach

On Tue, Mar 25, 2014 at 3:36 AM, Silvia Pfeiffer
<silviapfeiffer1@gmail.com> wrote:
> On Mon, Mar 10, 2014 at 6:57 PM, Philip Jägenstedt <philipj@opera.com> wrote:
>>
>> I've finally taken the time to finish reading this thread. We have a
>> few different goals here:
>>
>> 1. Remove the regions fork in the rendering algorithm.
>
> This was my only goal in starting this thread. :-)
>
>
>> 2. Remove the absolute-positioned-within-absolute-positioned mode of layout.
>
> Is this about having cues positioned in a particular line within a region?
> As per current spec, if a cue has a "line" setting, it can't be part
> of a region. So this was a new proposal within this thread.
>
> I think we should not pursue this line of thought until we have sorted out 1.
>
>> 3. Remove one of the two ways of doing absolute positioning.
>
> This was Victor's additional proposal to do after we merge the
> rendering algorithm, IIUC.
>
> The idea being: regions provide a means to absolutely position cues -
> so does the "line" cue setting.
> Therefore, we can remove the "line" cue setting.
>
> My opinion after having thought about this for a while:
> They are not actually the same thing.
>
> The "line" cue setting provides a simple means for a single cue to be
> absolutely positioned.
> It's a simple approach, easily understood, and already deployed in all browsers.
>
> The "region" approach can be used to position a single cue absolutely,
> but that is a side effect of a more complex feature: the ability to
> absolutely position a group of cues. Grouping cues is a need that we
> have identified by analysing how existing captions are created, in
> particular CEA708. It is a more difficult concept to deal with and
> will likely be used less than the simple "line" setting.
>
> There is a use case for both approaches.
>
> We can revisit this once we have done 1.

I don't think rewriting the rendering algorithm without actually
changing its behavior sounds very meaningful. The current model is
that regions makes positioning work completely differently, and the
rendering algorithm reflects that. The suggested change is using
anonymous regions for non-snap-to-line cues, but that doesn't seem
like a simplification at all. Also, as long as it renders the same,
implementations are already allowed to use regions internally if they
think it helps.

>> 4. Be backwards compatible in syntax, API and rendering.
>
> If you replace "and" with "and/or" I would agree more with this statement.
> I don't think this statement is a particular goal of this thread -
> it's merely one of the arguments being used for any of the proposed
> changes.
>
>
>> If there are other goals underlying the suggestions, please add to the
>> list. It's worth noting that enabling new use cases is not on the
>> list, so we're basically doing refactoring work here. (We should be
>> careful to not introduce new functionality that isn't backed by
>> compelling use cases.)
>
> Correct. Therefore, we should not do 2 at this stage.
>
>
>> Of the listed goals, I value (1) way above any of the other. I think
>> (2) is a good idea since the mode wasn't added to address any specific
>> use case. I think (3) could be worthwhile, but disagree with (4).
>
> I still disagree with (2) even existing right now. Can you explain
> where you see it?

The syntax and API makes it look like it works, and I've just assumed
that any meaningful unification would have to make it work, since
otherwise regions don't actually work like a smaller viewport.

After writing my demos I think we can simply not use regions for
positioning, and instead just have backgrounds and clipping for a
group of cues positioned as usual. What would be lost is the anchor
point concept from 608, but it seems to me that we could just as well
replace lineAlign and positionAlign with an anchor point on the cue
instead.

> As for (4): there are certain things that we should not change any
> more, simply because there are existing implementations. As in: we
> don't want to break YouTube every few months because we've come up
> with a great new idea for doing WebVTT better, just to turn out that
> we have to revise it again a few months down the track. I believe we
> have converged a lot over the last year on the syntax and the syntax
> is in good shape. Of the syntax, the region part hasn't been released
> in browsers yet, so there is a chance to still adapt it. However,
> browsers have implemented the syntax behind a flag, so there should be
> good feedback about the implementability of it - something that can't
> be said about anything else. That counts for something, too.
>
> As for rendering: the user/author should not get any surprised about
> how their existing content (which excludes regions) is rendered. How
> we do that in the rendering spec is internal implementation detail,
> though, so we are free to change that, of course.

When I say I disagree with (4), I simply mean that we should be free
to change things that haven't been shipped or where almost no content
depends on it yet, if it would make the spec better. Does YouTube
actually let the browser render WebVTT, though? That would be
surprising given the currently poor interoperability.

>> I worry that using automatic regions for absolute positioning while
>> maintaining backwards compat in syntax and API will make a mess of the
>> syntax and API.
>
> I don't follow - syntax and API won't be changed. Only the rendering
> algorithm will change.
>
>> Let's have a look:
>>
>> interface VTTCue : TextTrackCue {
>>            attribute VTTRegion? region;
>>            attribute DirectionSetting vertical;
>>            attribute boolean snapToLines;
>>            attribute (double or AutoKeyword) line;
>>            attribute AlignSetting lineAlign;
>>            attribute double position;
>>            attribute AlignSetting positionAlign;
>>            attribute double size;
>>            attribute AlignSetting align;
>>            attribute DOMString text;
>>   DocumentFragment getCueAsHTML();
>> };
>>
>> interface VTTRegion {
>>            attribute double width;
>>            attribute long lines;
>>            attribute double regionAnchorX;
>>            attribute double regionAnchorY;
>>            attribute double viewportAnchorX;
>>            attribute double viewportAnchorY;
>>            attribute ScrollSetting scroll;
>> };
>>
>> What would change?
>
> Nothing.
>
>> Should setting snapToLines to true cause a
>> VTTRegion to be created? Should changing line from "auto" to 30.5
>> should cause the region's attributes to change? What if the region is
>> shared by several cues? I would like to know the details here, because
>> the way I *guess* it would have to work doesn't make sense to me.
>
> None of this would change. It's only a refactoring of the rendering
> algorithm that we are talking about.
>
>> I want us to carefully consider what changes can be made without
>> breaking existing content and not. I happily volunteer to add use
>> counters to Blink for anything that people think we should change.
>> Things that we can definitely change because it hasn't been shipped
>> yet is VTT.region, VTTCue.lineAlign, VTTCue.positionAlign and the
>> whole of VTTRegion. The rest depends on real-world usage.
>
> Agreed. But to re-iterate: the point of this thread was not the make
> changes to syntax and API or even to the rendering outcome - but only
> to streamline the rendering algorithm.

It seems to me like Victor had actual changes in mind, I certainly do,
but OK. As I said above, implementations are already allowed to do
anything they like as long as the output is the same. The current
rendering algorithm well reflects the very special nature of regions.
I'd like to make them less special, but that necessarily implies
changes to the output.

Philip

Received on Sunday, 30 March 2014 17:08:27 UTC