W3C home > Mailing lists > Public > www-style@w3.org > July 2000

Re: border-collapse conflicts and other topics

From: L. David Baron <dbaron@fas.harvard.edu>
Date: Mon, 17 Jul 2000 23:42:36 -0400 (EDT)
To: www-style@w3.org
Message-ID: <Pine.OSF.4.10.10007172319360.28195-100000@is03.fas.harvard.edu>

On Mon, 17 Jul 2000, fantasai wrote:

> Re: Hidden Borders

>   Seeing as the width of a border affects the width/height of the
>   cell (or the table), why are hidden borders treated as none (without
>   a width)? If I decided to put a border on :hover, the contents would
>   bounce around every time I moved the mouse, no?

I think what you want is 'border-color: transparent'.  One could say
that 'border-style: hidden' is slightly misnamed.

>   By the way, if a table row is over-constrained (all widths, paddings,
>   and borders are specified, including the table width), what gives?
>   There's no margin on the table cells.

The CSS2 spec doesn't specify.  It does have a recommended algorithm,
but it doesn't fully say how CSS properties map to that algorithm.

> Re: Slight Error?
> 
>   <BLOCKQUOTE cite=[CSS2:17.6.2]>
>   3.If none of the styles is 'hidden' and at least one of them is not
>     'none', then narrow borders are discarded in favor of wider ones.
>     If several have the same 'border-width' than styles are preferred
>     in this order: 'double', 'solid', 'dashed', 'dotted', 'ridge',
>     'outset', 'groove', and the lowest: 'inset'.
>   </BLOCKQUOTE>
> 
>   I would think that should read "If none of the styles are 'hidden'
>   and at least two of them are not 'none'".

Why?  It seems fine to me as is.  I think other border styles are meant
to override 'none'.

> Re: Border Conflict Resolution
> 
>   <BLOCKQUOTE cite=[CSS2:17.6.2]>
>   4.If border styles differ only in color, then a style set on a cell
>     wins over one on a row, which wins over a row group, column, column
>     group and, lastly, table.
>   </BLOCKQUOTE>
> 
>   What happens if the border styles are both set on individual cells?

This has been pointed out as an ambiguity/error in the spec at least
once before.  I suggested a solution for it in [1] (the second point
from the end).

> Re: Border-Spacing
> 
>   Is there any reason why 'border-spacing' cannot apply to row and
>   column type displays (restricted to the appropriate dimension)?
>   I think it would be useful to space column group divisions further
>   apart or things like that.

This is somewhat complicated by inheritance.  However, one could solve
it (for specification of border-spacing within groups) in the following
manner:

 * Make 'border-spacing' a shorthand property for 'border-spacing-x'
   and 'border-spacing-y'.

 * Allow 'border-spacing-x' to apply to 'table', 'inline-table',
   'table-row-group', 'table-header-group', and 'table-footer-group'
   elements.

 * Allow 'border-spacing-y' to apply to 'table', 'inline-table', and
   'table-column-group' elements.

 * Determine the horizontal space between two cells by the following
   rule:
    1.  If both cells are in the same table-(row|header|footer) group,
	    then use the 'border-spacing-x' value from that group.
    2.  Otherwise, use the value from the containing table.

 * Use an analogous rule for determining the vertical space.

If one wanted to allow specification for any row/column instead of just
within any group, I think it would also require:

 * inheritance to rows/columns in addition to that above

 * either:

   + determination that the value for a row/column applied on its
     bottom/right side (or some other choice)

   + rules similar to the collapsing margin rules to resolve conflicts

If one just wanted to apply margins (and collapse them in both
dimensions), it might be better to use a third border-model (perhaps
similar to the one proposed in early drafts of CSS2) rather than fit it
into the separated border model.  However, margins could simply be
collapsed with the above solution (by collapsing all relevant margins,
and the border spacing, according to the collapsing margin rules).
However, such solutions could be rather difficult to implement
(especially with incremental layout).

-David

[1] http://lists.w3.org/Archives/Public/www-style/1999Jul/0077.html

L. David Baron        <URL: http://www.people.fas.harvard.edu/~dbaron/ >
Rising Junior, Harvard                           Summer Intern, Netscape
dbaron@fas.harvard.edu                               dbaron@netscape.com
Received on Monday, 17 July 2000 23:42:40 GMT

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