- From: Axel Dahmen <brille1@hotmail.com>
- Date: Wed, 11 Feb 2015 13:29:47 +0100
- To: www-style@w3.org
Absolutely agree.
For tabular or datasheet applications I see a strong demand for having
table-rows and table-columns draw borders and similar. One could highlight
total columns. And one could highlight the "current" row, eligible for
editing. Or even a number of rows in a cube.
And I see a high demand for having these properties apply to tables with
separated borders, particularly when you're styling tables by applying
border-radius to rows. The great part having table rows separated by margins
would be that their contents will align even then. So you could still
display tabular data while being able to style them according to your needs.
Hopefully others will see a need for these advantages, too. I don't suggest
to invent something new, but to apply existing definitions thoroughly.
> 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).
Absolutely my point of view. Instead of having invented that "hack", it
would have been better to just stick to the one basic box layout rule and
have everything apply to that rule in a consistent manner. For what it's
worth, table layout is merely more than displaying a number of stacked
inline-block elements, except for the additional rule of having table-cells
align vertically and horizontally.
The CSS Grid definition, however, is even more complicated for engines and
authors than tables would be. The Grid Layout definition tries to replace
tables by inventing questionable features (like "drawing order"), just for
the sake of having "something new" to work on. (This is but my personal
opinion.)
> 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.
Yes, this is correct. I wouldn't tend to believe this should be a problem.
If that would not the author's intention, he/she could easily apply a
background-color to table-cells. Or use table-row-groups to span a number or
rows (please refer to my image #4). I would suspect that an author who's
using rowspan/colspan elements will also apply appropriate styles.
Cheers,
Axel
--------------------------
"Morten Stenshorne" schrieb im Newsbeitrag
news:87a90kbsij.fsf@aeneas.oslo.osa...
"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 12:32:31 UTC