CSS and XSL

["Oren Ben-Kiki" <oren@xxxxxxxxxxxxx>]

Jelks Cabaniss <jelks@xxxxxxxx> wrote:

I wrote:
>> CSS allows attaching style information to XML trees using the following:

Sorry, of course I meant HTML trees. Associating CSS to XML is, as you
pointed out, not quite defined at the moment.

>> 2. A "style" attribute which may be attached to any element and which
>> contains a complex CSS syntax set of attributes.
>
>I don't really know what you mean by a "complex CSS syntax set of
attributes".


Maybe the word "composite" would have been better. The point is that it
contains the values of more then one independent DOM attribute, requires
separate parsing, and so on - hence it is more "complex" then a simple
atomic attribute. No offence was meant wrt. the particular syntax CSS uses -
it isn't simpler of more complex then any of the competing ones.

>> 3. Some supporting attributes such as "class" which again might be
attached
>> to any XML tag.
>
>I also have seen no published W3C discussions on using CLASS and/or ID
>mechanisms a la HTML 4 in XML.  Presumably these things are being thrashed
out
>behind closed doors, but we mortals ain't privy to such highfalutin'
venues.


I assume the time to raise such issues is before they are formalized in a
different manner by some WG "behind closed doors. The people who discuss
these issues in the W3C WGs are aware of what is going on in this mailing
list - presumably, throwing the seeds of a good idea into this forum would,
now and then, bear fruit in some proposal half a year later on :-)

>(If any or all of these things -- embedded CSS in XML, inline CSS in XML,
and
>the use of CLASS and ID mechanisms for applying CSS styles to XML -- have
been
>publicly discussed, I would greatly appreciate a pointer to the URL/list
...)


So would I. In the mean while, they are discussed here and now :-)

>> The advantages are:
>>
>> - Using XML syntax for all of CSS.
>
>There goes the neighborhood.

>
>> - Ease of generating CSS from XSL. XSS would be XML, and CSS isn't.
>
>Thank goodness.

I assume I missed a smiley here. If  not, does it mean you think that XML is
bad in itself? I'm also not thrilled by the angle bracket soup, but I'd
rather have a less then perfect common syntax then a set of three competing
ones, each with its own particular flaws.

I'm an old fashioned UNIX hacker and fondly remember the days when I could
do complex operations by combining simple commands using ASCII text files
(or even better, pipes). I see in XML the potential for providing another
framework which would allow the same sort of modularity. If we keep styling
in a separate syntax, then operations manipulating style would be left out.
I think that would be unfortunate.

>> - 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.
>
>What does "transforming content to structure" mean?  Sounds like
ASCII-to-Markup


It means I can break my application into three parts. One part handles the
data model, regradless of any viewing issues. Another is concerned with
extracting the data to be viewed and reorganizing it to be comprehensible to
the user. A final part is concerned with the second-to-second dynamic
styling of the organized data - handling events, highlighting some data,
collapsing entries in trees, etc.

Using XSL as it is today, the last two phases are forced into one, which I
feel is a mistake. Using XML -> XSL -> CSS is better in this regard. As you
pointed out, XML+CSS isn't well defined at the moment, and like you I'm not
aware of anyone who is working on this particular approach. I tossed this
idea here as a "heretical view" of how XSL could/should be defined, instead
of the current FO approach.

Share & Enjoy,

    Oren Ben-Kiki


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