RE: Parent pseudo-containers - a method for seperation of content from design

David,

I'm not commenting on your points below except to clarify what appears to be
a misconception on my post.

I was not talking about XSL at all.  When I said "changes to the underlying
XML/XHTML/HTML," I meant the author's manual changes to the underlying
source content, especially when the requirement for these changes is driven
by a purely rendering artifact.

I'm not talking about changes that can be automated batched by appropriate
XSL scripts.

I wasn't asking for any particular feature.  I was simply pointing out that
CSS in general (1, 2, 2.1, *and* 3) suffer from the problem that they don't
make a clear distinction between layout and stylization (IMHO).

This confusion is what I believe lies at the bottom of the inability to
resolve many of the issues that arise on this list regularly over the last
two years I've been a member (and I'm sure long before I came along as
well).



> -----Original Message-----
> From: www-style-request@w3.org [mailto:www-style-request@w3.org] On Behalf
> Of David Woolley
> Sent: Wednesday, April 06, 2005 11:14 PM
> To: www-style@w3.org
> Subject: Re: Parent pseudo-containers - a method for seperation of content
> from design
> 
> 
> > The clue for me is whenever it's necessary to change the underlying
> > XML/XHTML/HTML to yield the required rendering, and that change cannot
> be
> 
> Which is the domain of XSL.  CSS is intended to be a relatively simple
> styling language, and easy to learn, although is now suffering the bloat
> that is the fate of all computer standards (which start focussed then
> try to do everything).
> 
> The fact that XSL is not widely implemented indicates that browser
> marketing
> people don't consider there to be a real demand, although, to some extent,
> that is the result of an unsophisticated market that is failing to
> understand
> that different tools are appropriate for different jobs (e.g. I think that
> tagged PDF is the best compromise for pixel perfection with accessibility,
> but most authors try and achieve pixel perfection with HTML/CSS,
> forgetting
> the accessibility).
> 
> To take a point from another article, if you want a feature in CSS3 that
> is only going to be widely deployed in 5 to 10 years, an inability to
> support XSL in HTML should not be an issue, especially as XHTML 1.0
> provides
> a mechanism for writing, de facto, backward compatible XML.
> 
> > justified by the content alone.  This is just as bad a conceptual
> breakdown
> > as using tables for layout instead of tabular data, but is more
> difficult to
> > recognize.  And, so it's easy to overlook.

Received on Thursday, 7 April 2005 13:38:13 UTC