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

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.

 - Florian

Received on Wednesday, 3 December 2014 13:03:54 UTC