This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 25660 - [WebVTT] Restore size clamping in rendering
Summary: [WebVTT] Restore size clamping in rendering
Alias: None
Product: TextTracks CG
Classification: Unclassified
Component: WebVTT (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Philip Jägenstedt
QA Contact: Web Media Text Tracks CG
Whiteboard: v1
Depends on:
Reported: 2014-05-12 09:23 UTC by Philip Jägenstedt
Modified: 2015-11-09 15:23 UTC (History)
4 users (show)

See Also:


Description Philip Jägenstedt 2014-05-12 09:23:41 UTC
The maximum width clamping was removed in bug 20037. This has been implemented and shipped for a long time, in Presto, WebKit and Blink.
Comment 1 Silvia Pfeiffer 2014-05-12 09:41:32 UTC
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.
Comment 2 Philip Jägenstedt 2014-05-12 11:18:42 UTC
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.
Comment 3 Silvia Pfeiffer 2014-05-12 11:42:46 UTC
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.
Comment 4 Philip Jägenstedt 2014-05-13 12:12:45 UTC 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.
Comment 5 Silvia Pfeiffer 2014-06-08 11:29:52 UTC
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.
Comment 6 Philip Jägenstedt 2014-06-08 18:49:24 UTC
What's the use case for a non-clamping size?
Comment 7 Silvia Pfeiffer 2014-06-09 02:30:18 UTC
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
Comment 8 Philip Jägenstedt 2014-06-09 12:27:40 UTC
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 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.
Comment 9 Silvia Pfeiffer 2014-06-09 12:34:20 UTC
OK, let's change the clamping back.

I would like to see the bounding box approach specified, though.
Comment 10 Silvia Pfeiffer 2014-06-09 13:10:18 UTC
Please extract out of only the changes to re-introduce size clamping.
Comment 11 Philip Jägenstedt 2014-06-09 14:14:11 UTC
(In reply to Silvia Pfeiffer from comment #10)
> Please extract out of only the changes
> to re-introduce size clamping.

Will do!
Comment 12 Simon Pieters 2015-11-05 14:22:45 UTC
Philip, was there a commit or so for this somewhere I can look at?
Comment 13 Philip Jägenstedt 2015-11-05 14:41:17 UTC
Comment 14 Simon Pieters 2015-11-09 15:23:36 UTC
OK so this bug was fixed in the above PR. Please reopen if I misunderstood.