W3C home > Mailing lists > Public > www-style@w3.org > July 2002

RE: CSS in XML format ?

From: Rowland Shaw <Rowland.Shaw@crystaldecisions.com>
Date: Thu, 11 Jul 2002 06:43:08 -0700
Message-ID: <963A03BCAFF059488BAFF33AE5C8709774BB61@IPSENT04>
To: "'Patrick Andries'" <pandries@iti.qc.ca>
Cc: www-style@w3.org

> > Not being sentient (just yet), I'm sure they don't actually care, but
> > their users will, as you're hopefully aware, string manipulation,
> > particularly with C style strings (and other kinds of byte streams, eg
> > stuff coming over a network) is hideously inefficient.
> Yes, yes. This is why XML and XHTML has been rejected by all B2B and B2C
> applications : those tags are just too long (<TABLE COLSPAN=" " where <T1
> C2=" could be sufficient).

I think you've misunderstood what I meant; If you have a string, how do you
append to it? First you need to count the length of the string, before you
can copy onto the end (etc). Verbosity is just a scaling factor. Having to
do a larger number of string operations decreases performance.

> > If it's useful in the general, then publish your DTD/Schema - at the
> > moment discussing an abstract idea that "could be useful" isn't going to
> > sell that idea to anyone.
> Yes, discussing ideas (always abstract as far as I know) is really a bad
> idea ;-)

Glad you agree ;)
Again, discussing the abstract can be dangerous, as it's harder to
understand what you're trying to achieve and your motives for it -- my first
reaction way back in the thread was "why author in XHTML? Why not start with
an intermediate and convert for all outputs?" You've since hinted at why
(I.e. You have a specific editor you'd like to support, and you have to
output to legacy systems)

> > Oh, for the record, I've written a simple CSS parser written in XSLT,
> > it's not generalised enough for general use (it only handles in-line
> > style, (to convert some extensions into something User agents know
> > and modification of it).
> Which only proves (with the fact that someone has developed SAC) that
> people want to convert CSS. Why should everyone redo this job (write his
> parser) when, if CSS could be expressed as XML, the parsing could be done
> with the same W3C standard used to interpret the accompanying XHTML ?

SAC is just a library (or API) as I understand it, so it's on a par with all
the XML parsers out there; so SAC is not an application purely for
generating XML, but instead a library for interpreting CSS -- which
undermines your argument; SAC being created for interpreting CSS, not for
porting it to XML.

By the way, is XSL-FO a close enough port of CSS to XMLisms for you?
Received on Thursday, 11 July 2002 09:43:41 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:02 UTC