W3C home > Mailing lists > Public > www-style@w3.org > October 2010

Re: [css3-multicol] new editor's draft

From: Shelby Moore <shelby@coolpage.com>
Date: Fri, 22 Oct 2010 08:43:31 -0400
Message-ID: <616547504ad5c47c6d1bd032db3338ef.squirrel@sm.webmail.pair.com>
To: "Håkon Wium Lie" <howcome@opera.com>
Cc: www-style@w3.org
Thanks. You are a much better technical writer than me (maybe I am
exhausted too).

I found one typo...

> A new editor's draft is of css3-multicol is available:
>   http://dev.w3.org/csswg/css3-multicol/
> Here are the changes:
> 1) It has been clarified that all column heights in a row are the same
> height. This is clearly stated in section 2, but this text (in
> section 7) can be misleading and uses the wrong term ("lengths"):
>   Otherwise, columns are filled sequentially and will therefore end up
>   having different lengths.
> It has been changed to:
>   Otherwise, columns are filled sequentially and some columns may end
>   up partially filled, or with no content at all.

Glad you caught that. I didn't see it, but in general I found the
multi-col spec to be mind-twisting, and it might be partially because the
concepts were not consistent throughout. Looks like you are making
progress with it.

I also in general find the CSS specs to be very hard to understand
quickly, because there are no diagrams in the introductory sections, e.g.
Section 2.  The specs introductions contain many new technical terms which
I can't see in my head quickly.  I find words very difficult to parse. I
parse pictures much faster, and actually this is proven to be true for
most people.

Also, where is there no spacing between the paragraphs in section 2? Makes
it even more unpleasant to read.

I do not want to imply this too seriously, but do we purposely make specs
too dense, in order to sell our how-to books? I think not, I think we are
just too busy to make the specs beautiful? I think we sell more books if
we make the specs more interesting to read so people get inspired to read
more about them.


> 2) To clarify that constrained column heights result in extra column
> boxes in the inline direction even in paged media, section 8.2 now
> starts with:
>   Content that extend outside column boxes at the edges of the
>   multi-column element is clipped according to the 'overflow'
>   property. A multicol element can have more columns than it has room
>   for due to:
>    - a declaration that constrains the column height (e.g., using
>      'height' or 'max-height'). In this case, additional column boxes
>      are created in the inline direction
>    - the size of the page. In this case, additional column boxes are
>      moved to the next page(s).
>    - explicit column breaks. In this case, additional column boxes are
>      created in the inline direction for continous media, and
>      additional column boxes are moved to the next page(s) for paged
>      media.
> These lines have been removed:
>   In continuous media, columns that do not fit within the multicol
>   element are added in the inline direction.
>   In paged media, columns that do not fit within the page are moved to
>   the next page.

I like that you removed the conflation of overlow due to constrained
height and pagination, i.e. you removed "In paged media, the column height
is constrained by the size of the page.".

However, you still discuss pagination in the section, but the section is
still entitled "8.2. Overflow outside multicol elements".

Overflow has a specific meaning in CSS, we must not dilute and conflate
with pagination. Separation of concerns is a fundamental concept I think
we all strive for.

Thus I suggest you edit the section title to make it clear that the
section includes a discussion of pagination, e.g.

"8.2. Pagination or overflow outside multicol elements"

It is really important to not confuse people more, because CSS is already
way too confusing. The reader will be wondering what the heck does
pagination have to do with overflow.

I really think you would do best to instead make a section 8.3 for

Then you also need to retitle the overall section 8, change to:

8. Pagination, overflow and multicol elements

> 3) An implementor has pointed out that the current text may be
> interpreted as saying that all columns of a paginated element should
> have the same width. This is incorrect -- we must allow columns to
> adapt to the avilable width for each page, like we do for other content.
> This text in section 2:
>    All column boxes in a multi-column element have the same column
>    width, and all column boxes in a row have the same column height.
> has therefore been changed to:
>    All column boxes in a row have the same column width, and all
>    column boxes in a row have the same column height.

Good one.


> 5) As per Alex's proposal, this text has been added to the description
> of the 'column-span' element:
>    This property has no effect on elements that no not fit entirely

Typo "no not" should be "do not".

>    within the multicol element. Also, if a setting on this property pushes
> the
>    element outside a multicol element, this property will have no effect.

Where is the logic on this please?

I am thinking I don't agree, but I need to see his logic first.

> 6) The break-* properties have been given their own h3 element.

Ditto this, where is logic?

I do not like conflation of concerns which is what that seems to be, but
maybe I just don't understand well the issue.

> ---
> Some other notes, mostly to myself:
> ---
> I've been tempted to introduce the term "multicol box" to mean "the
> content box(es) of a multicol element". That would be slightly more
> accurate. However, I think the current text works.

What is the difference between the "content box(es)" and the "column
box(es)"? I can understand the multi-col element has its own content box
which contains column box(es), but how does a single mult-col element get
multiple content boxes?

Received on Friday, 22 October 2010 12:44:07 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:40 UTC