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 11:38:28 +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.0404171054180.15372@dhalsim.dreamhost.com>

On Fri, 16 Apr 2004, Adam Kuehn wrote:
> Well, yeah.  The original question was, "[W]ould it make sense to allow
> authors to rearrange the structure of a document wit[h] CSS?"  Maybe I'm
> just a literalist, but that sure looks like a yes/no question to me.
> You appeared to be arguing for "yes", so I asked you to clarify, as I
> found that surprising.

The original question, though, went on to indicate that what the author
actually meant wasn't what he asked. [1]

Specifically, the author asked whether the order in which the document
was _displayed_ could be changed.

Changing the structure of the document itself implies a change of
semantics, and, concretely in terms of W3C specs, a change in the DOM.

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". I mean, it's
already possible to a limited extent:



   foo { float: right; width: 50%; }
   bar { float: left; width; 50%; }

...for instance. Or similar effects with positioning.

Being able to do this with in-flow content without taking it out of flow
would, IMHO, be very useful. It will be possible to some extent with XBL,
but that is a rather heavy-weight solution, and doesn't really deal with
moving nodes from under different elements (as in the example below).

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.:


...where you want the rendering to be ordered foo, quux, bar, baz.

The 'flow-index' idea, similar to how XUL addresses this issue, suffers
from the same problem, and additionally requires more detailed knowledge
of the markup when writing the styles, which is not good.

All this will be possible to some extent with CSS3 Generated Content, but
that's a really awkward solution IMHO. It is, though, the only solution
that addresses how to move any node to any other place (although it always
has to be described in terms of moving nodes down the tree).

For example, the above could be done as (using the latest proposed names;
in the spec the property is move-to: and the functon is pending(), here I
use flow: and flow()):

   bar { flow: bar; }
   baz { flow: baz; }
   quux { flow: quux; }
   container { content: flow(quux) flow(bar) flow(baz); }

...or, if you just want to move bar and baz:

   bar, baz { flow: end; }
   root::after { content: flow(end); }

...which has the same effect in this particular case.

Unfortunately (the awkward bit) this breaks inheritance (the inheritance
has to be done in the original location, so things won't look like they
belong where they were moved to). And it can require an excessive number
of pseudo-elements.

For example, this is the mess you would need to wrap related <dt>s and
<dd>s into one box with a border using this:

   dt { content: none; }
   dt::after { content: contents; flow: terms; }
   dd { flow: definitions; }
   dd + dt, dl::after {
     display: block;
     content: flow(terms) flow(definitions);
     border: solid;

I wish there was a simpler way.

-- References --
[1] http://lists.w3.org/Archives/Public/www-style/2004Apr/0199.html

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

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:13 UTC