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 |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Fw: Fw: CSS and XSL, Oren Ben-Kiki | Thread | Re: Fw: CSS and XSL, Chris Lilley |
RE: For Each in XSL, Shekhar Kshirsagar | Date | MSXML in jdk1.1.5, Nilofer Motiwala |
Month |