Re: XSL-WG solicits comments on FO Draft

[Karen Lease <lease@xxxxxxxxxx>]

Stephen Deach wrote:
> 
> The XSL working group is soliciting comments from the xsl-list to improve
> the readability and understandability of formatting object and property
> descriptions in the April draft ...

Here are a few thoughts for starters.

Section 3.4
More diagrams would certainly be useful, especially concerning the
relative directions (block-progression, line-progression,
inline-progression) with a couple of writing-mode specific examples. The
discussion of space resolution is very dense, but I unfortunately don't
have any brilliant ideas on how to make it easier to grasp.

Section 3.5
The statement that "a small subset of the XSLT expression language may
be used in the values of the formatting properties" makes me nervous. I
would have thought that the expression language of XSL(F) is a superset
of that in XSLT (quantities and the functions dealing with inherited
values in addition to the XSLT functions and expressions.) It is
certainly true that the computed value of expressions involving
inherited values depends on the structure of the result tree.
(For comparion, jade resolves this type of expression before sending
values to the back-end; to do this it obviously has to manage the
inheritance.)

Section 3.6 (datatypes)
Space specifiers seem to currently be the only compound datatypes. Are
there other cases where this type of syntax is likely to be used?

4.7 Lists
I have a hard time understanding the placement rules for list-item-label
and list-item-body objects. The standard says :
"In the inline-progression-direction these areas are positioned
according to the start- and end-indent properties of the content of the
fo:list-item-label and fo:list-item-body formatting objects. It is an
error if the areas overlap."

The start-indent on the body object seems normal, but it doesn't seem
reasonable to put a large end-indent on the label content, especially in
the context of variable-sized windows! 
If an end-indent is specified on the label, then we can get a
"top-aligned" style of composition. But this is not typical list
composition.
Typical lists are single blocks, and label content is generally inline
not block. But in 4.7.4 the spec says that fo:list-item-label has
block-level FOs as children.
I suppose that label box is deemed to end where its content ends, so in
the normal case of a short list-item-label, the result is as expected.
Or perhaps the key is in the "provisional-label-separation" and
"provisional-distance-between-starts" properties. In any case, some
pictures would help.

(OPINION) Personally, I much preferred DSSSL's line-field object to the
four list-* objects in XSL. With line-field, it was easy to do a basic
lists with hanging indents. And several line-fields handled simple
tabulated data without using full-blown table flow objects. I can't
figure out how to get the same effect in XSL, since width properties
don't seem to be specifiable on the inline-sequence flow object.

Section 5
General
. A clear distinction between and inherited and non-inherited properties
would be very useful. Only a few properties currently state this
clearly. I generally use common sense and my DSSSL experience to make
the distinction, but I would feel better if it were official.

. What is the difference between a boolean value and one that permits
only the enumerated values 'yes' and 'no'? Couldn't these latter be
specified as boolean as well? For example, keep-with-previous (5.7.4) is
Boolean and may-break-before-row (5.11.18) is yes or no.

5.7 keep-with-
When XSL gets around to supporting more sophisticated page composition,
keeps properties (and widow and orphan properties, 5.14) will need to be
"compound" like space and to include a priority for keeping the objects
together.

5.13.2 rule-style. Only the value "none" is specified. The rest is
missing.

5.15 float, clear
The values left and right are writing-direction centric.

5.17 Link properties
Perhaps add a "indicate-source" property for link FOs which gives a hint
to the UA about whether to dynamically highlight the link source (cursor
change for example). Static "highlighting" can be done using standard
typographic properties.

-----------------------------------------------------------------
Style is my business
Karen Lease
Sogitec Industries


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list