Re: Unifying the rendering approach

I guess when I first laid out regions, I thought of them as working the same as the non-region case, by basically treating the non-region case as being one, anonymous, region that fills the entire area.

I think we might have deviated from that, but I see (2) as a natural thing to do if you take this direction (after all, the anonymous region is absolutely positioned to cover the entire viewing area).

In (4) I would express it as a goal for minimal perturbation, especially to already working code, files, or deployed systems.


Overall, I am with Silvia; this is an algorithm and description cleanup.  Can we try to leave the format alone and all the common cases of behavior, but streamline the algorithm and have it cover the corner cases more explicitly and elegantly?

On Mar 24, 2014, at 13:36 , 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.
> 
> 
>> 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.
> 

David Singer
Manager, Software Standards, Apple Inc.

Received on Monday, 24 March 2014 22:03:52 UTC