W3C home > Mailing lists > Public > www-style@w3.org > August 2013

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

From: Sebastian Zartner <sebastianzartner@gmail.com>
Date: Wed, 14 Aug 2013 00:57:10 +0200
Message-ID: <CAERejNb8ESKsXO+9=xr5SpLpv=3UhMzM_LQqW87W_AumA7hmrw@mail.gmail.com>
To: Brad Kemper <brad.kemper@gmail.com>
Cc: Kenneth Auchenberg <kenneth@auchenberg.dk>, www-style list <www-style@w3.org>, "tantek@cs.stanford.edu" <tantek@cs.stanford.edu>, "roc@ocallahan.org" <roc@ocallahan.org>
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.


Received on Tuesday, 13 August 2013 22:57:57 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:13 UTC