Re: Unifying the rendering approach

On Tue, Mar 4, 2014 at 5:55 AM, Silvia Pfeiffer
<silviapfeiffer1@gmail.com> wrote:
> Sounds like we are converging!
>
> Philip: if you agree, too, I can start preparing patches.

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.

2. Remove the absolute-positioned-within-absolute-positioned mode of layout.

3. Remove one of the two ways of doing absolute positioning.

4. Be backwards compatible in syntax, API and rendering.

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

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

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.

Don't read this message as "no", what I mean is "I don't know yet".

Philip

Received on Monday, 10 March 2014 07:57:55 UTC