This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
In the processing model step 12 sub-step 2 it asks us to get the height or width of the first line box in boxes. Earlier we set the value for height as "auto" on the root box and since it hasn't been added to the DOM yet there is no layout to compute which results in 0 values. "2. Horizontal: Let step be the height of the first line box in boxes. Vertical: Let step be the width of the first line box in boxes."
So, I guess you've worked around this by now, so perhaps you can tell me what the spec should say instead? ;)
(In reply to Philip Jägenstedt from comment #1) > So, I guess you've worked around this by now, so perhaps you can tell me > what the spec should say instead? ;) Heh :). In Firefox we've worked around this by immediately adding the box to the DOM after the first section of the processing model spec is ran. That's the section that gets the initial computed values, steps 1 - 10. Then we can get the computed values of either height or width, depending on if it's vertical or horizontal text. Then we proceed with steps 11 - 12. It might be helpful if the spec tells us what to do with the list of 'boxes' that we are creating and when to do it. My main issue was that the algorithm tells us to get the computed values without taking the prior step to make sure that _we can_ get the computed values. Alternatively, I would be okay with this being an implementation detail if there's consensus that it should be.
Prepared PR https://github.com/w3c/webvtt/pull/202
Rick, can you take a look at https://github.com/w3c/webvtt/pull/202#issuecomment-123743506 ? I think that the problem here is that the spec pretends that this is all a layout algorithm, while implementations do more or less of it in DOM, more in the case of Gecko I think. The spec is pretty hard to implement as written and that's unfortunate, but I think it's not actually wrong.
As I understand it, the spec basically uses CSS2 terminology to describe the layout. Think of it as similar to the way CSS2 defines how 'float' works. The WebVTT spec does not say "computed value", which is actually a separate concept. The processing model could be defined in terms of creating a DOM and fiddling with the rendered result instead of "Apply the terms of the CSS specifications to nodes within the following constraints", but that is strictly speaking editorial.