RE: WebVTT

On 16 Jun 2013 00:31, "Sean Hayes" <Sean.Hayes@microsoft.com> wrote:
>
>
> >> but all right, I guess I could specify that position:30% width:60% and
top 80%. If remove the repositioning logic, that might work, it's at least
predictable.
>
> > Right.
>
> OK. Your first port of call then should be to remove the text :
>
> 1.Set up x and y as follows:
> If the text track cue writing direction is horizontal, and direction is
'ltr'
> Let x be a percentage given by the text track cue text position, and let
y be a percentage given by the text track cue computed line position.
> If the text track cue writing direction is horizontal, and direction is
'rtl'
> Let x be a percentage given by the text track cue text position
subtracted from 100, and let y be a percentage given by the text track cue
computed line position.
> If the text track cue writing direction is vertical growing left
> Let x be a percentage given by the text track cue computed line position
subtracted from 100, and let y be a percentage given by the text track cue
text position.
> If the text track cue writing direction is vertical growing right
> Let x be a percentage given by the text track cue computed line position,
and let y be a percentage given by the text track cue text position.
>
> 2. Position the boxes in boxes such that the point x% along the width of
the bounding box of the boxes in boxes is x% of the way across the width of
the video's rendering area, and the point y% along the height of the
bounding box of the boxes in boxes is y% of the way across the height of
the video's rendering area, while maintaining the relative positions of the
boxes in boxes to each other.
>
>
>
> >>  I don't see any mechanism for vertical centering of the text, so top
will always be line, yes?
>
> >Yes.
>
> OK
>
>
> >>Yes, external CSS is applied after the WebVTT cue rendering algorithm
has executed and the basic CSS parameters been set. However, during the
rendering algorithm, the width of the video is taken into account and lines
are broken and create new CSS boxes that become part of what is being
rendered. That's what I was referring to.
> >
> > Sure. But those boxes fit within the containing block right?
>
> The initial containing block is viewport:
> http://www.w3.org/TR/CSS21/visudet.html#containing-block-details .
> Everything has to fit into that.
>
> Indeed, but also:
> 5.2.2 On the (root) list of WebVTT Node Objects, the 'position' property
must be set to 'absolute',
> This is what actually constrains and positions the inline boxes for the
inline boxes generated..
>
> >> so the outer box is created appropriately for a 5vh font of
unspecified advance. If CSS changes the font much from that it's going to
over or underflow, but its not going to move the box.
>
> >No, when the CSS changes, the cue is re-rendered and thus the box may
end up somewhere else.
>
> It could if there were CSS properties that could be applied affected the
top left or width, but there aren't. Can you explain to me how you would
see this happening.

The first line box will indeed be in the same place, but for a multi-line
cue the n next lines will end up further down because of the higher line
height.

> >>No, the rendering algorithm is executed again:
> >>"User agents that support the pseudo-element described below must
dynamically update renderings accordingly. When either 'white-space'
> >>or one of the properties corresponding to the 'font' shorthand
(including 'line-height') changes value, then the text track cue's text
track cue display state must be emptied and the text track's rules for
updating the text track rendering must be immediately rerun."
> >>
> >>The re-run is then using the new CSS settings for those properties and
thus ends up creating different boxes.
> >
> > Yes OK, but rules state that no style sheets are used, and there's no
other text to indicate that the cascade properties are projected onto the
WebVTT nodes, so re-running the algorithm does not does not pick up these
values.
>
> > We have the ::cue pseudo selector through which CSS properties of
individual cues can be changed.
> > When they are changed, they are the new properties of the cues and are
applied in the re-run of the rendering algorithm.
>
> Yes, but no property that can be set by cue can change the fact that the
root box is absolutely positioned, or influence its top, left, or width.
You can change the font and lineheight, but these would only affect the
height assuming they were applied before the height trait is calculated.
>
>
> > Ff it was intended the new values to be utilised then the spec text
needs to change.
>
> You don't think:
> "User agents that support the pseudo-element described below must
dynamically update renderings accordingly."
> is sufficient?
>
> No. because of this text : "No style sheets are associated with nodes.
(The nodes are subsequently restyled using style sheets after their boxes
are generated, as described below.)."
>
> So for purposes of 5.2.1 no style sheets are in use, whether run the
first time or the 100th time, they are used *subsequently*, which means
occurring or coming after, according to my dictionary. Therefore CSS style
is not applied until after the boxes are created. Delete this text, or
better still put 'apply the cascade' somewhere at the start of 5.2.1
>
> But even if you remove this text, as I say the only thing that will
change is the height, since it is set to 'auto',
>
>
> >> Moreover changing the font will only really affect the height of the
box. And once the repositioning rules that cause the problems above are
removed, changing the height will not cause the box to move.
>
> >If the line height changes because of a font size, that influences the
height of the line box. So on a re-rendering, the calculations will be
different.
>
> Yes, but the position will not be different.
>
>
> >> I will of course be looking at the region spec, in much more detail, I
have already noted a few issues with it. However my understanding is that
is an optional extension. Is it intended to a mandatory feature?
>
> >Since we want all browsers to support it, it would be a mandatory
feature for browsers. Of course, authors can choose if they want to make
use of all features or not.
>
> OK
>
> >> If the latter then I think having two different positioning schemes
could cause even more problems, so I would like to see these unified.
>
> >They don't conflict and the one without regions is easier to understand,
while the one with regions is more like CEA708. I think WebVTT can deal
with two different caption positioning approaches: one fixed and one
scrolling.
>
> They don't conflict as such, since it's clear which takes precedence,
however they are different, so this increases the cognitive load for
authors. The tools without regions will be simpler as and when you take out
the offending text above.

