W3C home > Mailing lists > Public > www-style@w3.org > April 2005

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

From: Mark Moore <mark.moore@notlimited.com>
Date: Thu, 7 Apr 2005 06:32:29 -0700
To: <www-style@w3.org>
Cc: "'David Woolley'" <david@djwhome.demon.co.uk>
Message-ID: <E1DJXD3-0002Yj-FX@frink.w3.org>

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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:54:36 GMT