Re: [css3-books] Re: [css3-gcpm] Leaders layout corner cases

> On Oct 26, 2013, at 7:46 AM, Håkon Wium Lie <howcome@opera.com> wrote:
> 
> Brad wrote:
> 
>> Maybe it is more obvious if you are dealing only
>> with inline elements (or inline pseudo-elements). But what if the
>> item that has the leader content is an inline block and/or if that
>> item is inside an inline block?  Do you do make the inline block as
>> big as you can (up to its width or max-width) to fill out the line
>> outside the inline block, or does the inline-block shrink to fit
>> the minimal leader length?
> 
> Good questions. I've added more text to -- hopefully -- answer your yestions. 
> 
>  Determine the empty space on the line. The empty space is the
>  difference between the width of the line box (as per CSS 2.1,
>  section 9.4.2) and the formatted content in the line box.

OK, so, assuming an inline-block with 'width:auto' and a single line box inside it: if I understand you correctly, it would do any shrink-to-fit first (to determine the inline-block width), and this would determine the line box width that you're looking at. This would mean there was no empty space at the end of the line, so it would get the minimum leader length.

> For table
>  cells in automatic table layout, the empty space is the difference
>  between the "minimum content width" and the "maximum content width"
>  (as per CSS 2.1 17.5.2.2).

I couldn't find where 17.5.2.2 describes "maximum content width". Do you mean maximum cell width? Even the description for minimum content width is so vague, with its liberal use of the word "may", that I don't really know what it is trying to say. Is it the width if you break after every word or element? This doesn't seem to help much with leader length calculation.

> The table cell description probably needs refinement as it would only
> work if there is one cell with leaders in a row. Hmm.

I'm not sure I understand. Like the inline-blocks, above, each cell would have its own line boxes, and you have to look at their lengths prior to inserting leader content. So each one gets the minimal leader width (if there is only one row and there is no specified cell width, otherwise, you might be able to add more), because you have already run the table algorithm on the auto-width table to determine the line length, and the line lengths are therefore based on the cell width before adding the leaders.

Then you do a second pass to add the leaders to add the minimal leader length. This then changes the width of the content, which can change the cell width, so all rows of the table are laid out again. But the cells can only get wider, not narrower, because of this in the spec:

     The expansion of a leader from its minimum length 
     never causes line breaks to change. 

So this then can result in the table overflowing its container.

By the way, WRT this sentence:

    White space in the leader string is collapsed according 
    to the values of white-space properties.

...because "never causes line breaks to change" seems to at least partially override the white-space property. Thus, consider this:

span { 
     leader("M M M M M M");
     white-space: normal;
     width: 1em;
}

Does this cause stacked M's, or does it cause text overflow? The latter, I assume, since the spec only mentions collapsing from the white space properties, not wrapping from the white space properties. On the other hand, the restriction on line breaking is only for "expansion of a leader from its minimum length", not on the minimum length itself. So, if you don't want a stack of M's in my example above, then the sentence should probably be changed to this:

     The leader never causes line breaks to change. 

>> What if the leader element/pseudo-element is floated? Or is wrapped
>> in something that is floated? What is 'the line' in that case
>> (there might be several lines outside the float with much smaller
>> line heights, for instance)?
> 
> I don't see that finding the line is problematic. The line is simply
> the line where the formatter puts the leader. If that sounds too
> simple, exchange the leader value with "foo" and see where "foo" ends
> up. That's the line of the leader. 

OK, so look at it this way, which is also informed by what you said about inline blocks:

Suppose I have a floated leader, which is therefore a block, and therefore has its own line-boxes inside. Does this not mean the lines outside the float no longer matter to leader length?

>> Does it grow in width to fill its
>> container if there is no other content?
> 
> Yes. That's empty space, for sure.

No, that space is in a different line box than those inside the float. So it would only grow enough to accommodate the minimum leader width.

>> Or if there is some sibling
>> text, is that text pushed to the right by the leader that is
>> filling the rest of the space?
> 
> Yes. In the writing direction. Here's my current description:
> 
>  The string inside the parenthesis is called the leader string. The
>  leader string must be shown in full at least once, thereby pushing
>  other content to the side (in the writing direction of the element
>  to which the leader is attached). The leader string establishes the
>  minimum length of the leader. If there is empty space on the line,
>  the leader is repeated as many times as possible. The expansion of a
>  leader from its minimum length never causes line breaks to change.
>  At the end of the leader, a partial leader string may be shown.
>  White space in the leader string is collapsed according to the
>  values of white-space properties.

Based on all this and your responses above, the float would only grow enough to accommodate the minimum leader width, and that is all it would push anything to writing direction. The space it is filling is based on the line box length, and that line box is inside a float.

>> What happens if the leader element/pseudo-element is absolutely
>> positioned? Or maybe it is not itself absolutely positioned, but
>> it's parent is, with an auto width? Is that width affected to grow
>> infinitely, or only enough to contain the minimal size leader?
> 
> These cases should be handled be the description above.

Hmm. I had to delve back into CSS 2.1 to think about it, but here is my understanding then: The width of a line box is determined by its containing block (and any shortening due to floats). But if an item is positioned, it becomes 'display:block' and width is determined by CSS2.1 10.3.7. Which means if the leader itself is abspos, it could have shrink-wrapped width, and in that case you would only add the minimal leader length.

>> The spec does say, "These properties influence the appearance of
>> leaders: all font properties, text properties, 'letter-spacing',
>> white-space properties, background properties, and 'color'." I
>> guess it means only those properties can change any initial values
>> at all, if the cascaded value of 'content' is a leader(). Is that
>> practically enforceable on something based on the content value
>> only? Suppose I have this:
>> 
>> div { content: leader(dotted); }
>> 
>> Does that negate the 'display' value for DIVs in the UA stylesheet
>> and make DIVs into inline elements? Sort of like the opposite
>> effect of how floating something makes it into block display?
> 
> No, the presence of a leader doesn't change any values on other
> properties. In your example, it would only mean that DIV is shown
> with one line of dots instead of its normal content. 

Then what is the meaning and point of "These properties influence the appearance of leaders: all font properties, text properties, 'letter-spacing', white-space properties, background properties, and 'color'."? Elements and ::before and ::after pseudo-elements are influenced by all properties. This sentence either changes something, or is meaningless as normative text. Is it just meant as a note to remind people that they have the power to style the content?

>> The spec also says, "the leader string is repeated as many times as
>> possible in the writing direction". What if the leader element is
>> between two words that each have opposite writing directions?
> 
> Good point. Changed to indicate that it's the writing direction of the
> leader we're talking about.

Great.

>> I think I can imagine what the answers to some of these questions
>> should be, and maybe some are answered somewhere else, but I think
>> the spec could be made more clear on such points.
> 
> Yes. Nice feedback. Let me know if you see further improvements.
> 
> -h&kon
>              Håkon Wium Lie                          CTO °þe®ª
> howcome@opera.com                  http://people.opera.com/howcome

Received on Saturday, 26 October 2013 18:30:21 UTC