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

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

From: Sean Hayes <Sean.Hayes@microsoft.com>
Date: Sat, 25 Apr 2009 11:28:49 +0100
To: "Glenn A. Adams" <gadams@xfsi.com>
CC: Public TTWG List <public-tt@w3.org>
Message-ID: <AB3FC8E280628440B366A29DABB6B6E8070E880F4A@EA-EXMSG-C334.europe.corp.microsoft.com>
Yes its difficult when we use the same terms in different vocabularies. Thanks for that exposition, it makes it easier for me to rephrase the question in XSL terms.

I'm concerned only with the semantics of this section:
       block-viewport-area        ; fo:block-container  < tt:region     tts:backgroundColor"red"
        block-reference-area      ; fo:block-container  < tt:region
         block-area   (1)         ; fo:block            < tt:body       tts:backgroundColor"blue"
          block-area   (2)        ; fo:block            < tt:div

If the block-area for body is not big enough to overflow the block-viewport-area, then the background (let's say red for argument's sake) is rendered on the viewport area. So we have a red rectangle the size of the region, now we need to inset into this by the padding and draw the content area.
XSL defines that the block-reference-area and block-area (1) have a stacking constraint, so the after-edge of the block-reference-area is after (in the bpd) the after edge of block (1), also the two block areas have a similar stacking constraint. We don't define any spacing after blocks, and the default is 0pt so in fact they are all effectively coincident.

Thus since we said block (1) is not big enough to fill the viewport (let's say it fills 50% of the content area), there is a gap between the after edge of the block-reference-area (which is blue by virtue of containing the blue block-area (1)), and the content area after edge. This area is therefore red, leading to the appearance (but not the reality) that the padding on the after edge is larger than it should be. This is semantically correct, but authorially confusing, especially to someone with a CSS background (A much larger population than those with XSL background, and likely our target audience) who would expect (as I did) the blue rectangle to fill the content area.

So my take on this, as I come more from a CSS background is to define the block-area (1) to in effectively be an infinite plane (this is what I was equating to the CSS canvas for the purposes of timed text, although obviously this is my own interpretation and not currently indicated by the specification). This is possible in XSL by defining an arbitrary amount of spacing between the after edge of block (2) and the after edge of block (1) (although obviously we would need to define this as part of the conversion to XSL-FO).

Now the block-reference-area is forced by the stacking constraint to overflow the viewport area. The background of the block-viewport-area is set to red; coloring the padding region, the background of block (1) [blue] is drawn onto the block-reference-area which is viewed through the block-viewport-area (coincident with the content area), and the result is semantically correct XSL, and visually as expected from a CSS viewpoint (and as non normatively referenced by 7.7.2 http://www.w3.org/TR/REC-CSS2/colors.html#propdef-background-color)

Hope this makes the issue clearer.

Sean Hayes
Media Accessibility Strategist
Accessibility Business Unit

Office:  +44 118 909 5867,
Mobile: +44 7875 091385

-----Original Message-----
From: public-tt-request@w3.org [mailto:public-tt-request@w3.org] On Behalf Of Glenn A. Adams
Sent: 25 April 2009 9:45 AM
To: Sean Hayes
Cc: Public TTWG List
Subject: Re: ISSUE-68 (tts:backgroundColor): Region content

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 10:29:35 UTC

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