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 17473 - WebVTT: Overflowing cues should be clipped, not removed
Summary: WebVTT: Overflowing cues should be clipped, not removed
Status: ASSIGNED
Alias: None
Product: TextTracks CG
Classification: Unclassified
Component: WebVTT (show other bugs)
Version: unspecified
Hardware: PC Linux
: P2 normal
Target Milestone: ---
Assignee: Philip Jägenstedt
QA Contact: This bug has no owner yet - up for the taking
URL:
Whiteboard: v1
Keywords:
Depends on:
Blocks: 17218 19458 28267
  Show dependency treegraph
 
Reported: 2012-06-12 15:45 UTC by Philip Jägenstedt
Modified: 2015-06-08 10:00 UTC (History)
4 users (show)

See Also:


Attachments

Description Philip Jägenstedt 2012-06-12 15:45:36 UTC
Step 10.14 of http://dev.w3.org/html5/webvtt/#webvtt-cue-text-rendering-rules is:

"Done positioning: If there are any line boxes in the (possibly now repositioned) boxes that do not completely fit inside video's rendering area, remove those offending line boxes from boxes."

Rather than trying to remove parts of cues that fall outside of the video content area, we'd like to apply overflow:hidden to simply clip to the content area. This is easier to implement and is slightly better: a line overflow by a single pixel will still be readable. (I bet it would also be easier to do in a polyfill, FWIW.)
Comment 1 vcarbune 2012-06-17 22:55:48 UTC
(In reply to comment #0)
> Step 10.14 of http://dev.w3.org/html5/webvtt/#webvtt-cue-text-rendering-rules
> is:
> 
> "Done positioning: If there are any line boxes in the (possibly now
> repositioned) boxes that do not completely fit inside video's rendering area,
> remove those offending line boxes from boxes."
> 
> Rather than trying to remove parts of cues that fall outside of the video
> content area, we'd like to apply overflow:hidden to simply clip to the content
> area. This is easier to implement and is slightly better: a line overflow by a
> single pixel will still be readable. (I bet it would also be easier to do in a
> polyfill, FWIW.)
I second Philip's suggestion.
Comment 2 Ian 'Hixie' Hickson 2012-07-24 16:08:31 UTC
Having clipped text everywhere is pretty ugly. Are we really sure we want this?
Comment 3 Philip Jägenstedt 2012-07-26 08:27:43 UTC
Not everywhere, just when there was no way fit the cue inside the rendering area, which is a pretty extreme situation. The option is between seeing nothing (current spec) and seeing something (clipping), and clipping seems easier to implement.
Comment 4 Ian 'Hixie' Hickson 2012-08-06 21:29:51 UTC
So we're saying that if the frame is completely filled with captions such that a new caption can't be put in, we're to require that the subtitle be added anyway, just overlapping or overflowing or something.

I guess I can spec that. I'll have to study the algorithm again to work out what exactly to require.
Comment 5 Philip Jägenstedt 2012-08-07 08:31:01 UTC
To clarify, the only suggestion in this bug is to rely on CSS (overflow:hidden) to hide overflowing cues, instead of having the algorithm remove the line boxes. Changing the layout algorithm to avoid overflow/overlap in the first place is discussed in bug 17483.
Comment 6 Ian 'Hixie' Hickson 2012-10-10 21:37:03 UTC
So... what are we putting overflow:hidden _on_? Or should I just replace the current rule in the WebVTT "Done positioning" step that removes the overflowing cues with a rule that says that you must clip the rendering of cues that go outside the video's rendering area?
Comment 7 Philip Jägenstedt 2012-10-12 13:27:08 UTC
A non-overridable overflow:hidden on video or on an invisible child cue root box (which is what Opera has) would work.
Comment 8 Philip Jägenstedt 2012-10-12 13:27:44 UTC
By invisible I of course mean invisible to scripts, not visibility:hidden or anything like that.
Comment 9 Ian 'Hixie' Hickson 2012-10-17 23:54:25 UTC
I don't think the spec has such a concept yet. I think I need to just say that all cues must be clipped to the edge of whatever overall box they're being rendered in, or some such, rather than using 'overflow' itself.
Comment 10 Philip Jägenstedt 2012-10-18 07:48:51 UTC
Yeah, that would be fine.