Re: Unifying the rendering approach

On Mon, Mar 31, 2014 at 4:07 AM, Philip Jägenstedt <philipj@opera.com> wrote:
> 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.

I am prepared to change the rendering section / algorithm completely.

But I am not prepared to change the Syntax any more. It's been too
long in the making.

That's really the core of my position. And it's not about CEA608, but
about CEA708.
For 608 I agree that we wouldn't need regions at all.

Cheers,
Silvia.


> 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 Saturday, 3 May 2014 01:26:09 UTC