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

On Nov 12, 2013, at 3:04 PM, Håkon Wium Lie <howcome@opera.com> wrote:
> 
> 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("..........................")
> }

Yes, you are right. That's what I meant. I'm getting sloppy. 

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

Right. 

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

OK by me. 

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

That seems fine. 

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

It does. 

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

Agreed.

Received on Wednesday, 13 November 2013 00:59:23 UTC