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: Sun, 26 Apr 2009 10:44:54 +0800
To: Sean Hayes <Sean.Hayes@microsoft.com>
CC: Public TTWG List <public-tt@w3.org>
Message-ID: <C619EBA6.A5ED%gadams@xfsi.com>


On 4/25/09 6:28 PM, "Sean Hayes" <Sean.Hayes@microsoft.com> wrote:

> 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.

[GA] Correct, per XSL 1.1 4.9.4, since background-attachment is not
specified and has initial value of 'scroll' and since the refined
block-progression-dimension of the block-reference-area is not larger than
the block-progression-dimension of the block-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.

[GA] Correct, per XSL 1.1 4.2.5 case 2 or 3c'.

> 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.

[GA] Correct, though it is more clear to elaborate the last "content area
after edge" as "after edge of content-rectangle of block-viewport-area".

> 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).

[GA] Note that XSL 1.1 6.5.3 does already say as much about

"The block-progression-dimension of the reference-area is not

However, this applies to the parent area of block-area (1) in this example.
So it is the block-reference-area generated by tt:region that is effectively
the "infinite plane". In contrast, the allocation-rectangle of block-area
(1) generated by tt:body is constrained to the cumulative geometries of its
children (since we don't permit margin, padding, or border on tt:body).

> 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)

[GA] As you point out, this can be achieved in XSL by specifying an
appropriate space constraint S on the trailing edge that ends
block-reference-area P (see XSL 4.2.5 last paragraph).

I believe this can be done by modifiying DFXP 9.3.3 (6) to synthesize the
following properties on the fo:block generated by tt:body:


where <region-bpd> is computed as follows:

if ( is-horizontal-writing-mode ( tt:region ) ) {
  region-bpd := computed-height ( tt:region );
} else if ( is-vertical-writing-mode ( tt:region ) ) {
  region-bpd := computed-width ( tt:region );
} else {
  region-bpd := 0pt;

This space constraint allows for a minimum of 0pt (the default) and optimum
and maximum of the available extent in the block progression direction of
the region. As such, it should ensure that there is sufficient whitespace
content at the after edge of the block-area (1) generated by tt:region, and
thus, fill out its content-rectangle to ensure the proper after padding

I will go ahead an adopt this as a resolution for this issue, but I also
want to test it on an XSL formatter to make certain my interpretation is

Received on Sunday, 26 April 2009 02:45:36 UTC

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