W3C home > Mailing lists > Public > www-style@w3.org > March 2012

Re: text-oveflow for _multiline_ texts

From: Samuel Santos <samaxes@gmail.com>
Date: Mon, 12 Mar 2012 16:44:59 +0000
Message-ID: <CAL3Vm+gKZHd4QTyXTKHxvaA=XcxgHn-AifMEP3uGYQLULUBcQw@mail.gmail.com>
To: Brad Kemper <brad.kemper@gmail.com>
Cc: "www-style@w3.org" <www-style@w3.org>
Hi Brad,

height: 3ln; may be useful for layouts with a flexible height, but is not
that useful for layouts using fixed heights on HTML elements.
For those elements, units like 'px' or 'em' or '%' should also be supported.

Cheers,

--
Samuel Santos
http://www.samaxes.com/


On Mon, Mar 12, 2012 at 4:02 PM, Brad Kemper <brad.kemper@gmail.com> wrote:

> I don't recall reading Tab's reply, but that isn't surprising, since it
> happened during the infamous January of a thousand e-mails.
>
> It looks like he and I agree that "A new unit based on the height of
> line-boxes is a separate issue" and that "Once you have a measurement
> like this, then text-overflow does not need it's own separate way of
> constraining its height.". I would also agree that a measurement based on
> lines or line-height could be useful. Then my example would be written like
> this:
>
>  DIV {
>    height: 3ln;
>
>    overflow: clip;
>    text-overflow: ellipsis multi;
>  }
>
> My main problem with this is that 'ln' looks too much like 'in',
> especially if you use an uppercase "i", as in 'In'.
>
> On Mar 12, 2012, at 7:45 AM, Samuel Santos <samaxes@gmail.com> wrote:
>
> Hi all,
>
> Is there any progress on this?
>
> I also agree with Brad, the height attribute is indeed useful.
> Lots of applications use fixed height values to arrange HTML elements on a
> page.
> For those elements you don't really care about the number of text lines
> that will fit in, you just want to ensure that the height of the element
> remains the same.
> I'm not sure about the usefulness of the line-height attribute though.
>
> Cheers,
>
> --
> Samuel Santos
> http://www.samaxes.com/
>
>
>  On Jan 15, 2012, at 2:06 PM, "Tab Atkins Jr." <jackalmage@gmail.com>
>> wrote:
>>
>> > On Sun, Jan 15, 2012 at 10:54 AM, Brad Kemper <brad.kemper@gmail.com>
>> wrote:
>> >> It seems odd to me to have the text clipping done by something other
>> than an edge of the content box. If you have a measure for number of lines
>> (3ln, above), then why not use that for box height (height: 3ln;)? Then you
>> could have something like 'text-overflow-lines: single | multi', and use it
>> in a shorthand that defaults to 'single'. A new unit based on the height of
>> line-boxes is not strictly necessary for this, and is really a separate
>> issue. Until then, this would suffice to accomplish your main goal, I think:
>> >>
>> >> DIV {
>> >>   line-height: 1.5em;
>> >>   height: 4.5em;
>> >>   overflow: clip;
>> >>   text-overflow: ellipsis multi;
>> >> }
>> >
>> > This isn't *quite* ideal, since a tall image or inline-block could
>> > make one of the lines taller than 1.5em, but this is probably a
>> > corner-case (and such outsized lines should be avoided in any case, as
>> > they're unattractive).
>>
>> I'm just saying its a separate problem. It could be useful to set a
>> vertical measure (height, min-height, max-height, for instance) to a number
>> of line-boxes tall, so that even if some of the line boxes were taller than
>> the line-height, it would still measure out to the right number of lines.
>> If it was more lines than what the actual contents created, then
>> 'line-height' would be used to determine what 1ln equaled. I believe the
>> request has come up before to have a measurement based on lines or
>> line-height, and this would also allow you to set border-width to that
>> measure (which would equal to line-height of itself). For replaced elements
>> such as images, 1ln could be equal to the height it would take to fit
>> exactly into the line box without increasing the line box height.
>>
>> Once you have a measurement like this, then text-overflow does not need
>> it's own separate way of constraining its height.
>>
>
>
Received on Monday, 12 March 2012 16:52:46 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 22 May 2012 03:48:51 GMT