[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [docbook] Whatever happened too CSS+XML?
I think perhaps you are missing the point. I don't think anyone here is saying that CSS is the equivalent of XSLT, or in fact, anything similar. I think the major point is that if you want the semantic goodness of an advanced XML document type such as DocBook without any of the post processing goodness of XSLT - CSS is more than an adequate way of styling this information for the user. On 11/8/05, Paul Prescod <email@example.com> wrote: > > Why use (X)HTML at all? That's the whole point. Modern > > browsers can display XML fairly well without transforming the > > original document into some bizarre and unnatural form. > > XHTML and CSS aren't bizarre and unnatural to people _with a design > background_. XML and XSLT are. > > I work with XML auhors all day, every day, so I know that in the general > case the XML you author on your desktop is not exactly what you want to > publish to your website or to print: > > * it lacks a TOC > * it lacks indexes > * certain elements need complicated prefixes and postfixes (including > text, graphics, borders, table-like structures) > * chunks are not necessarily at the "right size" for reading and > downloading > * cross reference syntaxes may not adhere to Web standards (e.g. DITA) > * IDs which are in the "same document" in XML may be in separate chunks > on the Web -- these links need to be fixed up > * it lacks breadcrumb navigation > * every HTML chunk needs a header and footer with next/prev/parent > buttons > * links may be injected from an external link base > > You don't need a transform step for what you're doing today. Great. > Consider yourself lucky. Please don't consider yourself representative. > CSS would be much further ahead right now if its advocates would > acknowledge where it is strong, where it is weak and where it needs to > work together with transformation technologies. Instead, they continue > to treat XSLT and CSS as competitors which ensures that CSS is > guaranteed to lose. After all, XSLT programmers are free to mix CSS > properties into their XSLT and thereby demonstrate that XSLT is > functionally a superset of XML+CSS without XSLT. But CSS users look > silly when they discount the requirements that drive people to XSLT. > "Indexing? Why would you want to do that?" A better strategy is to admit > that those things that cannot be done in CSS are best done in XSLT but > those things that can be done in CSS should be, because it is simpler, > more maintainable and easier to read. > > In fact, it is because "Web people" tend not understand the mechanics of > large-document publishing on the Web that big documents are usually > delivered as PDF. Please take a look around this site and tell me how > you would accomplish it with "just CSS": > > http://www.docbook.org/tdg/simple/en/html/sdocbook.html > > Paul Prescod > > --------------------------------------------------------------------- > To unsubscribe, e-mail: firstname.lastname@example.org > For additional commands, e-mail: email@example.com > > -- "Creativity can be a social contribution, but only in so far as society is free to use the results." - R. Stallman