W3C home > Mailing lists > Public > www-style@w3.org > April 2013

Re: [css-overflow][css-break] pathological fragment box generation

From: L. David Baron <dbaron@dbaron.org>
Date: Sat, 6 Apr 2013 12:36:15 -0400
To: Alan Stearns <stearns@adobe.com>
Cc: "www-style@w3.org" <www-style@w3.org>
Message-ID: <20130406163615.GA13557@crum.dbaron.org>
On Thursday 2013-04-04 20:59 -0700, Alan Stearns wrote:
> So the next step is to consider 0-height fragment boxes. Is there anything
> needed for that case if you are choosing to slice?

I'm inclined to think that css3-break should specify behavior such
that there is *never* a situation where the next fragment starts in
the same situation as the current fragment, even if the fragment is
zero height.

In other words, I would have a model where if the current position
is at the top of a page/column/fragment (nothing placed yet), then
something must be placed.

If the (innermost) thing being placed is a a line (or portion
thereof), a replaced block (or portion thereof), or margin, border,
or padding, then placing at least one of these would be required.
The height consumed for the blocks containing such object (whether
fixed or auto height) would be determined by the height of the thing
placed.

On the other hand, if the thing that is placed is a portion of a
fixed height that does not contain one of these things, such as the
space below the lines in a fixed-height block that is taller than
the space needed for its lines, then if that portion of height would
be 0 (from the fragment height), then the line-height is used
instead, and if that's 0 then the initial value of font-size is used
instead.  I think my proposal is that these would be fallbacks
rather than mimimums (that is, it would be possible to place less
than these amounts if there were something at a specified but
nonzero size).

-David

-- 
𝄞   L. David Baron                         http://dbaron.org/   𝄂
𝄢   Mozilla                           http://www.mozilla.org/   𝄂
Received on Saturday, 6 April 2013 20:52:26 UTC

This archive was generated by hypermail 2.3.1 : Saturday, 6 April 2013 20:52:26 UTC