Re: [css3-ui][css4-ui] block-overflow property

"Tab Atkins Jr." <jackalmage@gmail.com> writes:

> A few years ago, we discussed a feature that would ellipsize content
> in the block direction a la text-overflow, but concluded that it was
> sufficiently different to warrant a separate property, and then never
> pursued it.  I'd like to revive that with a concrete proposal.
>
> There's a minor point of prior art in WebKit with the
> -webkit-line-clamp property (barely documented, but an example shows
> up in <http://dropshado.ws/post/1015351370/webkit-line-clamp>), which
> is somehow built on top of our old flexbox code.  It lets you specify
> a number of lines to display, either as an integer or a percentage of
> the total number of lines; the rest of the content is suppressed (and
> treated as overflowing, for the purpose of text-overflow).

One more minor point of prior art, then: Opera supports
text-overflow:-o-ellipsis-lastline.

http://dev.opera.com/static/dstorey/text/text-overflow.html

> Here's my proposal:
>
> block-overflow: clip | ellipsis | <string>
>
> "clip" is the current behavior, nothing special.
>
> "ellipsis" is the same as <string>, it just defaults to the ellipsis
> character or "...", so you don't have to actually type it.
>
> <string> triggers the special overflow behavior.  First, the string is
> laid out and has its height measured.  Then, all boxes and lineboxes
> are removed from the element that are at least that height from the
> bottom.  Then, a block box is inserted containing the <string> as
> content.

Basically, remove as many boxes (starting from the bottom) as necessary
to fit the <string> box (which should be placed right after the last box
that was kept)? And then some blahblah about corner-cases when no boxes
at all can fit, and what to do when there's not even enough space for
the <string> box?

Maybe something like that. Not sure what to do with floats and
absolutely positioned boxes, though. The current solutions (both the
Webkit one and the Opera one) don't have to worry about such
things. Then again, they don't allow for reliably specifying block and
inline overflow separately, if that's something that we need.

> There's more variety in styling block overflows than text overflows,
> so we should also provide a pseudo-element (::block-ellipsis ?) that
> represents the ellipsis, and can be styled as desired.  On the pseudo,
> "content:auto" resolves to "none" if block-overflow is "clip", to an
> ellipsis character if it's "ellipsis", and to the string if it's
> <string>.  You can style this arbitrarily (which is why you have to
> lay it out and measure it before you carve out space at the bottom of
> the element).  You can even do silly things like positioning it, but
> this won't affect the 'carve out space' behavior.

Maybe. And you could add something similar for text-overflow in the
inline direction too, of course (::inline-ellipsis ?). Hmm, or maybe
not. You could end up with multiple inline ellipsis pseudo elements per
block container then.

> I think the default stylesheet should probably apply "display: block;
> text-align: center;" to the pseudo.  We can let it inherit the rest of
> its properties from the element.

Adding pseudo selectors to the default stylesheet sounds a bit weird to
me. It's a bit like saying that CSS isn't good enough in its plain form,
isn't it? :)

-- 
---- Morten Stenshorne, developer, Opera Software ASA ----
---- Office: +47 23692400 ------ Mobile: +47 93440112 ----
------------------ http://www.opera.com/ -----------------

Received on Tuesday, 31 July 2012 07:50:21 UTC