Re: Unifying the rendering approach

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.


> 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?

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.

> 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.

HTH,
Silvia.

Received on Monday, 24 March 2014 20:36:51 UTC