CSS and XSL

["Oren Ben-Kiki" <oren@xxxxxxxxxxxxx>]

I wrote:
>> It seems to me as if previous notions to XML-ize CSS have never resisted
the
>> attempt to tinket with the CSS semantics, so that now every time the
issue
>> is raised there's an automatic resistance reflex, regardless of the
actual
>> proposal merits.

Chris Lilley <chris@xxxxxx> wrote:
>(I don't like attempts to declare my arguments to be an automatic
>reflex.) On the other hand, you seem to have totally missed both
>
>a) what Paul was suggesting and
>b) the fact that I was objecting to Pauls suggestions
>
>I regard my arguments as an informed opinion, based on my work as Chair
>of the CSS WG, Chair of the SVG WG (whichm naturally, uses XML), and
>alternate member of the XSL WG.

You are of course absolutely right. I read your message wrong - my mistake -
and overreacted. Sorry. All I can say in my defense is that it was a
stressful week and I got mixed up following the threads, but even that
doesn't justify my choice of words. Again, I apologize.

This mix up aside...

I said:
>> ...All these attributes could be limited to two tags: <css:rule> and
>> <css:style>.


And you replied:

>Since the selector is always implicit, one is back at a <css:style>
>attribute.


? Isn't <css:style> a tag? I was thinking of

<css:sheet>
    <css:rule match="(xsl-like-pattern)" font="..."/>
<css:sheet>

And:

<AnyElement>
    <css:style font="..."/>
    ...
</AnyElement>

This keeps each CSS attribute as an XML attribute, but in just two elements.
The idea is to avoid the need for separate parsing of style attributes -
each attribute would be atomic. This is why I don't like "border" but have
no problem with "border-style". From your comment I gather you have
something else in mind?

A second point is:

I said:
>> If you limit them [CSS attributes] to elements
>> which are in the <css:*> namespace, then
>> you have no name space collisions at all.
>
>OK, and how do you validate this? You can't, using DTDs; and you can't,
>today,  using schemas (I would be glad to be proved wrong on the latter
>point).


Currently, one can't say in a DTD that an element may contain a sub element
from a different DTD. This means that the DTD for a CSS annotated document
must include the CSS DTD. This DTD is pretty short - it defines just three
tags: <css:sheet>, <css:rule> and <css:style>, though admittedly the last
two have a lot of attributes.

I assume that as an interim solution, given a standard DTD fragment for CSS,
people could simply incorporate it into their own DTDs. The damage to the
rest of their DTD is minimal - allowing a <css:style> sub element to certain
elements, and is no worse then today's approach, in which one has to add a
"style" attribute to the same elements. In fact, if the "class" attribute is
moved to <css:style>, this approach would be less intrusive to people DTDs
then the current one.

Of course, I agree with you that:

>... validation is useful,
>and having to update all DTDs whenever a style sheet language changes is
>a real bad idea.


But note that today, there is no validation to the CSS attributes nested in
a style attribute. So we have a tradeoff: what is worse, no validation or
updating DTDs once a year (say)? Note that if someone doesn't
generate/implement certain CSS attributes, he has no need to update the DTD
even if the official one changes.

If there was a way in a DTD to say "this element can have any attribute",
then people could choose from specifying this for <css:rule> and
<css:style>, giving them today's mixture of no validation and DTD stability.
Alternatively, they could embed a W3C standard CSS DTD fragment in their
DTD, gaining validation at the cost of possibly having to update it at
certain intervals. Today we are forced to using the first approach only.

Finally, you wrote:

>FO is not attributes. The point is that it has structure. it has things
>like queues. It has more things than you can do with a decorated source
>tree, even if that source tree has been transformed first.


I think one could duplicate the semantics of the FO objects by adding
attributes to CSS which declare a certain element to behave like the
equivalent FO object. We already have an example: a display="block" object
is very similar to an <fo:block> object. Why couldn't any additional
functionality, such as queues, be handled in the same way?

Have fun,

    Oren Ben-Kiki


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