RE: WebVTT

Disregard last comment re 5.1 nightly.

Ars longa phonemail brevis
________________________________
From: Sean Hayes<mailto:Sean.Hayes@microsoft.com>
Sent: ‎15/‎06/‎2013 15:32
To: Silvia Pfeiffer<mailto:silviapfeiffer1@gmail.com>
Cc: John Birch<mailto:John.Birch@screensystems.tv>; public-tt@w3.org<mailto:public-tt@w3.org>
Subject: RE: WebVTT


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

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

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

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

Basically no  onenter event is raised for the internal times.

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

Silvia.