Fw: CSS and XSL

Subject: Fw: CSS and XSL
From: "Oren Ben-Kiki" <oren@xxxxxxxxxxxxx>
Date: Tue, 16 Feb 1999 20:49:52 +0200
Chris Lilley <chris@xxxxxx> wrote:
>Yes. I can see some merit in Pauls suggestion, but the more I consider
>it the more drawbacks I see.
>
>1) It would add (for CSS2) 108 attributes (counting the properties in
>the CSS2 property index and omitting all shorthand ones). That is really
>going to mess up structured editors that let you seee for the current
>element what its attributes are and their values


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

>2) It would require setting all properties individually, including ones
>that are set to their initial values using shorthand properties or where
>related properties are all set to the same value. For example:
>
>section-heading { border: thin solid red }
>
>would become
>
><section-heading
> border-top-style='solid'
> border-right-style='solid'
> border-bottom-style='solid'
> border-left-style ='solid'
> border-top-color='red'
> border-right-color='red'
> border-bottom-color='red'
> border-left-color='red'
> border-top-width='thin'
> border-right-width='thin'
> border-bottom-width='thin'
> border-left-width='thin'

Why? Why couldn't the XML semantics of the attributes be identical to these
specified by CSS? If these attributes are limited to two tags, one could
expect CSS-aware editors to recognize this particular hack:

<css:rule match="section-heading" border="thin solid red"/>

Or, if one would insist on limiting the hack to single-value attributes
(which I'd personally prefer):


<css:rule match="section-heading" border-width="thin" border-style="solid"
border-color="red"/>

Still not that bad.

>3) It would require the same attributes to be duplicated on all elements
>matched by a (fully cascaded) equivalent stylesheet to all the browser
>default, author and reader stylesheets. That seems staggeringly verbose
>and a maintenance nightmare.


Why? the whole idea is to maintain the style data in one place and have it
effect various parts of the XML tree, _not_ to open the style sheets up and
distribute their attributes all over the tree. This allows to dynamically
change the style sheet in one position in the DOM and have it effect the
styling of numerous hard to find elements, without re-transformation.
Otherwise, what's the point? You might as well stick with FOs, they are
better designed.

>4) It would require all these attributes to be added to the xml
>namespace, since the alternative is to either trust that everyone uses
>the same names whenthey make up a namespace, or to use a different
>namespace. The latter would (currently) preclude using valid xml
>documents; its not possible at present to validate a document that uses
>more than one namespace.


Why? If you limit them to elements which are in the <css:*> namespace, then
you have no name space collisions at all. Another benefit of the <css:style>
and <css:rule> approach, besides being compatible with today's DOM access
patterns.

>5) The inheritance model would be really wierd (well, in fact, it would
>not have an inheritance model. All elements would have values set on all
>108 stylistic attributes


Why? The idea is to maintain CSS's model. It is there for a reason.

>6) Dynamic manipulation of styles via the DOM, something that is widely
>done at present, would become vastly more complicated. Querying what


It seems you have missed the whole point. The idea is to be able to write:

document.stylesheets.mySheet.myRule.bg_color = "red";

Which is vastly _less_ complicated then hunting all the elements matching
"myRule" in the DOM tree and changing their background color one by one -
which you _must_ do if you use FOs.

>7) User style sheets would essentially disappear


Why? We're just discussing an alternative syntax for them, after all. It is
XSL which makes it hard to add user style sheets - it is very hard to
combine XSL stylesheets, since they mix transformation and formatting. User
style sheets are typically only concerned with the latter, but there's no
easy way to add a "formatting-only" XSL stylesheet on top of a "full" one.
In CSS, it is relatively easy.

>8) Further development of CSS would require all DTDs to be updated to
>add the new attributes.


In just two points - the attribute lists for <css:style> and <css:rule>. So?

Paul Prescod wrote:
>> You might want to hard-code, default or constrain particular CSS
>> properties in your DTDs. You can do that if properties are directly
>> represented as attributes.


Actually I think this is the wrong way to go about it. A browser should be
able to render a document without a DTD, so you'd _have_ to specify such
defaults as a CSS stylesheet as well. Why repeat the information?

At any rate, Chris has answered:
>OK so you are assuming here that the attributes which used to be
>properties are just added by each person who defines the DTD. And a
>consistent style model that works across namespaces happens how?


By stuffing them into two tags in the <css:*> name space. DTDs don't allows
you to specify that "<css:style> elements directly under a <heading> element
have a default font-size of 'large'", but future schema languages will allow
it. No namespace collisions.

>> Anyhow, I'm asking/demanding that CSS be made XML compatible
>
>it already is ...


This is like saying that postscript is XML compatible since you can write:

<Postscript program="1 2 add"/>

