Re: [css-tables] Missing definition of table row borders if border-collapse: separate?

"Axel Dahmen" <brille1@hotmail.com> writes:

>> There are some nice layouts here, but I don't think that anybody wants
>> to make such drastic changes to the table layout model.
>
> Sure. I'm but proposing a suggestion here and would want to leave the
> evaluation of benefit/importance to others who are more eligible than
> I am.
>
>
>
>>Looks like you're imagining a hybrid between collapsed and separate
> borders.
>
> Yes, you are absolutely right. That was my mistake when trying to
> bring down my first thoughts. Of course, a property like
> "table-cell-priority" is nonsense here. The same would be achievable
> easily with simple CSS. The most important part of my suggestion
> instead is that if table-row, table-row-group, table-header-group,
> table-column and table-column-group would be accepting the standard
> box model. border-spacing, however, would become obsolete.

I suppose we can say that the reason for table-row, table-column & co
being weird and not being standard box model boxes, is that rows and
columns always overlap each other, and are considered to be merely
structural placeholders to establish a grid to put cells on. But then
you have the fact that they do accept borders in the collapsed borders
model, so that's not even entirely true (although it's always the
(relatively standard-box-model-friendly) table cell that needs to
resolve the borders around it, whether they be specified on the cell,
row, column, or the table itself; which means that the rows, columns &
co are still pretty much invisible, and don't REALLY get the borders
even if they get specified there).

Being structural grid-defining boxes, one could say that it would be a
bit weird to allow borders on those box types. And, by not allowing
border, one doesn't need both padding and margins. But allowing margins
could maybe make a lot of sense, no matter how you look at it. We could
do margin collapsing both vertically and horizontally. :) And deprecate
border-spacing.

When CSS was born to replace presentational attributes in HTML, for
tables, that meant that a TABLE's cellspacing got turned into
border-spacing on the table, while a TABLE's cellpadding just had to be
specified on each cell individually. One might wonder why it wasn't
decided that cellspacing could just be specified as margins on cells
(and maybe also rows, cells, columns & co), instead of inventing a new
property (except that it would obviously complicate the engines to do
so, and that's bad if nobody saw any use case for it).

> Please refer to my following new mock images for references on the
> issues you mentioned in the following:
> http://imgur.com/a/4sA51
>
>
>
>> Borders all normally take up space (unless you're collapsing
>> them) and affect layout, so I'd think that if you have col, tr {
>> border:2px solid; } and td { border:3px solid; }, a cell would be
>> surrounded by its own borders, and then, on the outside, the border of
>> the row and column? Which of them (rows / columns) should come first,
>> BTW, and what if they have different style or color? That could
>> potentially look hideous, on a general basis.
>
> You're absolutely right. But with simple CSS this can be caught. See
> image #2 for reference.
>
> Or if the programmer intentionally wants to see these borders - he/she
> simply can. See image #1 for reference.
>
>
>> How should the following be rendered?
>> <table>
>>     <col style="border:3px solid blue;">
>>     <tr style="border:3px solid pink;">
>>         <td>x</td>
>>     </tr>
>> </table>
>> Column borders on the outside, row borders on the inside? Or the other
>> way around? Or column borders on the outside on the left and right
>> sides, and row borders on the outside at the top and bottom?
>
> I would want to leave the decision of what's outer or inner to
> others. However, my personal preference (reflected in my images) is
> the following:
>
> table
>  \- table-column-group
>    \- table-column
>      \- table-row-group
>        \- table-row
>          \- table-cell

This matches background layering in CSS 2.1 17.5.1 for tables, so I too
think that would be the natural choice.

> Padding, borders and margin would only affect the corresponding sides
> of elements they touch. (I've been trying to be as precise as possible
> in images #3 and #4 to, e.g., reflect the influence on table-column
> elements only to the left/right side of affected child elements.)
>
> For reference, see images #3 and #4 in the album.
>
>
>> Together with border-spacing, you'll end up with a constantly
>> over-constrained situation here. That could of course be fixed by
>> introducing an 'auto' value for border-spacing, and require that it
>> always be 'auto' if the author wants borders, padding and margins.
>
> That's why border-spacing should become obsoleted. table-cell margins
> would perfectly do.

Indeed. But, as I wrote further up, even just allowing margins on table
cells would complicate the engine. So we need some strong use cases
here.

Have you looked at the CSS grid module, BTW? I don't know that spec much
at all, but it seems to be what the cool kids are supposed to use these
days, instead of old clunky tables. :)

>> Also - what about rowspan > 1?
>
> Good question! My consideration is that table-columns and table-rows
> are not concerned with rowspan/colspan. So they should just ignore
> these. See image #4 for reference.

OK. You might end up seeing a row's border that goes straight through
the middle of a rowspanned cell, unless you give the cell a background
to paint on top of said border, though.

-- 
---- Morten Stenshorne, developer, Opera Software ASA ----
------------------ http://www.opera.com/ -----------------

Received on Wednesday, 11 February 2015 11:25:14 UTC