Re: [CSS21] negative containing block width and percentages

On Mon, Mar 07, 2011 at 11:22:30AM -0800, fantasai wrote:
> On 11/03/2010 12:10 AM, Peter Moulder wrote:

> >Given these interesting existing results, I'd be somewhat inclined to
> >change things such that the containing block width can never be negative.
> 
> I personally think that makes the most sense, and I hope we define things
> that way in CSS3. For CSS2.1, we've resolved to make the containing block
> formed by a split inline undefined, so this case doesn't crop up.

I believe it can still crop up with bidi, i.e. if the position:relative
ancestor element generates what become multiple boxes due to splitting
for bidi, and if the 'direction' property doesn't match the topmost
bidi level in the ancestor.

Does it matter much to us how frequent such a case is?  In principle,
the fact that it's valid input is already senough grounds to consider
it an issue.  If frequency is important, then let's start from the
following example:

  <body style="direction:ltr">
  ...
  <p>And so we read that 
    <span style="position:relative; top:0.2em; left:0.2em; font-size:1.4em"
      >RTL TEXT</span>
  ...</p>

The plausibility of a position:relative ancestor in this example comes
from being used for emphasis, making the text stand out.

In order for the example to work, we need RTL TEXT to result in
multiple boxes, so that the box for the start of RTL TEXT (which I
assume to be the "first box"[*1]) is to the right of the box for the
end of RTL TEXT.

This can occur because "Inline boxes may also be split into several
boxes within the same line box due to bidirectional text processing."

Incidentally, the spec isn't clear here whether every change of
direction in the text can, or must, result in a new box.  (In
principle, it doesn't require separate boxes any more than a combining
enclosing mark or Indic split vowel sign requires separate boxes, so I
don't think any one answer necessarily follows from bidi layout
requirements.)  That looks like an issue in itself: it does look like
it affects this containing block calculation for example.

The example would still need to have a position:absolute descendant
to count.  I haven't looked at where position:absolute things tend to
be inserted, so I can't comment on how frequent that would occur.

Certainly I don't expect such cases to be common, but I think the above
at least makes it plausible that the case could occur in real-world
usage.

pjrm.


[*1]: If instead by chance "first box" could/should be interpreted as
 "leftmost" then of course we could use a direction:rtl example so that
 rule 4.1.2 applies.

Received on Tuesday, 8 March 2011 02:27:18 UTC