WD-css3-multicol-19990623 comments

Multi-column layout in CSS <http://www.w3.org/TR/1999/W
D-css3-multicol-19990623>



This specification needs numbered sections with IDs.  
Property definitions should begin with "Name:" and the 
names should be in single quote marks.



The number and widths of columns

"'column-number'

Value: <integer> | auto | inherit
Initial: 1 [or 'auto'?]"

The initial value should be 'auto'.  This would allow setting just 
one property ('column-width') in order to achieve a 
width-dependent number of columns.

"'column-width'

Value: <length> | <percentage> | auto | inherit"

"  DIV.article { 
    column-number: 3; 
    column-width: 10em 25% auto; 
  }"

The Value production does not match the example.  Apparently 
the Value production should be as follows

Value: [ <length> | <percentage> | auto ]+ | inherit

What happens when content overflows a column, but not 
the column's parent box?  Does the parent's 'overflow' 
property dictate the behavior for the column?

What happens when more widths are specified than columns 
are specified?

What happens when "column-number: auto; column-width: auto"? 
 'Column-number' should then compute 1.

"The width can be specifies as"

Typography: change "specifies" to "specified".

"'column-gap'

Value: <length> | <percentage> | auto | normal | inherit
Initial: normal
Applies to: block-level elements
Inherited: no
Percentage values: relative to percentage values of other 
columns and gaps"

Should the value production be as follows (to allow varying gaps)?

Value: [ <length> | <percentage> | auto | normal ]+  | inherit

What does the confusing percentages explanation mean?



Column rules

"column-rule-width
Value: [ <length> | <percentage> | thin | medium | thick ]
Initial: medium
Applies to: block-level elements
Inherited: no
Percentage Values: refer to parent element's width"

Presumably, "parent element's width" is a misnomer for "width 
of containing block", which, in the case of a column, is the same 
as "width of the principal block box".  Even with the 
misnomer corrected, is this a good idea?  Should percentages 
refer instead to the width of the respective column gaps?  If so, 
and if column gaps may be of varying widths, a specified 
simple percentage value becomes a list of length values 
when computed.

What happens when a column rule overflows its gap?  Does the 
rule render behind the content?  Is the rule clipped?

The brackets around the value options are unnecessary.

"column-rule-style
Value: [none | dotted | dashed | solid | double | groove | ridge | 
inset | outset ]"

Should values include 'wavy', 'dot-dash', 'dot-dot-dash'?

The brackets around the value options are unnecessary.

"The above three (3) simple properties are combined into a 
complex property:
column-rule"

Everywhere else, this is called a shorthand property, not a 
"complex property".  Change this instance to match 
current terminology.



Spanning several columns

"'column-span'

Value: none | all | <integer> | inherit
Initial: none"

Eliminate the 'none' value and change the initial value to '1'.



Variation #1

"Instead of creating new naming schemes for gaps and 
rules between columns, new properties are created in the 
existing padding, border and margin families... 
This would change the syntax for these properties...
Instead of accepting up to four values each (top, right, bottom, 
left), they would accept five (top, right, bottom, left, top)."

There is no need to change the syntax of the shorthand 
properties; the new column box properties would then simply 
be untouchable by the shorthand and would need 
longhand specification.

If the working group insists on changing the shorthand syntaxes, 
at least correct the error of listing "top" instead of "inside" as 
the last value.

"The padding, border and margin areas are the same for all sides 
of all columns, except the left side of the leftmost column and 
the right side of the rightmost column."

What happens to the left side of the leftmost column and to the 
right side of the rightmost column?

The terms should be changed:
"left" becomes "start",
"leftmost" becomes "starting",
"right" becomes "end", and
"rightmost" becomes "ending".



Variation #2

"P:column { 
  column-number: 4; 
  width: 25%; 
  border: thick solid black; 
  padding: 0.3em; 
}"

Change pseudo-element to double-colon notation.

If the pseudo-element accepts an argument, no new properties 
are necessary:

P::column(4)

This seems to fit better with the rest of CSS, because true 
elements will not carry a useless 'column-number' property.

"other properties can also be used, e.g. the 'background' 
property would set the backgroun of the columns within an 
element, but not the background of the element itself."

This raises the question of where the columns fit into the z-ordering. 
 I propose that column boxes lie in the z-ordering between 
the principal block box and the child boxes.

Typography: change "backgroun" to "background".

"Unanswered questions
what properties would be allowed on the :column 
pseudo-elemet. For example, setting 'display' would not make 
much sense, and the font and text properties seems to have 
limited value."

Typography: change "pseudo-elemet" to "pseudo-element" with 
an "n".

For columns, any value of 'display' may be specified, but 
the computed value must always be 'column' (or whatever 
keyword is chosen).

Font and text properties must have no effect on the content, 
since the column pseudo-elements do not fit into the document tree. 
 The column is in this respect similar to the page.

"would inline elements in the columns inherit from the 
:column pseudo-element?"

No, no more than elements inherit from their page box.

"would vertical margins set on columns collapse with 
vertical margins of other block-level elements?"

The column's vertical margins should collapse with vertical 
margins set on blocks in that column.

Received on Monday, 3 December 2001 00:37:50 UTC