Separation of content and presentation

Building single-source documents with XHTML+CSS is a lot easier than with
HTML4.  The level of separation between content and presentation in
XHTML+CSS means that in many cases choosing an alternate style is sufficient
for adapting the document to a new format or new medium.

However, there is a limitation in this approach (which also applies equally
to XSL-FO).  The limitation is that some media call into being distinctions
that do not exist naturally in the source.  For example, in a print medium
we may wish to copy a key phrase out of the text and insert it as a
stand-alone enlarged call out in the middle of a page.  

OK so we can do this with CSSn but it requires us to go back to the source
and introduce an element (distinction) into the source.  This new element
ONLY has meaning as it relates to a particular style and is effectively
there only as a target for the formatting CSS.  In addition this brings with
it a need for naming the new distinction (element).

This means that (in systems thinking terms) there is a positive feedback
loop between XHTML and CSS that muddies the waters.  XML (including XHTML)
content is not immune from the demands of presentation. 

I am curious.  Does anyone know of work on examining ways of further
separating content from presentation?  In particular managing
presentation-specific (and often one-off) distinctions that reflects the
demands of the medium and not intrinsic in the content?

All the best,

David




> -----Original Message-----
> From: www-style-request@w3.org 
> [mailto:www-style-request@w3.org] On Behalf Of Andrew Fedoniouk
> Sent: Friday, 7 October 2005 6:33 AM
> To: Jonathan Chetwynd
> Cc: www-style@w3.org
> Subject: Re: anchor as block level element
> 
> 
> 
> ----- Original Message -----
> From: "Jonathan Chetwynd" <j.chetwynd@btinternet.com>
> 
> 
> | "This is why anchors and hyperlinks are inline only - they attached
> | to words - the only known positioned entities."
> |
> | Andrew,
> |
> | What about images? or block level elements, which can't be contained
> | in inline elements?
> |
> 
> Again, we are speaking here about pure HTML. Imagine that 
> there no CSS at all in
> the Universe.
> 
> >From HTML point of view images are special type of 
> characters (or single
> character words) - they positioned inline as other text 
> (floating images is an 
> exception) .
> There are only two types of "blocks" from HTML point of view 
> - document itself
> and table cell.. All other tags (not elements, sic!) has no 
> visiual indication 
> that they are
> blocks (no borders/backgrounds) - thus some hypethetical 
> renderer can forget 
> about DIVs, BLOCKQUOTEs, etc immediately after parsing.
> 
> Parsing/layouting here is a simple incremental process - 
> build list of tagged
> (by hyperlinks) words and their postions by using markup 
> rules. To render just 
> walk through all of words and draw them at their positions. 
> Plain HTML renderer 
> is significantly simpler than HTML/CSS renderer - it does not 
> require DOM - just 
> list of words. Or it is "flat DOM" if you wish.
> 
> I guess that this simplicity was deliberate intention of HTML 
> inventors.
> 
> Andrew Fedoniouk.
> http://terrainformatica.com
> 
>

Received on Friday, 7 October 2005 07:20:33 UTC