Subject: Fw: CSS and XSL From: "Oren Ben-Kiki" <oren@xxxxxxxxxxxxx> Date: Sat, 20 Feb 1999 00:06:47 +0200 |
Chris Lilley <chris@xxxxxx> wrote: >Paul Prescod wrote: >> As Oren Ben-Kiki has pointed out you can maintain your current semantics >> for shorthand properties. > >I'm not sure he pointed that out; he wanted a single css attribute >containing the exact same syntax as the style attribute in SVG which was >the basis of your original objection. Hmm. It seems misunderstanding has gone both ways. Let me try to formalize what exactly I had in mind - would naming it XSS be acceptable, or is it already taken? CSS allows attaching style information to XML trees using the following: 1. A <style> tag whose contents is a stylesheet. This stylesheet isn't XML, but in CSS syntax. 2. A "style" attribute which may be attached to any element and which contains a complex CSS syntax set of attributes. 3. Some supporting attributes such as "class" which again might be attached to any XML tag. CSS is superior for dynamic applications since it allows (in theory) manipulating the style sheets themselves via the DOM. This allows making style changes to sets of elements scattered in the document in one simple operation, and can't be done using FOs. The down side is using CSS syntax in the style sheet and style attribute. My suggestion is providing an alternative syntax - "XSS" - for accessing the current CSS semantics: 1. Rename <style> to <css:sheet> and use XML syntax in it. For this to work, we need just one more tag, <css:rule>, which can appear only inside <css:sheet>. <css:rule> has a "match" attribute which accepts an XSL-like pattern - ideally it would use the XSL pattern language extended by CSS "pseudo classes" etc. 2. CSS attributes (font, color etc.) would become normal XML attributes of <css:rule>. Shorthand attributes ("border-style") would be supported just like today, although I'd suggest that attributes which take a tuple of values (such as "border") would not be supported. This would keep all attribute atomic. 3. Add a <css:style> _element_ which may appear directly under any element. This element would replace the "style" attribute. The same set of CSS attributes available in <css:rule> would also be available here. It would also be nice to move supporting attributes such as "class" to this tag. 4. Declare the current CSS syntax to be deprecated. It would still be supported by all browsers, but would not gain the benefits available to all-XML documents. Since conversion is trivial (a simple perl script could do the trick), we can expect that very soon support for the old syntax would be by conversion to the new one, anyway. The advantages are: - Using XML syntax for all of CSS. - Attributes are atomic, and by being contained inside just two tags effect on DTDs is limited. Validation of documents could follow the current model, instead of having to parse the inside of attribute values. Full validation would have to wait for DTD extensions/replacements. - Ease of implementation in current browsers. This is just an alternative input syntax, after all. - Preserving the DOM access patterns used today. Code would be indifferent to the CSS syntax used. This would break if the "class" attribute is moved to <css:style>, though. - Defining DOM access to CSS stylesheets. Today IE's "addRule" function is an ugly hack. using "document.stylesheet.mySheet.myRule.font = ..." is much better. - Ease of generating CSS from XSL. XSS would be XML, and CSS isn't. - Separating content from presentation taken one step further - separate content, from structure, from style. Transforming content to structure would be done by XTL; styling the result would be done by XSS. However, while being a minor technical change for CSS (just providing an alternative syntax), this poses a major problem for XSL (for the FO part of it). Assuming that the above proposal is accepted by the CSS group, then the XSL group could: - Bite the bullet and adopt XSS as the standard output for XSL. Build on the excellent work done on FOs - extend XSS to provide the same functionality. This is technically feasible, but such extensions would probably have to wait for the next version of XSS/CSS. - Ignore XSS and go on developing FOs separately. Given the advantages of CSS for dynamic applications, I find it hard to believe that FOs would ever be popular in browsers. They do have the advantage for printed documents - would this be enough to make FOs a viable technology? IMVHO, the worst combination would be "business as usual". As a dynamic application developer, I have to choose using CSS, which means giving up the benefits of XML for a significant portion of my documents. We'd end up losing the advantages of XML for significant portions of the documents. I suspect others like me would do the same - it is an easy choice to make in today's browser environment - so FOs would have a hard time in the market place, being limited to print applications. We'd end up losing all the nice features available in FOs because they simply won't be available on most platforms. In short, everyone would lose. Going the XSS way, everyone wins. Share & Enjoy, Oren Ben-Kiki XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
CSS and XSL, Oren Ben-Kiki | Thread | RE: CSS and XSL, Jelks Cabaniss |
Re: CSS and XSL, Chris Lilley | Date | RE: Passing counter value as macro , Grant Steinfeld |
Month |