Re: [css3-gcpm] Multi-column floats overflowing the column

Also sprach Del Merritt:

 > Having not (recently) read the "separated[sic] CSS3 module [CSS3COL]", I 
 > don't see how widow and orphan lines in columns are handled; the worst 
 > case would be a single line in column 1 appearing on the next page, of 
 > course, but there are several ways for columns to not align well, 
 > particularly when the goal might be to present on US-Letter and A4, for 
 > example.  CSS3COL does say, "In all three cases, the UA determines the 
 > height of the columns based on the content which needs to be fitted. 
 > Content should be balanced between columns to minimize the column 
 > height, while honoring the 'widows' and 'orphans' properties.", but that 
 > doesn't seem to address how columnar data that crosses page boundaries 
 > should work.  Is that implicit in the other properties in @page?

I'm not sure I understand the question. 

BTW, You are referring to an old draft of the multi-col spec:

The newer draft doesn't say anything about 'widows' and 'orphans',
perhaps it should. The definition of the 'widows' and 'orhpans'
properties only refers to pages, not columns. It seems reasonable that
'widows' and 'orphans' also apply to columns so that one could write:

  div.section {
    columns: 2
    widows: 3;
    orphans: 3;

Does this make sense to you?

 > What of the language (whose name escapes me) that not only breaks words 
 > during hyphenation, but actually changes the words when they flow to a 
 > new line?

I know of some languages where the spelling changes slightly. For
example, in Norwegian, the word "trafikkonstabel" is made up of the
two words "trafikk" and "konstabel". The three k's are normally
collapsed into two, but reappear when the word is hyphenated:


Likewise the Swedish word "tuggummi" becomes "tugg-gummi".

This paper discusses some of the issues:

The GCPM draft neither prohibits nor enforces this level of

 > A colleague also commented, "In a past life I worked on 
 > newspaper systems.  Anyone who can use
 > 'hyphenation' and 'stable' in the same sentence is smoking something 
 > that I think I want none of."  To your credit, I don't see the word 
 > "stable" in [css3-gcpm], but this sought-after feature is of course a 
 > can wriggling with worms.

Yes, it's a complex problem that has no fixed solution. The GCPM
draft doesn't try to specify all detail of hyphenation, it merely
allows some of the most common levers in current hyphenation engines.

 > And this may be obvious, but what about the styling of the content in a 
 > [foot|end|named]note that is transported/flowed to some other place?  If 
 > the footnote is called for in a block that has been styled to be {color: 
 > red; font-style: italic;}, should the footnote content also be red and 
 > italic?  E.g.:
 >     <p style="color: red; font-style: italic;">Ernie and Bert made pasta
 >     <span class="footnote">And the chef says, "bork bork"</span> for
 >     dinner that night.</p>

Yes, the element (span, in this example) inherits from its place in
the structure. E.g., in section 6.1, the spec says

  Footnote elements are presented inside the footnote area, but they
  inherit through their normal place in the structure of the document.

Some of the other sections lack this text, I'll add it.

 > And what of the marker, say the superscript "1"?  Is its color to be 
 > red, or is its color to match the rest of the footnotes, assuming that, 
 > say, the CSS calls for something like "BODY {color: black;}"?

The marker is a pseudo-element on the footnote element.

  .footnote::footnote-marker {
    content: counter(footnote, super-decimal);

So, given your code:

  <p style="color: red; font-style: italic;">Ernie and Bert made pasta
  <span class="footnote">And the chef says, "bork bork"</span> for
  dinner that night.</p>

and this style sheet:

  .footnote { float: footnote }
  .footnote::footnote-marker {
    content: counter(footnote, super-decimal);

both the footnote text and the footnote marker will be red.

Thanks for your comments,

              Håkon Wium Lie                          CTO °þe®ª        

Received on Sunday, 6 May 2007 14:33:11 UTC