<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<!DOCTYPE bugzilla SYSTEM "https://www.w3.org/Bugs/Public/page.cgi?id=bugzilla.dtd">

<bugzilla version="5.0.4"
          urlbase="https://www.w3.org/Bugs/Public/"
          
          maintainer="sysbot+bugzilla@w3.org"
>

    <bug>
          <bug_id>28105</bug_id>
          
          <creation_ts>2015-02-26 07:47:21 +0000</creation_ts>
          <short_desc>Should the rendering area be the video element or the video box within?</short_desc>
          <delta_ts>2015-02-27 10:56:17 +0000</delta_ts>
          <reporter_accessible>1</reporter_accessible>
          <cclist_accessible>1</cclist_accessible>
          <classification_id>1</classification_id>
          <classification>Unclassified</classification>
          <product>TextTracks CG</product>
          <component>WebVTT</component>
          <version>unspecified</version>
          <rep_platform>PC</rep_platform>
          <op_sys>All</op_sys>
          <bug_status>NEW</bug_status>
          <resolution></resolution>
          
          
          <bug_file_loc>http://dev.w3.org/html5/webvtt/</bug_file_loc>
          <status_whiteboard></status_whiteboard>
          <keywords></keywords>
          <priority>P2</priority>
          <bug_severity>normal</bug_severity>
          <target_milestone>---</target_milestone>
          
          
          <everconfirmed>1</everconfirmed>
          <reporter name="Philip Jägenstedt">philipj</reporter>
          <assigned_to name="This bug has no owner yet - up for the taking">dave.null</assigned_to>
          <cc>eric.carlson</cc>
    
    <cc>fs</cc>
    
    <cc>philipj</cc>
    
    <cc>rick.eyre</cc>
    
    <cc>silviapfeiffer1</cc>
          
          <qa_contact name="Web Media Text Tracks CG">public-texttracks</qa_contact>

      

      

      

          <comment_sort_order>oldest_to_newest</comment_sort_order>  
          <long_desc isprivate="0" >
    <commentid>118172</commentid>
    <comment_count>0</comment_count>
    <who name="Philip Jägenstedt">philipj</who>
    <bug_when>2015-02-26 07:47:21 +0000</bug_when>
    <thetext>http://dev.w3.org/html5/webvtt/#processing-model says:

&quot;Let video be the media element or other playback mechanism.&quot;

&quot;The viewport (and initial containing block) is video&apos;s rendering area.&quot;

This isn&apos;t explicit about what the rendering area is when the &lt;video&gt; element is not the same size as the video rendered within. This can happen with object-fit, both with the default contain but also any value other than fill.

Points to consider:

* Percentage positions in WebVTT ought to be relative to the video. Otherwise cues may end up obscuring what they were indented to avoid.

* Using the video rendering area is a bit more complicated implementation-wise.

* Using the video rendering area would make it impossible to deliberately use a video which is taller than needed, so that the captions can be rendered beneath the video.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>118173</commentid>
    <comment_count>1</comment_count>
    <who name="Philip Jägenstedt">philipj</who>
    <bug_when>2015-02-26 07:47:45 +0000</bug_when>
    <thetext>Fredrik, any thoughts on this?</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>118174</commentid>
    <comment_count>2</comment_count>
    <who name="Fredrik S">fs</who>
    <bug_when>2015-02-26 09:55:08 +0000</bug_when>
    <thetext>When I&apos;ve thought about I have mostly ended up thinking of the cases where the video ends up being letter-boxed. In those cases (with subtitles) I don&apos;t see why you wouldn&apos;t want to be able to place cues in the non-video area.
I can definitely see how more strictly positioned cues would want to use the actual video-area though. (I suppose that more often than not these days, the non-video are is empty/small.)
So it almost seems like you&apos;d like to use one for line-snapped cues and another for non-line-snapped...</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>118175</commentid>
    <comment_count>3</comment_count>
    <who name="Silvia Pfeiffer">silviapfeiffer1</who>
    <bug_when>2015-02-26 10:04:08 +0000</bug_when>
    <thetext>Letter-boxed video often has the captions in the bottom &quot;matte&quot;: http://en.wikipedia.org/wiki/Letterboxing_(filming) .
I personally think that&apos;s a good idea, so I wouldn&apos;t want to restrict cues to rendering within the video pictures, but use the whole video element&apos;s rendering area.

The effect that has on pillar-boxed video may be that cues may end up further to the right / left than originally placed, but I doubt that would typically have much effect on obscuring objects.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>118194</commentid>
    <comment_count>4</comment_count>
    <who name="Philip Jägenstedt">philipj</who>
    <bug_when>2015-02-27 06:41:31 +0000</bug_when>
    <thetext>Fredrik, I kind of agree, an argument can be made for using different boxes for snap-to-line and non-snap-to-lines layout. But then what about a (horizontal LTR) cue which is positioned in the right 80% of the cue but uses snap-to-lines layout? Presumably there&apos;s something to avoid in that left 20%, but widening the media element could cause it to become obscured.

How about clarifying that it is the media element&apos;s full extent that is used, and cautioning authors to make the media element match the video size if they&apos;re using absolutely positioned cues?

A bit of a cop-out, but if I have to pick one behavior this is definitely the one. Maybe if it becomes a problem some setting could be added to match the video box instead?</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>118196</commentid>
    <comment_count>5</comment_count>
    <who name="Fredrik S">fs</who>
    <bug_when>2015-02-27 09:38:26 +0000</bug_when>
    <thetext>(In reply to Philip Jägenstedt from comment #4)
&gt; Fredrik, I kind of agree, an argument can be made for using different boxes
&gt; for snap-to-line and non-snap-to-lines layout. But then what about a
&gt; (horizontal LTR) cue which is positioned in the right 80% of the cue but
&gt; uses snap-to-lines layout? Presumably there&apos;s something to avoid in that
&gt; left 20%, but widening the media element could cause it to become obscured.

Yes, at the end of the day it&apos;s always hard to infer what the author intended...

&gt; How about clarifying that it is the media element&apos;s full extent that is
&gt; used, and cautioning authors to make the media element match the video size
&gt; if they&apos;re using absolutely positioned cues?
&gt; 
&gt; A bit of a cop-out, but if I have to pick one behavior this is definitely
&gt; the one. Maybe if it becomes a problem some setting could be added to match
&gt; the video box instead?

I suppose that&apos;s a reasonable resolution. Another option might be to allow making a choice between the two (are there more?), but keeping that on hold is probably better.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>118198</commentid>
    <comment_count>6</comment_count>
    <who name="Philip Jägenstedt">philipj</who>
    <bug_when>2015-02-27 10:56:17 +0000</bug_when>
    <thetext>Rick, which box do you use in Gecko?

Eric, is WebKit still using the whole of the video area (assuming no video controls)?

If everyone already uses the media element dimensions, I should just make that clear in the spec.</thetext>
  </long_desc>
      
      

    </bug>

</bugzilla>