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

On Tue, Jan 13, 2015 at 1:34 AM, Florian Rivoal <florian@rivoal.net> wrote:
>> On 12 Jan 2015, at 20:58, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>> On Tue, Jan 6, 2015 at 7:51 AM, Florian Rivoal <florian@rivoal.net> wrote:
>>> 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?
>>
>> I'm not sure I understand.  Looking at the current spec, and the
>> rendering in Chrome and Firefox, setting overflow:hidden on a float
>> does have an effect, and text-overflow depends on that.  I don't
>> understand how what you're saying in this email applies to either the
>> spec or current implementations.
>
> It's not about setting overflow on a float, but on an element that contains a float. Let me try again.
>
> CSS2.1 defines 'overflow' as "This property specifies whether content of a block container element is clipped when it overflows the element's box.[...]"
>
> To me, this means that the 'overflow' property was not meant to have an effect on the content of a block container element unless it is actually overflowing the content box.
>
> Here's a little demo:
>
> http://jsbin.com/puweda/1/edit?html,css,output
>
> You can see in the first <p> content that does not overflow its block container. 'overflow: hidden' therefore does nothing to it.
>
> In the second <p>, overflow is visible, so, by spec, text-overflow does nothing, even though the content collides with the float.
>
> In the third <p>, overflow is hidden.

Ah, gotcha, I was confused by your language usage.  You're referring
to overlap, not overflow.  All the actual overflow examples I could
construct worked as expected.  Your example of overlap makes it clear
what you're talking about.

> Firefox/IE/Presto behave according to the previous version of the spec and to what I believe is the original intent of 'overflow': since the content does not overflow its block container element, there is no special handling, even though it overlaps with the float.
>
> Chrome ellipses the content at the line box edge, which is in line with the newest version of css3-ui.
>
> From here, I have two points:
>
> 1) I don't like for 'overflow' to change the behaviour of an element which is not overflowing
>
> 2) Nonetheless, showing ellipsis when you're running over a float is nice
>
> Therefore, if we are not constrained by web compat, I agree with the suggestion from Mats Palmgren, and think we should apply overflow-text on line box edge (as Webkit & Blink do) rather than on the block's content edge, but do so regardless of the value of the 'overflow' property. This this comes from Mozilla, I suppose Mozilla is ok with it.
>
> If we can't do that due to web compat concerns, I am somewhat uncomfortable with the Webkit / Blink / current-spec behaviour, and would like to consider whether we should roll back to text-overflow triggering at the block's content edge.

I'm not sure.  At first glance, yeah, it seems silly that getting an
ellipsis from overlap requires non-visible 'overflow'.  But what
happens if the line both overlaps the float *and* overflows the
element?  If you have visible overflow, it needs to be shown
overflowing, right?  But then the overlap getting ellipsized is weird
and inconsistent.  So the current behavior (requiring non-visible
'overflow' for overlap-ellipsis to work) actually does make sense. ^_^

~TJ

Received on Tuesday, 13 January 2015 21:35:20 UTC