Re: Comments on css3-multicol

2009/10/16 Håkon Wium Lie <howcome@opera.com>

> Giovanni Campagna wrote:
>
>  > > http://www.w3.org/TR/2009/WD-css3-multicol-20090630/
>
>  > The following are comments to the yesterday (30/06) css3-multicol Last
> Call WD.
>
> Thanks for your extensive comments. Now that the last call period has
> ended, it's time to give you an answer. I agree with you on most
> points you raise, and I belive the CSS WG will confirm this. For now,
> the editor's draft has also been updated to reflect changes.
>

I know, I've been following you, the ed's drafts and the minutes., thanks
for the formal answer.


>   > 1) The title is still "CSS3 module: Multi-column layout"
>  >
>  > Hadn't the WG decided to adopt consistent naming and in particular to
>  > avoid saying CSS3?
>  >
>  > If yes, it should be called "CSS Multi-column Layout Module" or "CSS
>  > Multi-column Layout Module Level 3" (although I guess that Level 3 is
>  > only for features that did exist in level 2)
>
> The CSS WG agrees that the title should be changed. The two names you
> list are both good candidates. Personally, I would prefer the first as
> multi-column layout wasn't part of CSS2.
>

Good.


>   > 2) About column-rule-color:
>  > Why UAs are required only to support CSS2 colors?
>  > If the goal is to avoid the burden of hsl / rgba / SVG colors,
>  > shouldn't that be delegated to a reduced profile?
>
> This is a general problem for several CSS modules; should they refer
> to CSS 2.1 or emerging CSS3 modules? In this case, it seems best to
> refer to CSS 2.1 and the draft has been edited to reflect this.
>

Good.


>   > 3) About column breaks
>  >
>  >     3.a) At the beginning of section 5, replace desrciption with
> description
>
> Indeed, thanks.
>

  >     3.b) Is it possible to avoid a column break while still allow a page
> break?
>  > Is the intended effect like:
>  >
>  > ----------------------------------
>  > | a bcd efg hij |                |
>  > | lmn opq rst u |                |
>  >
>  > / page break, but content remains in the same column /
>  >
>  > | rst uvw xyz ab|                |
>  > | cde fgh ijk l |                |
>  > ----------------------------------
>
> A page break will always cause a column break; columns on different
> pages are considered to be different columns. This specification does
> not provide a way to ensure that all content is in the (say) left-most
> column.
>
>
Ok

 >     3.c) What about margin and collapsing of them?
>  > If you're delegating all (not just properties) to css3-page, you
>  > should say that explicitly.
>
> The last-call draft stated:
>
>  A multi-column element establishes a new block formatting context,
>  as per CSS 2.1 section 9.4.1.
>

Sorry, at the time I hadn't seen it. Comment withdrawn (but more text is
better than less).


> Which is correct, but somewhat cryptic. Therefore one example has been
> added to the editor's draft:
>
>  A top margin set on the first child element of a mulitcol element
>  will not collase with the margins of the multicol element.
>
> Further, in the description of the "break" properties, this text now
> occurs:
>
>  When a page or column break splits a box, the box's margins,
>  borders, and padding have no visual effect where the split occurs.
>  However, margins will be preserved after forced page/column break. A
>  forced page/colum break is a break that does not occur naturally.
>

Should you note "box-break"? There are UAs that may support css3-background
before css3-multicol.


>  > 4) About overflow inside and outside the multicolum element,
>  >
>  >     4.a) you should insert some examples of non-floated, overflowing,
>  > clipped element (maybe inlines with long words)
>
> Yes. Done in the editor's draft.
>

Good.


>   >     4.b) what happens if a non-floated element overflows vertically?
>  > Is it still clipped regardless of overflow? Can implementations put
>  > scrollbars, if overflow asks so?
>
> Yes, the spec states:
>
>  Content that extend outside column boxes at the edges of the
>  multi-column element is clipped according to the 'overflow'
>  property.
>

There's still one problem. Consider:

<div><img src="a"><img src="b"><img src="c"><img src="d"></div>

div {
column-count:3;
column-fill:balance;
height:300px;
}
img {
height:300px;
display:block;
}

Do I get 4 columns, one column longer than the other (overflowing), or two
columns with two images each, and the third empty?
Does it depend on overflow-x vs overflow-y on div? What if the images were
always higher than the div's content area?


>   >     4.c) what happens if Example XVIII has an element that floats on
>  > the rigth? Is the element clipped (showing only the right part), does
>  > the element intrude (ignoring the side of the float), does overflow
>  > apply?
>
> I believe there's consensus in the WG to remove intrusion before
> moving to CR. There have been no implementations of intrusion, and it has
> been removed from the editor's draft.
>

Good.


>   >     4.d) if there are more columns than available, are scrollbars
>  > rendered when overflow:auto / scroll?
>
> Yes, the spec states:
>
>  Content that extend outside column boxes at the edges of the
>  multi-column element is clipped according to the 'overflow'
>  property.
>

Ok.


>  > 5) Section conformance names a "column-grid-image", but no definition
>  > is provided in the document.
>
> I assume you refer to 'column-gap-image'. Indeed, this was a mistake
> and it has been removed.
>

Good.


> Let me know if you still think changes are necessary.
>
>
Here you are, for the sake of DoC


> Cheers,
>
> -h&kon
>              Håkon Wium Lie                          CTO °þe®ª
> howcome@opera.com                  http://people.opera.com/howcome
>

Giovanni