This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The maximum width clamping was removed in bug 20037. This has been implemented and shipped for a long time, in Presto, WebKit and Blink.
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.
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.
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.
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.
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.
What's the use case for a non-clamping size?
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
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.
OK, let's change the clamping back. I would like to see the bounding box approach specified, though.
Please extract out of https://github.com/w3c/webvtt/pull/69 only the changes to re-introduce size clamping.
(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!
Philip, was there a commit or so for this somewhere I can look at?
https://github.com/w3c/webvtt/pull/105
OK so this bug was fixed in the above PR. Please reopen if I misunderstood.