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

It was my first thought too, to increase the size of the block-reference-area, however I don't think that quite solves the problem, since its background color is set by the region. So, unless, I'm missing something and the block-area (1) would expand too, it seems to me that either we have to say the block-reference-area gets its background-color trait set by the <body> element, or we need to arrange for spacing after the last child of block-area (1) to force the blue rectangle to increase in size.


Sean Hayes
Media Accessibility Strategist
Accessibility Business Unit
Microsoft


-----Original Message-----
From: Glenn A. Adams [mailto:gadams@xfsi.com]
Sent: 26 April 2009 3:45 AM
To: Sean Hayes
Cc: Public TTWG List
Subject: Re: ISSUE-68 (tts:backgroundColor): Region content


inline

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
fo:block-container:

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

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:

space-after.optimum="<region-bpd>"
space-after.maximum="<region-bpd>"
space-after.conditionality="retain"

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

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

Glenn

Received on Sunday, 26 April 2009 21:20:01 UTC