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

On May 4, 2006, at 3:38 PM, Brady Duga wrote:
> On May 4, 2007, at 12:07 PM, Håkon Wium Lie wrote:
>>> I would like to see some text explaining when (for
>>> paged media) it is allowed for floated content to flow into
>>> neighboring columns. Always? Only when using one of the new float
>>> values? Only when float-offset is specified?
>>     :
>
> ... However, trying to imagine how I will implement automatic column 
> balancing with decent line breaks and unpredictable line lengths makes 
> my head hurt. I'm not really sure how I would even go about dealing 
> with it. When I first read the Multi-column draft I was ecstatic when 
> I saw the bit about clipping, though I knew my users weren't going to 
> be terribly happy.
>
> I guess, the bottom line is, if I have to do it then let's just make 
> it consistent across specs and never require clipping. Otherwise, 
> let's always require it.

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?


>>
>> And, how to you like the rest of the GCPM draft?
>
> There is a lot of good stuff in there. I just had someone ask if we 
> could do something like continuation markers, so I am glad to see 
> them. I haven't read the whole thing yet (I just jumped to the column 
> support, which has some very nice controls in it). I am a little 
> confused by the column support being in this spec, though. Most other 
> things make sense (footnotes, headers/footers, etc), but I don't see 
> what about the column support is specific to paged media. Actually, 
> that's why I read that section first - to understand what it was doing 
> here :) For those of us who have been working in the paged media space 
> for years, it's very nice to see some significant work coming out of 
> the W3C on it.

Indeed, it's nice to see.  There remain questions.

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

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>

Or is it implicitly considered to be part of the @footnote's box(es)?  
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;}"?

Thanks,
-Del

Received on Friday, 4 May 2007 20:52:58 UTC