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

Brad Kemper wrote:

 > >  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)

Yes. 

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

Yes. 

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

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

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|

That'a what I'm trying to say. Do you agree that this is the desired
behavior? If so, could you suggest how to phrase it?

 > 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");

'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;
  }

 > Does this cause stacked M's, or does it cause text overflow? 

I don't know. What would be most useful? 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;
  }

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

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

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.

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

 > >> 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.
Perhaps we can just say:

  The appearance of leaders are affected by the same properties that apply to fixed strings. 

  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.

-h&kon
              Håkon Wium Lie                          CTO °þe®ª
howcome@opera.com                  http://people.opera.com/howcome

Received on Saturday, 26 October 2013 23:27:36 UTC