- 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>
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:simple-page-master> </fo:layout-master-set> <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 --> </fo:block> </fo:block> </fo:block> </fo:block-container> </fo:flow> </fo:page-sequence> </fo:root> 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: page-reference-area region-reference-area main-reference-area span-reference-area normal-flow-reference-area 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: fo:root fo:layout-master-set fo:simple-page-master page-height page-width reference-orientation writing-mode fo:region-body background-* border-* clip display-align overflow padding-* reference-orientation writing-mode fo:page-sequence reference-orientation writing-mode Reviewing these options, it appears that background-color applies only to fo:region-body. 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