Re: CSS for XML *outside* of the formatting model

Nils Klarlund writes:
> This question is *not* about using CSS for styling XML documents into
> the CSS formatting model!
> It's about using CSS as a general XML default mechanism for filling in
> missing attribute values (as opposed to filling in "properties" in the
> visual formatting model). SMIL 1.0 is an example where such a use of
> CSS was suggested.
> That suggestion unfortunately is not a perfectly well-defined
> mechanism: since selectors themselves depend on attributes, the order
> in which defaults are inserted affect the result.  This nondeterminism
> is not desirable, of course.
> Did anyone else consider or just note this issue?  A simple solution
> is to insist on an ordering among the attributes.  It is used to
> determine in which order the attributes of an element are assigned
> values according to the stylesheet.
> Any references would be appreciated.

No concrete references, but some discussions I remember that may be
related. Basically, you can either disallow attribute selectors, order
the attributes, order the rules, or consider the application of the
rules to be a single atomic operation:

  - The XML canonicalization draft[1] suggests an ordering of

  - CSS can already base a style on the contents of the STYLE
    attribute, but that doesn't result in a conflict, because the
    STYLE attributes are not changed and the style sheet has its
    cascading algorithm to deal with conflicting rules.

  - STTS[2] is a transformation language that can change attributes
    based on their values. In this case conflicts are avoided because
    the *rules* are applied in a predefined order.

  - You don't need a full ordering among the rules (or the attributes),
    a partial order is enough. When you can make a dependency graph
    between the rules and determine that it has no cycles, that is
    enough, theoretically. However, it is not easy for a human to see
    where the error is when there is a cycle.

  - Do you really need to have attributes in the selectors? If *all*
    default values are set by rules (and none in the DTD/schema), you
    don't need that, I believe.

  - The non-determinism can also be avoided by specifying that all
    rules are applied at the same time. Or stated in another way: that 
    all selectors are matched against the initial state.


  Bert Bos                                ( W 3 C )                              W3C/INRIA                             2004 Rt des Lucioles / BP 93
  +33 (0)4 92 38 76 92            06902 Sophia Antipolis Cedex, France

Received on Tuesday, 14 December 1999 11:20:19 UTC