W3C home > Mailing lists > Public > www-style@w3.org > May 2003

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

From: Ian Hickson <ian@hixie.ch>
Date: Wed, 28 May 2003 09:13:03 -0700 (PDT)
To: Ernest Cline <ernestcline@mindspring.com>
Cc: "www-style@w3.org" <www-style@w3.org>
Message-ID: <Pine.LNX.4.50.0305280855290.7869-100000@dhalsim.dreamhost.com>

On Tue, 27 May 2003, Ernest Cline wrote:
>>
>> 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.

Proposal: Properties 'col-span' and 'row-span', that indicate how many
columns and rows the cell spans respectively.

Is that formal enough?


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

No, the difference is that table-inherit (as you proposed it, anyway)
takes place during the cascade, while col-span/row-span take place a lot
later, during the rendering stage. The problem of how to do the latter is
already solved in CSS2 (CSS2 copes with spanning, it just doesn't say how
to specify which cells span).


> 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

Well, Microsoft's expression() syntax works quite well, although it leaves
open the problem of what to do when the return value is not a valid value.
(It also isn't clear if the expression must be evaluated at parse time or
continuously, although the former is clearly more optimal, the latter is
necessary if you want to do layout-dependent calculations.)

There is also the problem of when to compute the values. For example, to
do calculations involving percentages, you need to delay the calculation
until after the cascade. But that leaves some problems, for example, what
happens if the result is outside the allowed range for the property.


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

This hard codes the widths, which I explicitly said should be avoided.

-- 
Ian Hickson                                      )\._.,--....,'``.    fL
"meow"                                          /,   _.. \   _\  ;`._ ,.
http://index.hixie.ch/                         `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 28 May 2003 12:20:48 GMT

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