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

Brad Kemper wrote:

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

Yes.

 > > 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("..........................")
 > }

Did you mean to replace the content of these element with a leader? Or did you mean something line::

.with-dotted-leader {
  width:99%;
}
.with-dotted-leader::after {
  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|

Yes, after the first step it would look like you have drawn. After the
second step it would be:

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


 > >  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?
 > 
 > Maybe just shortening the MLL by enough characters to make it fit. I don't have a strong opinion about this.

The simplest is probably to specify that behaviour is as if "M M M M M
M" was the content of the element.

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

I've changed it to:

  If there is empty space on the line, the leader is expanded by
  repeating it as many times as possible. The expansion of a leader
  from its minimum length never causes line breaks to change.

So, displaying the MLL may cause line breaking, but expanding it will
not. 

This should pretty much solve the matter. One more thing is needed: we
need to specify that line-breaking charaters inside the leader string
must be ignored. I've added this to the spec.

  http://books.spec.whatwg.org/#leaders

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

Yes. And, as per the suggestion above, the answer is that adding the
MLL may cause line breaks, but the expansion never will. Does this
make sense?
 
 > Maybe it shouldn't, except in the case where it would cause a table to overflow.
 >
 > >> 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'.

I don't think we need the text following "except" if we change the
spec, as per what I wrote above.

Cheers,

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

Received on Tuesday, 12 November 2013 23:04:56 UTC