Column areas and span="all"

Dear XSL Editors,

while implementing multi-column layouts, we have encountered problems in  spec
interpretation.

Consider this case:

<fo:block>
  <fo:block span="all">SPANNED</fo:block>
<fo:block>

The outer block has an implicit value of span="none". Therefore, by definition
of the "span" property [WD 7.18.5], "this object does not span multiple
columns". It looks like having children with span="all" is illegal in this case.

If we swap the location of attributes, we still get interpretation problems:

<fo:block span="all">
  <fo:block>SOME TEXT</fo:block>
<fo:block>

The outer block "shall span all the columns of a multi-column region", and the
inner one "does not span multiple columns" (because @span is not inheritable,
with the initial value of "none"!). Therefore, for a layout to be consistent,
one should never nest blocks with different values of span="all".

This turned out to be extremely unpractical. When designing a stylesheet, you
have to care about every block-level element if it will be placed into a spanned
region, or into a normal one; you need either to switch modes, or to keep an
extra parameter just to pass the @span value down to all block-level descendants
of a spanned  block. (Using "inherited" of "from-parent()" value does not help
much - you should care to specify this on every wrapper inside your block, but
not outside. And "from-nearest-specified-value()" risks to destroy
floats/footnotes).

My suggestion is to get rid of all these. If a flow-region should be subdivided
into span-reference-areas, let us design a special formatting object to
correspond to these areas - let us call it fo:flow-body:

<!ELEMENT fo:flow (fo:flow-body+ | (%block;)+)>

<!ELEMENT fo:flow-body+  (%block;)+>
<!ATTLIST fo:flow-body
          column-count CDATA #IMPLIED
          column-gap CDATA #IMPLIED
          ...
>

This would also yield the formatting more flexible - you could alternate
two-column regions with three-column ones. From the implementation point of
view, there's little difference between having only two possible values for
@column-count in a fo:flow, or having many - you still need to balance columns
in every span-reference-area separately. And  having a possibility to produce
magazine-style layouts is a big plus for any formatter.

Best regards,
Nikolai Grigoriev
RenderX

Received on Tuesday, 14 November 2000 03:39:55 UTC