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

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 defintion of text-overflow-min-width is not totally correct yet.
>> What's probably expected is to have either start/end truncation or middle
>> truncation, but not both at the same time.
>> I.e. what it should be able to handle is this:
>>
>> Whole text:
>> This is some truncated text.
>>
>> End truncation:
>> This is so…
>>
>> Start truncation:
>> …ated text.
>>
>>
>> When is this actually needed for text overflow? Can you provide for
>> samples, perhaps from in print or something, where the start of the text is
>> missing, in favor of the end showing?
>>
>
> 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.

 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.

 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. I
assume in such cases the author would want to additionally define a
min-width value for the container.

Sebastian

[1]
https://developer.mozilla.org/en-US/docs/Web/CSS/text-overflow?redirectlocale=en-US&redirectslug=CSS%2Ftext-overflow#Examples