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

typo and another point...

> 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.

Typo, should be "why is there no".

Also why are technical terms not in italic, so I know when I am reading a
term which has a definition, e.g. column row height or column box.

Another reason I find CSS specs very hard to parse, because I can't
quickly see where are the defined terms.

I really hope you take that suggestion seriously. It costs me a lot of
time when I read these specs.

The perspective of someone who doesn't read these specs often for years is
going to be different than you own expert perspective.

>
> 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.
>
> below...
>
>> 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
> pagination.
>
> 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.
>
> [snip]
>
>> 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?
>
> [snip]
>

Received on Friday, 22 October 2010 13:02:01 UTC