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

Sorry for the late reply:

On Oct 26, 2013, at 4:26 PM, Håkon Wium Lie wrote:

> Brad Kemper wrote:
> 
>>> 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? 
> 
> Yes. 
> 
>> 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 section is non-normative, so it's hard to use it as a reference.

Yes, that's what makes it hard to write a spec that describes what should happen in the underspec'ed table "standard".

> What the sentence (Starting with "For table cells..") tries to say is
> that the presence of a leader could possibly enlarge the cell (beyound
> its minimum length), whereas this would never be the case in, say,
> inline elements.
> 
>>> 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.
> 
> I think the minimal leader length (MLL) should be added before doing the first pass.  

OK, sure. 

> 
>> Then you do a second pass to add the leaders to add the minimal
>> leader length.
> 
> I assume you mean: 
> 
>  Then you do a second pass to add the leaders to the minimal leader
>  length.

Yes. 

> If so, yes. 
> 
>> 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.
> 
> The second step (adding leaders beyond the MLW) should never result in
> added overflow. In general, it shouldn't result in any changes to
> other elements. Except for tables, where I think it's ok to make other
> cells smaller. For example, considert this example:
> 
> <table style="width: 1000px">
> <tr><td class=with-dotted-leader>foo</td> <td class=without-any-leader>bar</td></tr>
> </table>
> 
> In UAs that don't do leaders, the two cells will have the same width
> and we will have this kind of rendered output:
> 
> |foo                             |bar                           |
> 
> For UAs that support leaders, I think the correct behavior is for the
> first cell to grow so that the rendered output is:

> |foo.........................................................bar|

you mean:

|foo.........................................................|bar|

> 
> That'a what I'm trying to say. Do you agree that this is the desired
> behavior?

Sort of. I think.

> If so, could you suggest how to phrase it?

How about "Abandon all hope, ye who enter here. This way lies dragons."?

Consider this:

.with-dotted-leader {
	width:99%;
	content:leader("..........................")
}
<div class=fixed-width>
<table style="width: 100%">
<tr><td class=with-dotted-leader>Some already long content in this cell</td> <td class=without-any-leader>Alakazam</td></tr>
</table>
</div>

So, without the leaders, the table might look like this, filling its container:

|Some already long content in this cell  |Alakazam|

But with the minimum leader, it would look like this:

|Some already long content in this cell..........................|Alakazam|

Thus, overflowing its container. But you'd probably actually want it to look like this at this step:

|Some already long content in this cell  |        |
|..........................              |Alakazam|

> 
>> 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;
>> }
> 
> I assume you meant to write:
> 
>   content: leader("M M M M M M");

Yes.

> 'width' doesn't apply to inline elements, though. So let's assume we have:
> 
>  span { 
>     display: inline-block;
>     content: leader("M M M M M M");
>     white-space: normal;
>     width: 1em;
>  }

Yes.

> 
>> Does this cause stacked M's, or does it cause text overflow? 
> 
> I don't know. What would be most useful?

Maybe just shortening the MLL by enough characters to make it fit. I don't have a strong opinion about this.

> This is not what leaders were
> desingned for, but it's a corner case that should be resolved. I can go
> either way. I'd guess that the simplest for UAs is to format it as if
> it was:
> 
>  span { 
>     display: inline-block;
>     content: "M M M M M M";
>     white-space: normal;
>     width: 1em;
>  }

So this means you would jettison the "never causes line breaks to change" sentence from the spec? Or just have it there for some things and not others?

>> 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. 
> 
> That's not quite true though; the presenece of a MLL may cause a line break to change. 

Well, that's what we're trying to decide, no? Maybe it shouldn't, except in the case where it would cause a table to overflow.

> 
>>>> 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?
> 
> A float with 'width: auto' is shrink-wrapped. So, if the float only
> has a leader as content, the leader would only have its MLL. The lines
> outside the float would not matter to the leader length.

O.K. The same is true if the leader is not floated (just inline) and its parent is floated with 'auto' width.

> If the float has a fixed width, there may be empty space on the line
> which can be filled with leader strings. But the lines outside the
> float would still not matter to the leader length.

Yes.

>>>> 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)? 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.
> 
> I didn't mean to say that the leader grows outside the edges of the
> float, nor that the leader expands the float (beyond its minimum
> length). I think we agree here.

Yes.

>>>> 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.
> 
> Yes.
> 
>>>> 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).
> 
> Yes.
> 
>> 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.
> 
> Yes. 
> 
> The leader itself cannot be abspos, but an abspos element can have only
> a leader as content. In this case, if the width is 'auto', the abspos
> would be shrinkwrapped to the MLL.
> 
>>>> 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'."?
> 
> The meaning is that the listed properties can change the appearance of
> the leader. For example, the font properties result in a chosen font
> from which the periods in a leader will be picked. The letter-spacing
> property describes how much extra space should be added between the
> dots in a leader etc. etc.
> 
>> 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?
> 
> That seems to be the case. I guess there may be easier ways to say so.
> And I wonder if some properties, like text-indent, should be excluded.

I think it may be problematic to exclude other property values based on the value of the 'content' property.

> Perhaps we can just say:
> 
>  The appearance of leaders are affected by the same properties that apply to fixed strings. 

Or "Note: The appearance of leaders are affected by the same properties that apply to any text string, except that the line-breaking restriction, as noted above, will override any line breaking allowances that result from properties such as 'white-space'. 


> Example:
> 
>     The same properties can affect the presentation of the fixed string and the leader.
> 
>     content: "...";
>     content: leader("...");
> 
> --
> 
> Again, great feedback -- thanks for going through all of this.

No problem.