Re: WebVTT

On Thu, Jun 13, 2013 at 2:58 AM, Sean Hayes <Sean.Hayes@microsoft.com> wrote:
>
>
>> That's all there is - the mailing list and the bugs. Just add your name to all the CG bugs (all you need to do is click the "Add me to CC list" toggle button at the top right and hit "Save Changes" when you are on the page of a bug). There's not that many.
>
> Yes I know how the bugs list works. I guess my point is that some of those discussions haven't been updated in months, I see a couple of emails a week at most on the CG. This spec was claimed as 'substantially done', however I think that is evidently something of an overstatement, and at this rate of progress you are going to make TTMLs 10 year gestation look positively lightning.

I should probably stop discussing on this list and get onto these bugs indeed.


>>> My concern is that one cannot pick an arbitrary rectangle on the screen for example 0vw 80vh to 60vw 94vh with centered text using the controls in the current spec text.
>
>>The theory is that because you have a centered text (i.e. align:middle), you need to specify the middle of your cue as the cue position (i.e. line:60%, position:47%). Then you specify the cue's width appropriately (i.e. size:94%). That should do it.
>
> Well I want the middle of my cue to be at 30vw. So not sure where 47% comes in

You're right, it should be 30% (I mixed up vh and vw).

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

>  I don't see any mechanism for vertical centering of the text, so top will always be line, yes?

Yes.



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


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


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


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


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


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


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


>>> But even after removing the reposition text I still cannot have a centered box that is left or right aligned in the video and is wider than 50% of the video width.
>
>>You will be able to, once it's changed. And also, right now, the region spec allows you to do this.
>
> 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.


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


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


Silvia.

Received on Saturday, 15 June 2013 13:30:56 UTC