>> in the same
>> way that HTML has been made XML compatible.
>
>Ah, by rewriting the syntax in XML. Taking us back to the dark old days
>of spaghetti documents and no separation of structure and content and no
>user choice in document presentation and no dynamic web pages.


Separation of structure and content? Don't you mean content and
presentation? Anyway, it seems that if anything, the following:

XML data
->
converted by XSL for a particular viewing structure
->
annotated by CSS for a particular viewing style

Is better in this respect then:

XML data
->
converted by XSL for a particular viwing structure _and_ style

Isn't it?

>We (or at least, I) don't want to end up in that place; its where we
>came from - "lets add some more presentation control to HTML with these
>extra attributes". That is why CSS was developed in the first place, to
>rapidly get us out of there.


And we'd like to be able to use CSS technology to add presentation control
to any XML, not just HTML - how is that a step back?

Paul has said:
>> Since XML is a fundamental
>> building block of most upcoming W3C specifications, that
>> seems reasonable.


And I fully agree. It is ridiculous to announce XML as "the" file format and
then propose standards which use a different one, for no good technical
reason.

Chris replied:
>I cannot see why you are suggesting it. Either I am missing something
>which outweighs all these huge disadvantages, or I have completely
>misunderstood your proposal to make the CSS be separate XML attributes.


I think it is the latter. The idea is simply and only to provide an XML
syntax for CSS _as it stands today_. This has the following advantages:

- It allows dynamic modification of style attributes in a single place to
effect arbitrary parts of the document.
- It is compatible with a host of other XML related standards.
- It is compatible with the DOM access patterns used today in browsers to
handle style.
- It therefore requires _much_ less effort to implement in todays browsers
then FOs.

As for disadvantages, these are:

- It requires moving the FO attributes into CSS, which is politically hard
on the FO people.
- It requires depracating the current CSS syntax (just syntax!), which is
politically hard on the CSS people.

In short, I agree with Paul:
>> It makes everyone's life easier.


Chris, your response:
>No, it makes it staggeringly complicated and would cost actual content
>creators millions of dollars in increased document maintenance; would
>make DOM manipulation of style information next to impossible and, to
>keep track of what attribute values you planned to put where, you would
>need some concise and separate syntax that allowed attribute values to
>be set on multiple elements and inherit in useful ways.


Indicates to me you have missed the point completely. Surely by writing:

>That concise and separate syntax is of course CSS.


You don't mean that merely replacing:

<STYLE>
P { bg-color: red; }
</STYLE>

With:

<css:sheet>
<css:rule match="P" bg_color="red"/>
</css:sheet>

Would wreak all this havoc on humanity?

>Its very fashionabe right now to want to express everything in XML, and
>often that makes sense. But it seems that it obscures the underlying
>processing model in folks minds. If the input document is XML and the
>stylesheet is XML and the transformed document is XML and the styled
>transformed document is XML then, it seems, folks get confused; they
>start relying on case conventions to separate out which elements mean
>what where; they get so confused that they think HTML is a formatting
>language.


Would it mix them more if we mentioned in passing all these things are also
files, and Unicode files at that? Imagibe if every application invented its
own character encoding so people wouldn't think "Unicode" is a formatting
language :-) XML is just a _meta_ file format. Saying a file is XML is like
saying it is in Unicode - it tells you _nothing_ about which application
should process it - XSL, word processor, printer driver, whatever.

>CSS is aligned with CSS conventions and syntax, which have beeb used for
>severa years now. It works fine with XML, provided you don't need more
>than a 1:1 mapping between source elements and rendered objects.

>
>With the addition of the transformation capabilities of XSL, which is
>designed to be able to do the sort of transformations that are required
>when styling documents, that limitation goes away; the combination of
>XSL transformation followed by CSS styling of the result gives very
>powerful formatting capabilitis in multiple output media.


Exactly right! And since XSL is so good in generating _XML_ we'd like the
CSS part of the document to be in XML as well. hat simple. No change in
semantics. None.

>All we need now is an out-of-line linking capability, using XLink, to
>associate an XML document with both the XSL sheet that will be used to
>transform it and the CSS stylesheet which will be used to style the
>transformed result - without embedding that information in the XML
>document at all.


Right. But it also helps to be able to generate in-line CSS stylesheets, and
CSS styles, and that would be much easier to do if CSS used XML syntax,
which XSL was designed to generate.

>The CSS Object Model should make it transparent whether a particular
>element got its style via a style attribute, the style element or an
>external stylesheet.

What gave you the idea that XML-izing the CSS syntax would effect this one
iota either way? We are justing talking about providing an alternative
syntax.

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.

Share & Enjoy,

    Oren Ben-Kiki


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


Current Thread