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

Re: Controling structure with CSS

From: Ian Hickson <ian@hixie.ch>
Date: Sat, 17 Apr 2004 21:31:35 +0000 (UTC)
To: Adam Kuehn <akuehn@nc.rr.com>
Cc: Tantek Çelik <tantek@cs.stanford.edu>, David Woolley <david@djwhome.demon.co.uk>, www-style@w3.org
Message-ID: <Pine.LNX.4.58.0404172116020.6258@dhalsim.dreamhost.com>

On Sat, 17 Apr 2004, Adam Kuehn wrote:
>
> Ian Hickson wrote:
>> The question of whether it makes sense to reorder the document on
>> output is an important one, but to me the answer is clearly "yes".
>
> Why?

Because it is presentational.


> Or more particularly, why in CSS and not in some other place more
> designed to manipulate structure?

Because this is not about manipulating structure. It's about manipulating
layout order.


> Exactly.  But it strikes me that going very far beyond this limited
> "reshuffling" of source order goes beyond mere presentation, and more
> importantly starts getting beyond the point of being relatively
> straightforward to use and understand.

It's pretty simple to me. If it mucks about with the DOM (XSLT, JS) then
it is a structural change. If it is a layer between the DOM and the
rendered pixels (CSS) then it is presentation.

What I want, as an author, is something which changes the presentation but
leaves the DOM (the semantics, if you like) well alone.


>> The 'flow-offset' idea, as proposed at the head of this thread, which
>> just moves the element up or down its siblings by a few, could work,
>> but then you lose a whole class of problems, e.g.:
>>
>>    <root>
>>     <foo/>
>>     <bar/>
>>     <container>
>>      <baz/>
>>      <quux/>
>>     </container>
>>    </root>
>>
>> ...where you want the rendering to be ordered foo, quux, bar, baz.
>
> But if that's the order you want rendered, why is there an
> intervening container?  Aren't you better served at that point by
> re-thinking the actual document structure?

What has the document structure got to do with it?


> At what point do we really cross the line into issues that CSS isn't
> *really* designed for?

We crossed that line years ago. This is about changing the CSS design so
it _is_ designed for this.


> The only way to make the language decently easy to use is to limit its
> scope, at least somewhat.  The entire generated and replaced content
> module is already exceedingly complex, and I think will likely be the
> source of considerable confusion

Yes, we're working (or more to the point, I will be working) on
simplifying parts of it.


> and most likely abuse, as well.

Yes. The more power you give, the more it is abused.


> but it seems to me the draft proposals are already at the point where
> they are unnecessarily complicated.  It would be desirable for
> non-programmers to be able to read and use this stuff.

I agree. Better proposals are very welcome.

-- 
Ian Hickson                                      )\._.,--....,'``.    fL
U+1047E                                         /,   _.. \   _\  ;`._ ,.
http://index.hixie.ch/                         `._.-(,_..'--(,_..'`-.;.'
Received on Saturday, 17 April 2004 17:31:38 GMT

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