Comments on latest XSL Draft

Sharon

Congratulations on a very good XSL WD. Needless to say I have some comments!
What follows are just my initial comments, on a quick read-through.

Page Sequence
The model of page-sequence as (static-content*, flow) has some worrying
implications. Firstly there is the question of things like dictionary
headers, where the contents of the "static-content" depend on the contents
of the flow. Secondly there is a question of display timing in web
environments, where I would prefer to be able to display the flow before the
static content, rather than the other way around. Is there any reason why
you could not extend the model to (static-content*, flow, static-content*) ?
This would also serve to make stylesheets more natural as you could define
the static content for the region-before, then the one for the region-body
and then the region-after rather than, as at present, always having to
define the region-after before the region-body because the latter is a flow
rather than static content.

The use of margin-top, margin-bottom, margin-left and margin-right in place
of space-before, space-after, space-start and space-end should be deprecated
so that we get them phased out asap.  Similarly other uses of top, bottom,
left and right will eventually lead to user errors in multilingual setting
unless deprecated. (I realise the imperative for ease of change over from
CSS, the propensity of Latin language on the Web, etc. I also realise the
advantages of mixing Hebrew/Arabic and Latin languages on the same page
using a stylesheet with one entry per element, which is only possible if you
replace the left/right convention with a start/end one. In any other case
you need a separate stylesheet statement per writing direction. This means
that any changes to the style may have to be done twice, with a greatly
increased chance of errors occuring. ) Note that this applies to things like
floats (and clear) for which, to me, absolute positions do not really make
sense in the overall model.

The presumption for page numbering seems to be that it will be based on
incrementable numbering, with no overrides, or allowances for numbering
using non-adjacent chararacter sequences. What happens if, at some stage, I
want to number pages alphabetically, but forbid the use of I, O and V? (Typo
warning: look out for initial-page-numer)

Thoughts re scroll-bars and rotated viewports.
Does it make sense to allow rotation of a scrollable viewport on a "page",
or of its contents? Scrollability is a feature of web tools, not printed
text. Scroll bars are designed to move you from top to bottom of the
viewport contents or from start to end of a line, but the convention on all
computers I have seen is that the vertical scroll bar moves you from top to
bottom while the horizontal one moves you from start to end. There should be
no need for scroll bars on anything that has been "rotated with respect to
the page area". (Viewport rotation should be viewed with scepticism!)

The rules for defining column reference-areas seem to make it impossible to
define unequal width columns (as used on many web pages as well as some
magazine layouts) or more than two columns each with space for a change bar.
(I'm surprised Microsoft have not complained about this!)

Why does  <fo:initial-property-set font-variant="small-caps"/> get
transformed into
  <fo:initial-property-set font-variant="small-caps">
  </fo:initial-property-set> during formatting? Surely either it stays as an
empty tag or the end tag gets moved to the end of the text that is to go in
the block.

Otherwise it seems to be coming along nicely.

Martin

Received on Thursday, 13 January 2000 07:40:56 UTC