OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

docbook message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [docbook] Whatever happened too CSS+XML?

On Tuesday 08 November 2005 10:46 am, Paul Prescod 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
Create an XML: TOC http://www.docbook.org/tdg5/en/html/toc.html

>  * it lacks indexes

Create an XML index: http://www.docbook.org/tdg5/en/html/index.html

>  * certain elements need complicated prefixes and postfixes (including
> text, graphics, borders, table-like structures)

Most of that /can/ be done with CSS.  CSS and JavaScript can do even more.  
Basically all a web browser does with xhtml is apply a built in CSS style. 

html, address,
body, dd, div,
dl, dt, fieldset, form,
frame, frameset,
h1, h2, h3, h4,
h5, h6, noframes,
ol, p, ul, center,
dir, hr, menu, pre   { display: block }
li              { display: list-item }
head            { display: none }
table           { display: table }
tr              { display: table-row }
thead           { display: table-header-group }
tbody           { display: table-row-group }
tfoot           { display: table-footer-group }
col             { display: table-column }
colgroup        { display: table-column-group }
td, th          { display: table-cell }
caption         { display: table-caption }
th              { font-weight: bolder; text-align: center }
caption         { text-align: center }
body            { margin: 8px }
h1              { font-size: 2em; margin: .67em 0 }
h2              { font-size: 1.5em; margin: .75em 0 }
h3              { font-size: 1.17em; margin: .83em 0 }
h4, p,
blockquote, ul,
fieldset, form,
ol, dl, dir,
menu            { margin: 1.12em 0 }
h5              { font-size: .83em; margin: 1.5em 0 }
h6              { font-size: .75em; margin: 1.67em 0 }
h1, h2, h3, h4,
h5, h6, b,
strong          { font-weight: bolder }
blockquote      { margin-left: 40px; margin-right: 40px }
i, cite, em,
var, address    { font-style: italic }
pre, tt, code,
kbd, samp       { font-family: monospace }
pre             { white-space: pre }
button, textarea,
input, select   { display: inline-block }
big             { font-size: 1.17em }
small, sub, sup { font-size: .83em }
sub             { vertical-align: sub }
sup             { vertical-align: super }
table           { border-spacing: 2px; }
thead, tbody,
tfoot           { vertical-align: middle }
td, th          { vertical-align: inherit }
s, strike, del  { text-decoration: line-through }
hr              { border: 1px inset }
ol, ul, dir,
menu, dd        { margin-left: 40px }
ol              { list-style-type: decimal }
ol ul, ul ol,
ul ul, ol ol    { margin-top: 0; margin-bottom: 0 }
u, ins          { text-decoration: underline }
br:before       { content: "\A" }
:before, :after { white-space: pre-line }
center          { text-align: center }
:link, :visited { text-decoration: underline }
:focus          { outline: thin dotted invert }

/* Begin bidirectionality settings (do not change) */
BDO[DIR="ltr"]  { direction: ltr; unicode-bidi: bidi-override }
BDO[DIR="rtl"]  { direction: rtl; unicode-bidi: bidi-override }

*[DIR="ltr"]    { direction: ltr; unicode-bidi: embed }
*[DIR="rtl"]    { direction: rtl; unicode-bidi: embed }

@media print {
  h1            { page-break-before: always }
  h1, h2, h3,
  h4, h5, h6    { page-break-after: avoid }
  ul, ol, dl    { page-break-before: avoid }

That's the entire CSS for HTML4.1.

>  * chunks are not necessarily at the "right size" for reading and
> downloading

That can be addressed using XPath-related technologies.

>  * cross reference syntaxes may not adhere to Web standards (e.g. DITA)

So you apply some transforms to make the links into XLinks.

>  * IDs which are in the "same document" in XML may be in separate chunks
> on the Web -- these links need to be fixed up

There are different ways of accomplishing this.  One would be to use something 
along the lines of XIndice.

>  * it lacks breadcrumb navigation

If I understand what you are referring to, that could be implemented using XML 
at least as effectively as any HTML solution.  

>  * every HTML chunk needs a header and footer with next/prev/parent
> buttons

There's nothing preventing you from doing the same with XML.

>  * links may be injected from an external link base

Add it to the XML as it's served out.

> You don't need a transform step for what you're doing today. Great.
> Consider yourself lucky.

No.  I /do/ need a transform step for what I'm doing today because there is 
not enough CSS to support it.  That's the problem.  I have been doing other 
things for the past few years.  I just returned to this topic in the past 
week.  Unfortunately things are in too much flux for me to focus directly on 
the CSS issue.

> 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.

I don't believe you understand the point.  I can do the same things that are 
done with CSS using Java, C++, JavaScrip, Mathematica or some other language.

> 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. 

It demonstrates no such thing.

> 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.

DocBook XML is simpler, more maintainable and easier to read that the xhtml 
generated using XSLT.

> 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

I've never asserted that content can be served out using "just CSS".


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]