23269 2013-09-17 22:48:59 +0000 [WebVTT] Cannot get the computed value for height and width in the proc model 2015-10-21 21:09:21 +0000 1 1 1 Unclassified TextTracks CG WebVTT unspecified All All RESOLVED WORKSFORME v1 P2 normal --- 1 rick.eyre dave.null mike philipj public-texttracks silviapfeiffer1 zcorpan dave.null oldest_to_newest 93509 0 rick.eyre 2013-09-17 22:48:59 +0000 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." 99280 1 philipj 2014-01-28 08:59:19 +0000 So, I guess you've worked around this by now, so perhaps you can tell me what the spec should say instead? ;) 99307 2 rick.eyre 2014-01-28 16:53:21 +0000 (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. 121509 3 silviapfeiffer1 2015-06-28 11:30:14 +0000 Prepared PR https://github.com/w3c/webvtt/pull/202 122263 4 philipj 2015-07-22 14:39:23 +0000 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. 123830 5 zcorpan 2015-10-21 21:09:21 +0000 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.