Re: [css-ui] text-overflow in overflow:visible blocks

> On 03 Dec 2014, at 14:03, Florian Rivoal <florian@rivoal.net> wrote:
> 
> On 24 Nov 2014, at 10:19, Florian Rivoal <florian@rivoal.net> wrote:
>> 
>> 
>>> On 23 Nov 2014, at 00:49, Mats Palmgren <mats@mozilla.com> wrote:
>>> "This property specifies rendering when inline content overflows its
>>> line box edge in the inline progression direction of its block container
>>> element ("the block") that has overflow other than visible."
>>> http://dev.w3.org/csswg/css-ui/#text-overflow
>>> 
>>> I think we should take one step further and drop the "that has overflow
>>> other than visible" requirement.
>>> 
>>> That was part of Tantek's proposal under "In addition, ..." here:
>>> http://lists.w3.org/Archives/Public/www-style/2014Feb/0140.html
>>> 
>>> Was that part considered but rejected? (if so, why?) or is it simply
>>> an oversight when updating the spec?
>> 
>> I cannot speak for Tantek, but I would guess 2 reasons:
>> - browsers are fully interoperable in applying it only to overflow other than visible (checked latest firefox, chrome, safari, IE 10 and presto opera)
>> - having overflowing text overlap with neighbouring things is what normally happens everywhere when overflow is visible
>> 
>> Overlapping text is hardly ever a good thing, but I am not sure this case is one we should try to fix.
> 
> So we briefly spoke about this in the weekly telco, and the general feeling that the proposal made sense, but might have overlooked complications. In particular, it was raised that this could be problematic because the ellipsed content wouldn't be accessible by scrolling.
> 
> However, this concern applies not only to making text-overflow apply on visible overflow, but also to the change Tantek already made to make the ellipsis start at the edge of the line box. Unlike when the text overflows its block container element, when you ellipse text that spills over a float, you cannot reveal it by scrolling. Similarly, if overflow is visible, there will be no mechanism letting you scroll to reveal the content. 
> 
> I don't know if this is enough of a downside to reject the behavior. If you have a choice between non-revealable ellipsis and overlapping text, ellipsis might still be preferable.
> 
> On the other hand, we do have questions of web compat and interop to consider as well. 
> 
> However, given that we have complete interop on the only applying text-overflow when overflow is not visible, and that for many years, I am far from sure this is worth the web compat risk.
> 
> For the first part of the change, which Tantek already applied, we do have the ability to make the change given the lack of interop so far. However, I can't find the resolution that sanctions this change of behavior. There was a brief thread (the one you linked to) where Tab agreed, but I find no other discussion of this. If there was no discussion, I think we should have one, given that IE and FF (and Presto, should anyone care) behaved according to the spec before the change.


As currently specified, we are in a somewhat strange situation.

If a line is long enough to overflow a float, but not long enough to overflow its block container, setting 'overflow' to something else than visible does not affect it. However, if you wish to use text-overflow to get rid of overlapping text between the line and the float and get an ellipsis instead, you need to set 'overflow' to something else than visible.

Allowing text-overflow to apply even when overflow is visible would make this strange situation sane again (assuming we are ok with the ellipsed text not being accessible by scrolling), which would be ideal as far as I am concerned. Can we do this, or are we stuck due to web-compat problems?

If we can't, do we prefer to stay in the intermediary situation we're in now, or prefer to revert to the previously specced text, as currently implemented in all but webkit/blink browsers?

 - Florian

Received on Tuesday, 6 January 2015 15:51:42 UTC