W3C home > Mailing lists > Public > www-style@w3.org > October 1999

Re: Feedback requested: Replaced elements that ex...

From: Ian Hickson <py8ieh@bath.ac.uk>
Date: Wed, 20 Oct 1999 19:54:55 +0100 (BST)
To: Web Master <thelawnet@yahoo.com>
cc: www-style <www-style@w3.org>
Message-ID: <Pine.GSO.4.04.9910201841070.5702-100000@mary.bath.ac.uk>
On Wed, 20 Oct 1999, Web Master wrote:

> [sniiiiip]
>
> 1. Modify overflow: visible in a column context.
> This is necessary, because at present overflow: visible (i.e. the
> default) would cause subsequent columns to be moved when a column
> cannot contain its image.

Incorrect. If an image overflows, it just overflows. Columns are not
resized. (What _will_ happen is that text in the next column will
overwrite the overflowing replaced element.)

The reason the later columns would not resize themselves is that we
are reusing the box model, and in the CSS block box model parents do
not resize horizontally to fit their children.


> With the modified box/psuedo-element model proposal, there is no way
> to do this.

Hmm, also incorrect. In a previous post I wrote:

A more flexible way of doing [the column-span thing] would be to add
an optional value on the 'position' property (say, 'wrap') which would
have the same effect on line boxes as the 'float' property does. Note
that this reuses existing concepts of the box model again. You could
then do something like this:

   div { display: 3 columns; position: relative; }
   h1 { position: wrap absolute; top: 0; left: 0; right: 0; 
     margin: auto; }

...which would have an effect equivalent to the current:

   div { columns: 3; }
   h1 { column-span: all; }

...but would be much more powerful. For example, it would allow
pictures to straddle the column gaps:

   div { display: 3 columns; } div:column { position: relative; }
   div img { position: wrap absolute; left: 50%; right: -50%; 
      margin: auto; }

This is not possible with the current draft AFAICT.

It would work by making the inline box model not place any line boxes
within the margin edge of a positioned element with 'wrap' set --
exactly like happens currently with floats.



> | A typical | Here is | And a | And a |
> | newspaper | another | third | fourth|
> | is in     | column  | column|       |
> | columns   |         |       |       |
> |           |         |       |       |
> |           |------------------ 
> |           | This image goes |
> |           | with the columns|
> |           |                 |
> |           |                 |
> ------------- -----------------

Easy:

   div { display: 4 columns; }
   div:column(1), div:column(2) { width: 30%; }
   div:column(3), div:column(4) { width: 20%; }
   div img { position: wrap absolute; left: 30%; right: 20%;
      margin: auto; }

Now make it straddle half of the last column, too:

   div img { right: 10%; }

That is, AFAICT, impossible to do using the current draft (or for that
matter, any of the dozens of properties you suggest).


> Clearly the advantages of retaining the block element are obviated
> by the special features of columns, which lend themselves to a
> special model, particularly to column-span.

Hmm, 'column-span' is the _only_ feature of the entire current draft
which is not directly supported using my original proposal based on
Variation #2. And that feature is supported in a *much* more powerful
way using the suggestion given above. (And note that the above
solution is not in any way restricted to being used only with columns,
unlike 'column-span'.)


> Thus in conclusion we need:
>  [snip huge list of new values, properties and pseudos]

...or we could use the proposal I suggested, based on the variation
mentioned at the bottom of the current draft [1], which only
introduces two new values (one on 'display' and one on 'position'),
one new pseudo-element, and reuses the entire box model with only a
few minor changes.

(I wonder which would have the shallowest learning curve for authors?)


> Further, there is a situation where the image or heading or whatever
> doesn't accompany any particular paragraph, but rather is wanted at
> the top or bottom, or middle of column N. If we use positioning, we
> can certainly position the element relative to the column block, but
> not relative to a particular column.

Ah, but you can if you use the :column pseudo element and 'position'
property to make one of the columns the containing block. For example:

   div { display: 4 columns; } div:column { position: relative; }
   div img { position: wrap absolute; left: 0; right: 0; width: 12em;
      bottom: 6em; top: 100%; height: 6em; margin: -6em auto -6em; }

This puts an image at the bottom of the column in which the <img>
finds itself, centred horizontally in that column. [2]


> PPPS. It is unlikely that you would want columns of different
> widths. BUT you can't do it with the column-* proposals, but you can
> with the pseudo-element proposal.

Actually, you can do it with the current draft. It is one of the few
things that the current draft _does_ already allow...


-- Footnotes --
[1] The reason I keep saying that this proposal is based on the
comment at the bottom of the draft is that I don't want to claim
credit for a suggestion that isn't really mine! :-)

[2] A minor detail with this particular example is that if the width
of a column becomes less that 12em, the images will spill into the
nearby columns (while remaining centred about the <img>'s column) but
because the left and right margins into the nearby columns will be
negative, the text will not wrap around the image in nearby columns.
It would not be compatible with the 'float' rules, but maybe with
positioned elements, line boxes should be excluded from the _border
box_ instead of the margin box. Or maybe they should be excluded from
the intersect of the border box _and_ the margin box.

-- 
Ian Hickson
"I take a Professor Bullett approach to my answers. There's a high
probability that they may be right."
  -- Dr Snow; Mechanics Lecturer at Bath University; 1999-03-04
Received on Wednesday, 20 October 1999 14:54:59 GMT

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