xml-dev - Re: Why I dislike CSS

["Simon St.Laurent" <simonstl@simonstl.com>]

Put up a heading like that one, and you'll get a quick response.  Once I
got beyond your first few paragraphs, it was clear that you have some
excellent points, but the initial presentation's downright infuriating.

At 02:28 PM 6/18/00 -0400, Amy Lewis wrote:
>Because it ain't XML.

So you don't like the syntax.  Okay, I've always found XSLT's XML-based
syntax to be verbose, counter-intuitive, and generally ugly.  XML syntax
doesn't magically improve everything.

>In a few responses in the FOs thread, it's been made clear that XSL FO
>is intended as a high-performance page description language; reading
>the list of working group members' affiliations makes it clear that
>this is where the expertise (and hence the focus) is going to be.  The
>suggested alternative for a simple presentation language has been CSS. 
>I don't like CSS.  I learned back-when, and still can't use it, because
>it isn't supported well.

I think that the XSL-FO crowd may have wowed you with their credentials and
the talk of their plans, but CSS is still a very lively and very smart
group of people.

XSL-FOs aren't especially well-supported either.

>I believe that CSS is a dead end.  That's fairly tendentious, I
>suppose, but I have some reason to say it.  It isn't an XML language,
>so it provides no leverage of existing familiarity with tag-oriented
>markup languages.

It's not intended to be a markup language, only to annotate markup
languages.  You can't implement CSS selectors as tag names, for instance -
you'd have to drop them into attributes.  That's a lot of what I hate about
XSLT.

>  Instead, it has the flavor of client-side scripting
>language.  Worse, from the point of view of implementation, developers
>can't leverage the XML and XSLT parsers that they may already have
>implemented; CSS requires an additional engine.

CSS parsers aren't especially difficult to build, and there has been
(grossly underdocumented) work on a simple API for CSS as well:
http://www.w3.org/Style/css/SAC/

>  My main reason for
>calling it a "dead end," though, is that because it isn't XML, it has
>to be "last in the chain".  Using stylesheets, it has its own selection
>language that has nothing to do with XPath, and is supposed to be
>delivered directly to the rendering engine.

There was a lot of talk that XSLT should use CSS selectors, but this didn't
seem to resonate with the DSSSL origins of the XSL community.  Personally,
I find XPath pretty clunky stuff for my style needs, though it's useful for
some fairly funky structure-based queries.

Also, I find CSS being 'last in the chain' makes it pretty much ideal for
describing final results without having to worry about them getting chewed
up in transformation processes.

>  If I combine XSLT and CSS,
>I end up with an XML document in which the styling is all encoded in
>the single attribute "style", and if I want to transform it any
>further, I have a significant parsing challenge.  I can't use my
>validating XML parser to verify the correctness of my stylesheet; I
>have to have something that understands CSS.

I can't use a validating XML parser to verify that my XSLT is correct,
except inasfar as it is well-formed, either.  XSLT's design bascially makes
such verification impossible

>I want a stylesheet language that lets me leverage my familiarity with
>XML syntax, and lets me reuse the tools that I already have for coping
>with tag-oriented, tree-oriented languages.  CSS isn't "part of the
>family."

CSS isn't 'part of the family' because it was around long before XSL, and
was basically ahead of the curve as far as convinving HTML developers that
separating style from content was a good idea.  I've always been deeply
disappointed that the XSL community came in and started over, barely
attempting to reconcile their work with a lot of good that had been done
before.

>I realize that the W3C continues to develop CSS, and that a part of the
>reason for the focus of the XSL WG is probably so that it doesn't
>conflict with that ongoing work.  I realize that, after W3C has spent
>*years* flogging this technology, it's likely to be embarrassed at the
>prospect of abandoning it.  But I *really* dislike being forced to use
>CSS, and only barely refrained from titling this "CSS considered
>harmful," which is probably just too over-the-top.

I really dislike being forced to use XSL, but figure that the perpetual
delays on XSL-FOs might spare me from having to use a grotesquely clunky
language to solve the kinds of simple work that CSS does very elegantly.

>So, XSLFO ... sheesh.  I agree with the need to be able to print
>high-quality output.  As a matter of fact, I think that the ability to
>print barely-acceptable output would be an enormous advance over the
>current situation.  However, in my last-but-one job, the testers had an
>irritating habit of applying the "mom and pop" test.  That is, they
>would ask "could a mom-and-pop shop (Ma and Pa Kettle's Online Special
>Recipe Depot) use this software".  XSL FO fails the test, in my
>opinion.  It's software that makes the user into Scarlett, always
>depending on the kindness of strangers (who will develop the
>interactive tools that will allow one to actually use the language,
>since it's so large and variegated--over fifty elements, over two
>hundred attributes that relate to those elements--that it isn't likely
>to be easily learned).
>
>I don't want to deprecate the work of the XSL FO committee.  I just
>don't see that it's going to meet my needs, judging both from the
>current draft and from the focus of the comments expressed here in the
>last week or two.

Well, you could always create a subset...

>That leaves me with basically nothing, if I want to go out and help
>Ma&Pa join the electronic revolution, using the vertical market schemas
>for communicating with vendors of mash, pipe, and glassware, and their
>own custom inventory/order language that's intended to interact with
>humans hitting their site.  There isn't anything that meets my needs,
>because CSS isn't XML, and XSLFO is neither finished nor suitably
>compact (I seriously doubt that there will be much stylesheet
>generation using XSLFO without the aid of a software tool; I happen to
>still like using text editors for generating this stuff).  My printed
>order forms don't *need* that level of control; my online presentation
>is completely overwhelmed by that level of complexity.  Perhaps the
>XSLFO folks could produce a "core" outline, or follow the lead of the
>schema folks and do a tutorial ... but it isn't the focus now, and
>given the need to not appear to be trying to undermine CSS, it probably
>won't be in the future.

So apart from the fact that CSS isn't XML, it seems to fit your needs.  Why
not do a simple bit of XML-izing?  It wouldn't be that hard to do, and I
think there are a lot of folks who'd be willing to help, provided you can
tone down the fire and brimstone.

>I don't mind undermining CSS, though.

Some of the rest of us might, though, and that's not going to help you get
to your dream of a simple XML-based stylesheet language.

>So, drawing on material from CSS & XSLFO, and from XLink, XSLT,
>XPointer, and XPath, I've put up a really quick pass at a layout
>vocabulary for XML, at
>http://www.mindspring.com/~alicorn/xslv.txt

It's a promising start, but you might find it easier to define a conversion
to and from XSL-FOs and CSS attributes rather than having to redefine all
of this from scratch...  That'd work fine, provided XSL-FOs and CSS stay
roughly in sync.

>It may be that, in my dislike for CSS and disappointment with XSLFO,
>I'm part of a vanishingly small minority, so that there's no point in
>doing this.  If so, I'll shut up after this.  If there's interest, drop
>me a line, and I can expand on the admittedly sketchy material that's
>currently there (if you can't get to the doc using the above URL, then
>try it - .txt + .html; that will mean I've revised it to pretty-print,
>and there's been some level of positive response).

There's definitely a point in doing this, but creating 'simple subsets'
often proves astoundingly difficult in the face of feature creep, community
support for existing institutions and specs, and the need to build software
supporting those specs.  Without a large community actually using the
stuff, XSLV will probably get crushed by a unique combination of CSS, XSLT,
and apathy.

But heck, I'd love to help, provided you change the subject line!

Simon St.Laurent
XML Elements of Style / XML: A Primer, 2nd Ed.
http://www.simonstl.com - XML essays and books

***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/
***************************************************************************