Shorthands and Inheritance

Max Froumentin <mf@w3.org> wrote:

> Property refinement/resolution make it possible to have an inheritance
> mechanism which makes it much easier to write stylesheets as you don't
> need to specify everything everywhere.  It also allows shorthand
> properties and relative units, the latter being very handy using
> several stylesheets on the same document (e.g. if you want to add a
> user template saying something like 'make these headers twice as
> big').
> Other (minor) advantages I can think of are: it makes the FO file
> easier to read (in case you have to), it produces shorter documents
> and it makes it easier to restyle an FO file on the client style (if
> you're unlucky enough to receive FO files directly).

My main concern is not about using CSS2; it's about making XSL a superset of
CSS2. In my opinion, XSL editors lack  selectivity in borrowing from CSS. There
are many things in CSS that don't really fit into XSL processing model, and
should be dropped. But "the legacy is hard to die": most useless CSS2 properties
survive as shorthands [1], and CSS2 weird quirks percolate to XSL [2, 3]. Let us
not forget that

1) XSL-FO is not meant to be read by humans except for debugging purposes;
    no need to optimize it for readability;

2) XSL-FO is not meant for transmission; making XSL-FO documents
    compact is not an advantage. (By the way: we could achieve compactness
    by shortening attribute names. If we don't, there's a reason for it);

3) XSL-FO document tree is primarily meant to be an abstract
    representation, internal to a renderer engine; in this situation,
    several explicit attributes is by far more preferrable than a single
    cryptic shorthand;

4) XSL-FO is used in conjunction with XSLT - a much more
    powerful language than CSS selectors. This alleviates many problems
    of stylesheet readability/maintenance. In my opinion, proper use of
    xsl:use-attribute-sets constitutes a good alternative to shorthands;

5) XSL-FO is an XML offspring, and should obey XML design principles.
    These include simplicity of machine processing and redundance kept
    to the minimum.

There's one more reason: I'd like to see the XSL spec readable and compact. I
have a strong feeling that attempts to achieve full CSS2 compatibility spoil the
spec and make it blow up.

In my opinion, XSL editors should have more freedom to remove CSS things. E.g.
shorthands are definitely a Bad Thing, an extra syntax level that makes document
tree representation more complex, disabling its direct parsing by XML parsers -
for which sake? It does not add anything to functionality, and can be perfectly
emulated in XSLT. (See also [1] below).

The same for inheritance: it is useful in many situations, but it hinders
validation and lengthens processing. A right solution would be to limit it to a
necessary minimum: let inheritable properties be inheritable, but leave all
others in their right places. Currently, every property (except @id and few
others) can get a value of "inherit", and be specified everywhere. Have you ever
seen a stylesheet that makes use of "inherit"? I have some experience in writing
stylesheets; despite this value is supported in our formatter, I have never
found any application to it. Maybe it was useful with CSS selectors; with XSLT,
I am sure it's useless. Removing it (as it was in the WD of 1999-04-21) would
actually simplify processing and permit better validation. (This would also
permit to remove ugly parentheses from URI-specification, as it won't be
ambiguous any more).

The same is true for functions like "from-parent()",
"from-nearest-specified-value()", etc. I have a feeling that they are pretty
useless when you have XSLT to produce the tree.

All these should permit to make the structure of XSL-FO documents more rigid. I
don't pretend to have a DTD, though I continue to think it wouldn't be bad :-).

Sorry for being verbose,
Regards,

Nikolai Grigoriev
RenderX




[1] An example: do you think 'vertical-align' is useful? It maps to a series of
inline-level alignment properties in such a way that in each case, a single
property would suffice to express the meaning. It has lost a part of CSS2
semantics as it does not apply to table-cells any more. So it adds nothing in
terms of conciseness - but generates confusion due to semantic change.

[2] Let's take a quiz: if I write <fo:table table-layout="fixed">, what will be
the value for 'table-layout'? Right: it will be "auto" (because the default
value of 'width'="auto" overrides the explicitly specified 'table-layout'). Is
it intuitive? For me, not. When I asked XSL editors about reasons for this, I've
got an answer: "it's CSS2 that says so". I wonder if XSL editors aren't free to
fix evident inconsistencies in CSS?

[3] My favourite topic: background images are taken directly from CSS, and thus
cannot be neither scaled nor rotated in XSL. OK, after waiting a year, we have
implemented them as extensions to the spec; but I still wonder what was the
reason for keeping the CSS solution?

Received on Tuesday, 13 February 2001 18:59:52 UTC