Re: Fw: CSS and XSL

Oren Ben-Kiki wrote:
> 
> 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>.

I agree that would be a better way, but not what Paul seemed to want.

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

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

> Why? 

Bear in mind I was not *proposing* that; quite the opposite. i was
showing that it was a bad idea by counter example.


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

I agree that is a much better idea. Again, recall I was not proposing
this, just showing that it was not a good idea. I am actually pleased
you didn't like it; I didn't either.

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

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

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

No, it seems you have missed my whole point ;-)

You have gone through this list and pointed out all the bad points of
it. My point was to show that it had lots of bad points and was
generally undesirable.


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

So, the content and the style should be different; validation is useful,
and having to update all DTDs whenever a style sheet language changes is
a real bad idea.

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

This is fine and I will be able to evaluate it once the future schema
language arrives.

> >> 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"/>

No, actually, its like saying that CSS is already XML compatible because
you can already use it with XML. While keeping the separation of style
and content.

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

Yes ;-) I was typing too fast.

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?

Yes

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

Because the way Paul seemed to be proposing it was exactly like HTML
with millions of presentational attributes.

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


Fine, and a better idea, but not what Paul was proposing. It still puts
CSS in CSS syntax, just stuffs it into an attribute. The parsing still
needs to be done. And that is what SVG does, and what Paul objected to.

So No, i don't think I misunderstood the proposal. I think you agreed
with me that Pauls proposal did not make sense, for lots of good reasons
that you listed in detail, and showed that a style attribute made more
sense at this point. I agreed.

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

yes

> As for disadvantages, these are:
> 
> - It requires moving the FO attributes into CSS, which is politically hard
> on the FO people.

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.

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

Well, you seemed to be using the CSS syntax in the proposed <css:style>
attribute.

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

No, because I was arguing against Pauls comment, not your response to my
response to Pauls comment ;-) Chronologically, that makes sense.

You modified all Pauls suggestions, so that my objections did not apply.
Thats fine; I agreed with your modifications.


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

No, of course not. But then, you and I have similar ideas whereas it
seems Paul wants to have 108 new attributes, if you look at his
examples.

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

Actually, your suggestion kept the CSS syntax but wrapped it up in an
attribute.

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

Well that would be a help. A necessary first step to let this work at
all.

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

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


--
Chris
> 
> Share & Enjoy,
> 
>     Oren Ben-Kiki
> 
>  XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


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