Fw: CSS and XSL

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