25660 2014-05-12 09:23:41 +0000 [WebVTT] Restore size clamping in rendering 2015-11-09 15:23:36 +0000 1 1 1 Unclassified TextTracks CG WebVTT unspecified PC All RESOLVED MOVED v1 P2 normal --- 1 philipj philipj philipj rick.eyre silviapfeiffer1 zcorpan public-texttracks oldest_to_newest 105700 0 philipj 2014-05-12 09:23:41 +0000 The maximum width clamping was removed in bug 20037. This has been implemented and shipped for a long time, in Presto, WebKit and Blink. 105703 1 silviapfeiffer1 2014-05-12 09:41:32 +0000 I think it would be valuable to restore this for the case where no "size" is specified. In all other cases I think it goes against author intention. 105708 2 philipj 2014-05-12 11:18:42 +0000 What's the use case for having cues render outside the video where they cannot be read? Even if there were a use case, this change makes it too easy to overflow by accident. 105709 3 silviapfeiffer1 2014-05-12 11:42:46 +0000 Who is to tell if the author deliberately wanted to place cue text at the edge of the screen or made an authoring mistake by not being able to add up to 100? We don't protect authors from such mistakes on the Web either. They find out by inspection. I agree, though, that if no "size" is given, overflow may happen by accident, so need to fix that. 105834 4 philipj 2014-05-13 12:12:45 +0000 https://github.com/w3c/webvtt/pull/69 changes position in a way that keeps the maximum width calculation. Unless there's a use case for a non-clamping size, that's just extra complexity. 107476 5 silviapfeiffer1 2014-06-08 11:29:52 +0000 I have a counter-proposal. I believe we should introduce an "auto" setting for "size" such that by default clamping is done. But if the author explicitly sets size to be 100% (or another value), we should respect author decisions and not clamp at the frame boundary. 107485 6 philipj 2014-06-08 18:49:24 +0000 What's the use case for a non-clamping size? 107496 7 silviapfeiffer1 2014-06-09 02:30:18 +0000 When auto-clamping, we change much more than just the width of the cue. We potentially change the height of the cue, too, because cues may get new auto line breaks, potentially having unexpected side effects. When not clamping, we risk text being cut off as it overflows the video. However, that would only happen when the author has explicitly defined the cue's width to be such that it extends outside the video. Which side effect do you think is more tolerable: the one that screws up other stuff on the video viewport or the one where some text possibly disappears, where the latter only happens as an authoring mistake? To clarify, here is what I am suggesting (horizontal case only for simplicity): size=auto or size=author-provided em * width should be defined by the bounding box of all the line boxes in the cue * auto-clamping of cue width should occur when the space for the cue box gets too small to avoid line breaks size=author-provided percentage * width should be as authored * overflow is hidden 107518 8 philipj 2014-06-09 12:27:40 +0000 You already have to deal with the number of lines changing due to the user changing the font size, and we have the overlap avoidance algorithm to make the best of the situation. We have potentially serious interop problem on our hands and we need to fix it ASAP. I've fixed it in http://foolip.github.io/webvtt/ by just restoring the size clamping and that's what I want to put on master. If we need a non-clamping size (use case?) also, we can fix that separately. 107520 9 silviapfeiffer1 2014-06-09 12:34:20 +0000 OK, let's change the clamping back. I would like to see the bounding box approach specified, though. 107522 10 silviapfeiffer1 2014-06-09 13:10:18 +0000 Please extract out of https://github.com/w3c/webvtt/pull/69 only the changes to re-introduce size clamping. 107529 11 philipj 2014-06-09 14:14:11 +0000 (In reply to Silvia Pfeiffer from comment #10) > Please extract out of https://github.com/w3c/webvtt/pull/69 only the changes > to re-introduce size clamping. Will do! 124092 12 zcorpan 2015-11-05 14:22:45 +0000 Philip, was there a commit or so for this somewhere I can look at? 124095 13 philipj 2015-11-05 14:41:17 +0000 https://github.com/w3c/webvtt/pull/105 124134 14 zcorpan 2015-11-09 15:23:36 +0000 OK so this bug was fixed in the above PR. Please reopen if I misunderstood.