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

Shelby Moore wrote:

 > I found one typo...

First, thanks for you thorough reading and the time you have spent
writing up your comments. As you have seen, several of the changes
done in the last revision are due to the points you make -- even if I
don't always use your proposed wording.

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

Good catch. Fixed.

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

By setting 'column-span: all' on an element, there's a chance you move
the element outside the column box. If so, you don't really have room
to make the element span, and it should instead be displayed normally.

 > > 6) The break-* properties have been given their own h3 element.
 > 
 > Ditto this, where is logic?

This was just an editorial change to give the bread-* properties their
own headline in the spec so that they can more easily be found.

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

Overflow and pagination are related in this case. Also, it must be
possible to refer to a topic in a section even if it's not listed in
the heading. 

So, I don't think it necessary to include "pagination" in the heading,
but it doesn't hurt either. Thus, I have revised the heading in
section 8.2:

  http://dev.w3.org/csswg/css3-multicol/#pagination-and-overflow-outside-multicol

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

I disagree, it's natural to discuss how content is moved to the next
page in the same section as overflow.

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

Pagination. One mulitcol element can result in (say) three mulicol
boxes, one per page.

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

Technical terms are marked as <dfn> elements the first time used, and
explained. Thereafter, their use in the text should conform with the
definition but they are not called out. This is consistent with the
other CSS specs. 

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

Would you really want to see the definition of all terms always?
Here's a random sequence from CSS 2.1:

   All levels of CSS - level 1, level 2, and any future levels - use
   the same core syntax. This allows UAs to parse (though not
   completely understand) style sheets written in levels of CSS that
   did not exist at the time the UAs were created. Designers can use
   this feature to create style sheets that work with older user
   agents, while also exercising the possibilities of the latest
   levels of CSS.

About half the words in that text could point to some techincal
definition. I'm not sure the extra effort in writing the spec would be
worth it.

Cheers,

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

Received on Saturday, 23 October 2010 12:14:08 UTC