W3C home > Mailing lists > Public > public-tt@w3.org > April 2009

Re: ISSUE-68 (tts:backgroundColor): Region content

From: Glenn A. Adams <gadams@xfsi.com>
Date: Sat, 25 Apr 2009 16:44:44 +0800
To: Sean Hayes <Sean.Hayes@microsoft.com>
CC: Public TTWG List <public-tt@w3.org>
Message-ID: <C618EE7C.A5DB%gadams@xfsi.com>

First, we need to get on the same page regarding terminology; since DFXP
makes (logical) use of XSL formatting semantics, we had best start with XSL,
not CSS;

In DFXP 9.3.3, we map DFXP elements from a synchronic intermediate document
instance to the following XSL FO hierarchy:

<fo:root>                     <!-- from tt:tt     -->
  <fo:layout-master-set>      <!-- from tt:tt     -->
     <fo:simple-page-master>  <!-- from tt:tt     -->
       <fo:region-body/>      <!-- from tt:tt     -->
  <fo:page-sequence>          <!-- from tt:layout -->
    <fo:flow>                 <!-- from tt:layout -->
      <fo:block-container>    <!-- from tt:region -->
        <fo:block>            <!-- from tt:body   -->
          <fo:block>          <!-- from tt:div    -->
            <fo:block>        <!-- from tt:p      -->
              <fo:inline/>    <!-- from tt:span   -->

We then apply the formatting semantics of XSL to this FO tree in order to
produce an "XSL FO area tree" as follows (with lineage shown on right):

page-viewport-area                ; fo:page-sequence(*) < tt:{layout,tt}
 page-reference-area              ; fo:page-sequence(*) < tt:{layout,tt}
  region-viewport-area            ; fo:page-sequence(*) < tt:{layout,tt}
   region-reference-area          ; fo:page-sequence(*) < tt:{layout,tt}
    main-reference-area           ; fo:page-sequence(*) < tt:{layout,tt}
     span-reference-area          ; fo:page-sequence(*) < tt:{layout,tt}
      normal-flow-reference-area  ; fo:page-sequence(*) < tt:{layout,tt}
       block-viewport-area        ; fo:block-container  < tt:region
        block-reference-area      ; fo:block-container  < tt:region
         block-area               ; fo:block            < tt:body
          block-area              ; fo:block            < tt:div
           block-area             ; fo:block            < tt:p
            line-area             ; fo:block            < tt:p
             inline-area          ; fo:inline           < tt:span

(*) page-{viewport,reference}-area[s], region-{viewport,reference}-area[s],
and {main,span,normal-flow}-reference-area[s] are generated by
fo:page-sequence by using fo:simple-page-master and fo:region-body. Since
fo:page-sequence is generated by tt:layout, and
fo:{simple-page-master,region-body} are generated bo tt:tt, these areas have
a lineage that combines the input from tt:tt and tt:layout.

Now, we can see from this skeletal area tree that <tt:body> does not, in
fact, correspond to what CSS calls "the canvas", nor does it correspond to
the CSS "initial container block".

In the DFXP use of the above XSL FO tree, it is the case that the following
reference areas are coincident (i.e., their edges are coincident), and,
further, the writing mode of each of these reference areas is the same:


If we look at these areas and trace them back to their generating FOs, we
see that area traits that involve geometry and background color may possibly
derive from the following:


Reviewing these options, it appears that background-color applies only to

At present, DFXP maps the tts:extent property on <tt:tt> to the
page-{height,width} properties on fo:simple-page-master. See DFXP 9.3.3 (3).
However, we don't specify any mapping to the background-color property on
fo:region-body. Since XSL (and CSS) define the initial value of
background-color to be 'transparent', then the effective background color
depends upon the specific DFXP presentation processor implementation's
choice of a default background for the page-reference-area.

If we want to allow for DFXP authors to specify the background color that
applies to fo:region-body, which would thus form the background for all
tt:regions (as mapped to fo:block-containers), then we would need to allow
tts:backgroundColor on <tt:tt> as we have done with tts:extent. We would
then specify this mapping in 9.3.3 (3).

If we don't take any action, then it is transparent.

On 4/24/09 10:53 PM, "Timed Text Working Group Issue Tracker"
<sysbot+tracker@w3.org> wrote:

> ISSUE-68 (tts:backgroundColor): Region content
> http://www.w3.org/AudioVideo/TT/tracker/issues/68
> Raised by: Sean Hayes
> On product: 
> CSS (referenced through XSL) defines: "The background of the root element
> becomes the background of the canvas and covers the entire canvas, anchored
> (for 'background-position') at the same point as it would be if it was painted
> only for the root element itself. The root element does not paint this
> background again."
> My interpretation of the canvas background is that is the plane on which the
> blocks are laid out, and then this is seen through the viewport-area of the
> region (which is equal to the content area). Can we clarify if this is
> correct, and which element (if any) controls the background colour of the
> canvas (and thus the content area), or whether it is always transparent. (My
> working assumption has been that it is the <body> element which controls it).
Received on Saturday, 25 April 2009 08:45:34 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 5 October 2017 18:24:04 UTC