Indeed. But for professional caplets that want more control over cue
rendering boxes or need roll up, regions are required. Anyone else can just
ignore that feature.

> >> OK, just so I'm clear do you intend the region spec to replace the
current positioning and be a mandatory component of the spec?
>
> >No, it adds to the current positioning.
>
> OK. If you wish. Seems poor design to me, but at least it's not ambiguous.
>
> >>> Anyway it seems we may need to table this discussion until the text
is a somewhat more mature.
> >
> >>I think it's one particular section that you have the most trouble
with. But feel free to wait until that bug is fixed.
> >
> > Yes, currently I'm concentrating on understanding section 5.2 so that's
what I'm reporting on right now. I'll get to the rest of the spec in due
course.
> >
> > boiling it down I think my issues are so far:
> >   Step 10.5 & 10.6 occurring first (or indeed at all)
> >   Step 10.7 before step 10.10 (as per your bug), although not sure
10.10 should happen at all.
> >   Step 10.8 x-position and y-position not just being position and line
respectively (units here could be % or em)
> >   Step 10.10 unspecified UA specific value for margin repositioning
content. Needs to be predictable.
> >   Step 10.12 Not clear that it is intended for CSS properties from the
cascade to work here (as per your comment above), and if it is it would be
better for top, left, width and height to work directly as the cue settings
are not amenable to document style
> >   Step 10.12 Unclear algorithm for 'balanced line breaking', which
should definitely be switchable if kept.
> >   Step 10.14 should not happen at all
>
>
> Ok, I'm going to have to work through these
>
>
> >   5.2.2 Specifying a sans-serif font of 5vh is not adequate if this is
the only mechanism to control the box height. The font advance needs to be
more predictable. Or, more preferably the size setting controls both the
width and height directly, and the user gets to specify a font in terms of
the box height/width.
>
> >Which box height are you asking for more control over? The box that the
font is rendered into is the line box and its height is specified from the
font. What other box height are you after?
>
> The box created for the (root) list of WebVTT Node Objects, where the
'position' property must be set to 'absolute'.

Right, that's what the region spec offers you.

> > 5.3.3 past: and future: it's not clear to me how these are communicated
to external script - if I get the cue as HTML can I get events for when
these change the styles?
>
> >I don't think I understand this question. :past and :future are CSS
pseudo-classes that are provided on WebVTT Node Objects. They are, e.g.
specified in a style sheet that is included into the HTML page that also
has a <track> element with the WebVTT file in it. The browser will take
care to change the CSS styles of the WebVTT Node Objects accordingly as
time marches on - no extra work is necessary by the developer for this
styling - there are no events to indicate that the CSS style change
happened. Why would they be required?
>
> Because they affect what text is visible to the user.
> So if the JS developer gets the cue text, they always receive all the
text in the cue. They cannot know where the time is internal to that cue,
and therefore what part of that text is currently visible?

Oh right, you misunderstand how :past and :future are applied. They only
work if you have provided time stamps in your markup <00:00:00:00>. And
time matches on according to the video, so video.current time provides the
JS dev the current time. And the timeupdate event provides regular hooks
into that playback loop.

Also, these CSS classes don't necessarily make text invisible - they may
just change its color or font weight (think of karaoke).

> Basically no  onenter event is raised for the internal times.

Why would a JS dev need to be alerted of CSS changes? What's the use case?

> BTW, it seems that in the 5.1 nightly nothing ever raises onenter, is
that right?

Really? If so then that's a recently introduced bug.

Silvia.