Re: [css3-ui] Support cropping in the middle of texts using 'text-overflow'

On Aug 13, 2013, at 3:57 PM, Sebastian Zartner <sebastianzartner@gmail.com> wrote:

> On 13 August 2013 02:33, Brad Kemper <brad.kemper@gmail.com> wrote:
>> On Aug 12, 2013, at 2:06 PM, Sebastian Zartner <sebastianzartner@gmail.com> wrote:
>>> 
>>> The use case I need that for are file names. In print doesn't have dynamic text cropping, so I'm not sure what you want here.
>> 
>> I just can't imagine that there is much need for truncating the start edge (ie left edge in Latin scripts), except when the element is too narrow to show even a single character on the left. When would you ever want "...ilename.pdf" instead of "filen...e.pdf" or "f...lename.pdf? Left-side truncation seems unnecessary to me, as I've never seen it anywhere, and never needed it (though it seems OK if a single character won't fit there).
>  
> Discussing whether left-side truncation is needed or not is not part of this thread.
> 
>>> Other use cases for text-overflow-min-width are samples of texts having some kind of [more] link at the end, which can be seen on many pages.
>>>>> Start and end truncation:
>>>>> …ome trunca…
>>>> 
>>>> That looks pretty odd to me, and not readable.
>>> 
>>> Well, truncating at both sides at the same time is not my invention.[1]
>> 
>> I never noticed that there, and don't think any UAs do that. It seems bizarre to me. I don't know what the use case is.
> 
> Firefox already implements this.[1] Though this thread is also not about discussing two-side truncation.

It is now, and is directly relevant to your proposal.

>>>>> Middle truncation:
>>>>> This …text.
>>>>> 
>>>>> For start/end truncation text-overflow-min-width would just need to hold one value, while for middle truncation you may want to define the min. width of the start and end part separately.
>>>> That seems like overkill, and would result in more cases where the text is unable to be truncated further. What then? Wouldn't it be better to keep truncating in the middle than to, what, overflow the box on the right
>>> 
>>> No. The purpose is to keep the text readable (or at least identifyable) as long as possible. If you think there's an easier way to define the minimal width of truncated text, I'd like to hear your idea.
>> 
>> I would define the min value for the end only. 
>> 
>> 1. The UA would insert keep the many characters on the right, insert ellipses to the left of those, and as many characters from the starting character on, as could fit, to the left of all that. 
>> 
>> 2. If it could fit less than one on the left, then include one and reduce the number of characters on the right. 
>> 
>> 3. If the width was small enough, it would eventually would just be the one starting character plus the ellipse. 
>> 
>> 4. If the ellipse also didn't my fit, then it would be treated the same as 'text-overflow: clip'.
>> 
>> Thus, text-overflow-min-width:0 would be the default starting value, which means the ellipsis would be at the end.
> 
> Sorry, I don't get these steps. Some examples (maybe with mockups) would help here.

<span>MMMMMMMMMMMMMMMM.MMM</span>

span {
font-family:monospace;
white-space:nowrap;
overflow:hidden;
text-overflow:ellipsis;
width:15em;
text-overflow-preserve-end:0; /* default value */
}

MMMMMMMMMMMMMM…

------------------


span {
font-family:monospace;
white-space:nowrap;
overflow:hidden;
text-overflow:ellipsis;
width:15em;
text-overflow-preserve-end:10em;
}

MMMM…MMMMMM.MMM

-------------------

span {
font-family:monospace;
white-space:nowrap;
overflow:hidden;
text-overflow:ellipsis;
width:11em;
text-overflow-preserve-end:10em;
}

M…MMMMM.MMM

-------------------

span {
font-family:monospace;
white-space:nowrap;
overflow:hidden;
text-overflow:ellipsis;
width:8em;
text-overflow-preserve-end:10em;
}

M…MM.MMM

-------------------

span {
font-family:monospace;
white-space:nowrap;
overflow:hidden;
text-overflow:ellipsis;
width:4em;
text-overflow-preserve-end:10em;
}

M…MM

-------------------

span {
font-family:monospace;
white-space:nowrap;
overflow:hidden;
text-overflow:ellipsis;
width:2em;
text-overflow-preserve-end:10em;
}

M…

-------------------

span {
font-family:monospace;
white-space:nowrap;
overflow:hidden;
text-overflow:ellipsis;
width:1em;
text-overflow-preserve-end:10em;
}

M




I suppose I am not totally against having a text-overflow-preserve-start value too (defaulting to 1em in my example above). Also, maybe ems, chs, and other lengths should not be the unit, but instead use a number to represent how many characters (or code points or graphemes clusters or whatever) get preserved, whether the letter is an i, l, M, W, or whatever.


>>>>> So it would hold two values. This differentiation is not written down in the wiki page yet.
>>>>> I'm open for ideas how to achieve the above.
>>>>> 
>>>>>> Also, I think text-overflow-min-width would need to be more of a suggestion than an absolute, as you would probably want to ensure at least one character at the start, in case the value was larger than the length of the line.
>>>>> I believe that should be up to the author. But of course a good default value like e.g. 1ch should be chosen.
>>>> 
>>>> If the author's intent is to have middle truncation, then I don't think min values should prevent the browser from doing that smartly once it reaches the extremes.
>>>  
>>> If the author doesn't care about how the truncation happens, it's ok to let the browser do that smartly. Though there are situations, in which you want to influence the truncation as I mentioned above, to which you already agreed before.
>> 
>> I'm talking about what to do when the mins don't all fit. You haven't said what you expect in that situation, as I have.
>  
> I'd either expect the text to overflow its container or to be clipped.

Pretty much the same thing, if you have overflow:hidden. Well, except that overflow:clip preserves padding, I think.

With my scheme, instead of getting clipped, an ellipsis is used, but with fewer letters preserved than what was specified. Thus, the author's intent of middle truncation is preserved, and the result is better than just clipping.

> I assume in such cases the author would want to additionally define a min-width value for the container.

Sure, sure, but that is just avoiding an issue that the spec would need to deal with anyway. Because not every author would specify a min-width in that situation.