RE: [docbook] Whatever happened too CSS+XML?

["Peter Ring" <PRI@magnus.dk>]

> > - mean clean lean XHTML that accurately represent
> (in whose opinion?)
> >   the rendering *intention* 
> of whom?

Well, TDG should be taken into account :). Take e.g. this description of <firstname>:

 "Processing expectations

  Formatted inline. In an Address, this element may 
  inherit the verbatim qualities of an address."


In XXE's interpretation of this pattern, the CSS looks like this:

  address {
      display: block;
      white-space: pre;
      margin: 1.33ex 0; 
  }
  
  honorific,
  firstname,
  surname,
  lineage,
  othername {
      display: inline;
  }

  honorific:after,
  firstname:after,
  surname:after,
  lineage:after,
  othername:after {
      content: " ";
  }

That is, a firstname element in the context of address will display inline (in a box set on the same line as the previous content) and verbatim (preserving whitespace). Furthermore, a " " (space) is appended. Most other properties are inherited from the parent element, all the way to the document root.

In many, if not most cases, the processing expectations for each single element is this straightforward and uncontroversial. What is controversial, however, is the how the processing expectations are interpreted as a pattern, i.e., which other elements each elements share properties with.

In this case, there is a common rule for the honorific, firstname, surname, lineage, and othername elements. If you change this rule, it will -- everything else beeing equal -- apply to all those elements.

If you want a special behaviour for firstname in an address context (but nowhere else), just add a more specific rule:

  address firstname {
    color: blue;
  }

But this special behaviour is not something that can be argued from TDG or from the schema. The grouping of honorific, firstname, surname, lineage, and othername, however, can be argued from TDG and from the content model:

person.ident.mix =
  honorific
  | firstname
  | surname
  | lineage
  | othername
  | affiliation
  | authorblurb
  | contrib
  | local.person.ident.mix

A CSS stylesheet for 'lean clean mean' XHTML wouldn't be much different. Some elements are inherently block, inline, list-item or whatever, and need not have the CSS display property set. Many different DocBook elements get transformed into a smaller number of XHTML elements; in most cases, the class attribute could be used as a form attribute to cary some 'semantic goodness'.

The XHTML output and the modular 'template CSS' stylesheet must be designed in concert. The success criteria are similar to those of modular DocBook itself: plan for growth, allow for easy maintenance and customization. 

It might be neccessary to use some extensions to or an alternative represenation of CSS in order to implement property groups and other features that cannot be modelled in CSS.

Kind regards
Peter Ring



> -----Original Message-----
> From: Dave Pawson [mailto:davep@dpawson.co.uk]
> Sent: 10. november 2005 18:07
> To: Peter Ring
> Cc: DocBook
> Subject: RE: [docbook] Whatever happened too CSS+XML?
> 
> 
> On Thu, 2005-11-10 at 11:56 +0100, Peter Ring wrote:
> 
> > If we have
> > 
> > - mean clean lean XHTML that accurately represent
> (in whose opinion?)
> >   the rendering *intention* 
> of whom?
> > without messing with
> >   the actual rendition
> > 
> > - a modular CSS that reflects the *types* of
> >   rendition intention, take advantage of the
> >   'Cascading' in CSS and some way to represent 
> >   property groups
> > 
> > it is piece of cake to change fonts, colors, margins, 
> > linking behaviour, etc. in a typographically consistent 
> > manner.
> 
> Too many assumptions there Peter?
> I agree with your starting point.
> Clean XHTML with CSS 'hooks'
> 
> > The main point of using CSS is actually that you can get rough 
> > and ready output for a website, while I re-purpose the same XHTML
> > for an e-book, and someone else syndicates the content into a 
> > glossy weblog.
> 
> Totally agree. CSS (for some browsers) is quite good.
> How it's used is another matter.
> I might call it taste?
> I like X
> you like Y
> 
> That's all I'm saying.
> 
> In that respect, yes we seem to agree.
>  Bit like saying that a particular codec
> is 'better' than another.
> Its all subjective.
> regards DaveP
> 
> 
> 
> 
> 
>