Re: [CSS3-UI] text-overflow change: single value must only apply to end line edge

On Thu, Sep 29, 2011 at 05:52, Alan Gresley <> wrote:
> On 29/09/2011 6:54 PM, Tantek Çelik wrote:
>> Through experience with both existing site use of text-overflow, and
>> testing existing implementations[1], it's become clear that
>> text-overflow with a single value must only apply to the end line
>> edge, rather than to both left and right line edges.
>> In particular, there are numerous sites that apparently depend on
>> start edge ellipsing NOT occurring when there is a single value (e.g.
>> cases where a negative text-indent is combined with left padding, thus
>> causing overflow of the text, but not any rendering clipping).
>> In addition, existing implementations (IE, Opera, Safari) consistently
>> apply a singular text-overflow value to only the right edge for LTR
>> text, and in most of those (IE, Safari) to only the left edge for RTL
>> text.
> I would say this is far worst than you recognize

Assuming you meant "worse".

> (with regards to overflow,
> WebKit and Gecko are more in agreement). BTW, LTR and RTL is 'inline base
> direction' and is not exclusive to text. It encompasses 'inline base
> direction' and has a direct relationship with 'block flow direction' (was
> 'block progression'). Please see the introduction of the writing-mode WD [2]
> for more details.

Based on the input of one of the editors of that draft (fantasai), the
CSS3-UI definition of text-overflow uses the phrase "inline
progression direction".

If you want to suggest a different term, I suggest you take it up with
the writing-mode WD editors.

Feel free to also suggest other prose corrections or improvements in
the definition of text-overflow in CSS3-UI.

>> Thus I've made the respective change in the CSS3-UI text-overflow section:
>> from: a single value applying to both left and right edges
>> to: a single value applying only to the end line edge.
>> Thanks,
>> Tantek
>> [1]
> Looking at the comments in that bug thread (epically by Boris [3]) and with
> my own experimentation with ellipses, bidi, overflow (both direction and
> block progression, the former is text overflow), I would say that it is not
> an issue with ellipses but more an issue with overflow of any nature. To fix
> ellipses handling on a broken overflow behavior will just cause more compat
> issues in the future.

Please state the specific compat issues you see occurring due to the
specific changes made above.

> Please view this test case.

Reviewed and thank you. I've collected this for future work when we're
specifying overflow-x and overflow-y.

> For the above test case, with the earlier examples, there seems to be either
> WebKit/Gecko behavior or Opera/IE behavior. With the later examples, Opera
> seems to have WebKit/Gecko behavior leaving IE alone with it's behavior.

The behavior of the test cases in that file are far from clear as to
what should/may happen. I'll have to take some time analyzing it to
figure it out when I get to specifying overflow-x and overflow-y.

> May I suggest that all CSS modules, implementations and the CSS WG start to
> work towards a CSS3-overflow module instead of a collection of notes [4] for
> planning, so overflow can be defined in one module (not defined in a myriad
> of ways in many modules) so we can work towards interoperability between all
> UAs.

Feel free to add to that collection of notes in any way that you see
improving them in the direction of a CSS3-overflow module.

> Please see more in a future list message  ...

It may take me a while to setup a tachyon detector. ;)

> regarding a new property that I
> like to propose which is 'overflow-direction'. This is needed if UIs
> consider showing bidirectionally of script or dual writing-modes (horizontal
> and vertical) in a sensible way.

Please add your 'overflow-direction' proposal directly to the wiki
page instead, and send a URL to it instead:

> 2.
> 3.
> 4.


Received on Thursday, 29 September 2011 22:50:04 UTC