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

Håkon Wium Lie wrote:
> 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. 
>   

If the block that is in column style does not specify its height in any 
way, then on paged media the actual height on a given page cannot be 
greater than the page box.  When the text, etc., that is in that block 
would not fit on a single page, I have missed how it would spill onto 
the next page(s), particularly the last page required.  If this was a 
2-column newsletter and there were 10 lines of text that spilled from 
Page 1 to Page 2, I think the preferred result would be for all 10 widow 
lines to be in column 1, leaving column 2 empty.  Another designer might 
think differently.

What I find missing in a paged-media spec are more examples of 
multi-page results.  "Page floats" sort of address this, but I don't 
think the relationship to columns is clear.  This is also why I wonder 
if there is an appropriate way for @page rules to regulate such styling.

> BTW, You are referring to an old draft of the multi-col spec:
>
>   http://www.w3.org/TR/2001/WD-css3-multicol-20010118/
>   

Ah.  I was referring to the version explicitly mentioned in the "Other 
References":

    [CSS3COL]
        Håkon Wium Lie. Multi-column layout in CSS. 18 January 2001. W3C
    Working Draft. (Work in progress.) URL:
    http://www.w3.org/TR/2001/WD-css3-multicol-20010118

Silly me...


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

Sure.  I had thought widows and orphans applied to all block-level 
elements, so this makes sense.

Thanks for the clarification on the rest of the issues.

-Del

>  > 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:
>
>    trafikk-
>    konstabel
>
> Likewise the Swedish word "tuggummi" becomes "tugg-gummi".
>
> This paper discusses some of the issues:
>
>  http://www.fi.muni.cz/usr/sojka/papers/tug95.pdf
>
> The GCPM draft neither prohibits nor enforces this level of
> sophistication.
>
>  > 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
>               Håkon Wium Lie                          CTO °þe®ª
> howcome@opera.com                  http://people.opera.com/howcome
>
>
>

Received on Monday, 7 May 2007 16:21:33 UTC