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,
blockquote,
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".

Steven


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