Re: CSS and XSL

[Chris Lilley <chris@xxxxxx>]

Paul Prescod wrote:
> 
> "Simon St.Laurent" wrote:
> >
> > If XSL can't deal with the style attribute, then maybe the
> > XSL WG should put some serious thought into how better to 
> > handle it. 

That is a reasonable suggestion, though as I mentioned before brings up
the question to what extent the generation of non-XML syntaxes is in
scope for XSL.

> > As much as I like atomization, being able to 
> > put style information into a single attribute for handling 
> > by a CSS interpreter  - rather than cluttering my documents
> > and likely my DTDs with an incredible profusion of normally 
> > unused style attributes - is convenient and usually 
> > downright sensible.

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

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'
>

subhead { font: 12pt/14pt "Gill Sans", Univers, Helvetica }

would become

<subhead 
  font-style='normal'
  font-variant='normal'
  font-weight='bold'
  font-size='12pt'
  line-height='14pt'
  font-family='"Gill Sans", Univers, Helvetica' 
  font-size-adjust='none'
  font-stretch='normal' 
>

wow, is that ever verbose. 

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.

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.

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

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

7) User style sheets would essentially disappear
   
8) Further development of CSS would require all DTDs to be updated to
add the new attributes.

> 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.

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?

> Anyhow, I'm asking/demanding that CSS be made XML compatible

it already is ...

> 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.

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.


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

Until you start thinking it through. Paul, you generally come up with
well thought out and reasonable suggestions. This one seems to be wildly
off base - it has an enormous slew of problems, removes lots of existing
capabilities and adds nothing except that it makes it easier for the
current XSL draft to write it out.

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'm not so much of a purist that I think that CSS's current 
> syntax should never be used. 

Good.

> All I ask is that when CSS is used directly with XML that
> it should align with XML conventions and syntax. 

That makes it sound really simple until you start examining what that
would mean.

> It makes everyone's life easier.

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.

That concise and separate syntax is of course CSS.

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.

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.

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.

You can see that I am headed in the opposite direction from where I
understand Paul to be heading:

stylistic attributes
a style attribute
a style element
inline style links
out of line style links

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.

--
Chris



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