W3C home > Mailing lists > Public > www-style@w3.org > August 2013

Re: [css3-multicol] Excessively wide column-gaps; § 4.3 border-style of column-rule

From: Gérard Talbot <www-style@gtalbot.org>
Date: Mon, 5 Aug 2013 18:59:13 -0400
Message-ID: <1bd9e7b7720180bcd012f15a95ff77d6.squirrel@ed-sh-cp3.entirelydigital.com>
To: "Håkon Wium Lie" <howcome@opera.com>
Cc: "www-style mailing list" <www-style@w3.org>

Le Lun 5 août 2013 17:14, Håkon Wium Lie a écrit :
> Gérard Talbot wrote:
>
>  > 1- What should happen when column-gaps are excessively wide?
>  >
>  > Let's say:
>  >
>  > div
>  > {
>  > column-count: 3;
>  > column-gap: 200px;
>  > width: 300px;
>  > }
>  >
>  > (11)  if (column-width = auto) and (column-count != auto) then
>  > (12)    N := column-count;
>  > (13)    W := max(0, (available-width - ((N - 1) * column-gap)) / N);
>
> In the current ED (which, I believe, reflects consensus) the relevant
> lines in the pseudo-algorithm are:
>
>   (03)  if column-width = auto then
>   (04)      N := column-count
>
> and
>
>   (11)  W := max(0, ((U + column-gap)/N - column-gap)
>
> which gives us:
>
>    N = 3
>    W = max (0, ((300px + 200px)/3 - 200px)) = 0
>
>  > So, used column-count should be 3 and used column-width should be 0
>  > according to the pseudo-algorithm.
>
> Yes.
>
>  > But I still can not figure out how the
>  > multi-column element will look like if "Column gaps take up space. That
>  > is, column gaps will push apart content in adjacent columns (within the
>  > same multicol element)."
>
> Hmm.
>
> The whole multicol element will be covered by column gaps, right? Then
> there will be three columns of zero width: one on the left, one in the
> middle, one on the right. However, content is clipped only "in the
> middle of the column gap", so some of the content in the first two
> columns will be visible.
>
> Or, one can argue that there's no point in splitting content into
> several columns when the columns have zero width. (This is what Presto
> and Prince seems to do)

In the spirit of accessibility-to-content, the content will overlap into
half of column-gap.
"
Content in the normal flow that extends into column gaps (e.g., long words
or images) is clipped in the middle of the column gap.
"
§ 8.1. Overflow inside multicol elements
http://www.w3.org/TR/css3-multicol/#overflow-inside-multicol-elements


> Or, one can say that the column-gap should be honored, even if it
> means that some of the content is pushed outside the multicol element
> (IE seems to do this.)

The column-gapS, when too wide, could be pushed outside the multicol
element or they could be clipped at both ends of available width of
multi-column element. This is the situation+question with the hypothetical
example I gave: when column-gapS > available-width, then how is this
rendered?


> What would authors like to see happen?


column-gapS should not be wider than available-width. Just my opinion. So, if

div
{
 column-count: 3;
 column-gap: 200px;
 width: 300px;
}

is declared, then the used column-gap would be 150px, used column-count
should be 3 and used column-width should be 0.


>  > 2-
>  > "
>  > The <border-style> values are defined in [CSS21] and the values are
>  > interpreted as in the the collapsing border model.
>  > "
>  > § 4.3. ‘column-rule-style’
>  > http://www.w3.org/TR/css3-multicol/#crs
>  > http://dev.w3.org/csswg/css-multicol/#crs
>  >
>  > "in the the collapsing"
>  > should be instead
>  > "in the collapsing"
>
> Thanks, fixed!

I think the link, the collapsing border model
(href="http://www.w3.org/TR/CSS2/tables.html#collapsing-borders") should
be instead
(href="http://www.w3.org/TR/CSS2/tables.html#table-border-styles")

Gérard
-- 
CSS 2.1 Test suite RC6, March 23rd 2011
http://test.csswg.org/suites/css2.1/20110323/html4/toc.html

Contributions to CSS 2.1 test suite
http://www.gtalbot.org/BrowserBugsSection/css21testsuite/

Web authors' contributions to CSS 2.1 test suite
http://www.gtalbot.org/BrowserBugsSection/css21testsuite/web-authors-contributions-css21-testsuite.html
Received on Monday, 5 August 2013 22:59:45 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:32 UTC