[CSS3-Values] Compound length values (was:Table cell inheritance)

Partial reply on one specific sub-topic follows:

Ian Hickson wrote:

> (Apologies for the large amounts of context quoting.)
> 
> On Mon, 26 May 2003, Ernest Cline wrote:

> > In any case, since things like column and row position and column and
> > row span are semantic and not presentational, specifying those should be
> > left to markup to do, not CSS in my opinion.
> 
> Take the following document fragment:
> 
>    <section>
>     <section>
>      <h> Foooooooooo </h>
>      <p class="date"> Monday </p>
>      <p> Content ontent ontent. </p>
>      <p class="attribution"> <cite> A. N. Other </cite> </p>
>     </section>
>     <section>
>      <h> Bar </h>
>      <p class="date"> Tuesday </p>
>      <p> Text ext ext. </p>
>      <p class="attribution"> <cite> Someone Else </cite> </p>
>     </section>
>    </section>
> 
> ...and lay it out like this:
> 
>    | Foooooooooo              |              |
>    | Monday  | Content ontent |              |
>    |         | ontent.        | A. N. Other  |
>    | Bar                      |              |
>    | Tuesday | Text ext ext.  | Someone Else |
> 
> Unless you hard-code the size of the columns, I don't think you can easily
> get that layout without using the col-span/row-span properties.
> 
> I don't think col-span and row-span are any more semantic than
> list-style-type. In fact I'd say there are many more totally unsemantic
> cases where they would be used. Indeed, most uses of colspan and rowspan
> attributes today aren't semantic, and if we want to move those layouts to
> CSS, we're going to need an alternative. Don't forget there's nothing
> wrong with table-based layout per se, it's only when said layout is
> achieved by butchering supposedly semantic markup that there is a problem.

First off, until I see a CSS proposal that would enable you to do what 
you suggest, I'd say that you are handwaving here. The problems 
involved in determining which rows, columns, and table a table-cell 
belongs that I see as the as root cause of your concerns of my table-
inherit proposal will apply just as much here.

Secondly, Most of the problems involved is using non table CSS could be 
solved if CSS had some mechanism to be able to combine length values 
via addition and subtraction, so far no-one has provided a satisfactory 
solution despite the fact that it has been seen as being advantageous 
since the ones proposed have had problems of ambiguity such as:
  margin: 10px+2em;
where it can't be told whether that is supposed to be one or two length 
values. Might I suggest as a solution the simple expedient of requiring 
parenthesis around any such calculation (or if that still presents 
parsing problems, altho I think it doesn't, using a length function for 
the same purpose.) That way,
  margin: 10px+2em; /* Two <length> values */
  padding: (10px+2em); /* One <length> value */
its clear how many values are intended.

Thus in your example above,
section {min-width:30em}
.date {width:8em}
.attribution {width:12em}
h {width:(100%-8em)}
p {width:{100%-20em}}
would handle getting the right widths, while being an adjustable 
design.

(There still would be some instances where table layout could handle it 
better (in terms of using no more space for the date and attribution 
columns than needed), but any such instance is going to require the use 
of the optional algrithm given in CSS2 17.5.2 for automatic table 
layout. which is hardly a speed demon.)

Received on Tuesday, 27 May 2003 15:09:45 UTC