224685 - RFE: a mechanism to decide on which side cropping should ocour for RTL XUL label

Status: NEW

(Core :: Layout: Text and Fonts, enhancement)

Description

[Mark Kaplun]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5a) Gecko/20030728 Mozilla Firebird/0.6.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5a) Gecko/20030728 Mozilla Firebird/0.6.1

By default whenever a XUL label has an RTL direction it is cropped to the left.
This is indeed the desired operation when the text is a RTL or BIDI text, but
when the text is in latin the resault can be strange since the begining of the
word/phrase is cropped. "bugzill" and "mozilla" may end up as "...zilla" 

IMHO there is a need to be able to change the cropping side based on the content
of the label. It can either be automatic, change the start and end direction
when content is latin, or set up a "bidi" attribute so CSS can be written to
change the crop direction. 

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1

[Simon Montagu :smontagu]

(In reply to comment #0)
> "bugzill" and "mozilla" may end up as "...zilla" 

Do you mean this? I would expect them to end up as "...Mozil" and "...Bugzi".
The title of the tab in which I am viewing this bug says: 
"...Bug 224685 - RFE:a mechani"

Is the issue here the same as bug 222486 or different?

Comment 2

[Mark Kaplun]

> 
> Do you mean this? I would expect them to end up as "...Mozil" and "...Bugzi".
> The title of the tab in which I am viewing this bug says: 
> "...Bug 224685 - RFE:a mechani"

I guess that I should have checked instead of making assumption :(. Anyway I
think that the desired outcome should be to display Mozil... which IMHO makes
much more sence then ...Mozil

> Is the issue here the same as bug 222486 or different?
I'm not sure since 222486 AFAIU is a bug about difference of placement of
cropping in the tabs and the window title, while this RFE is about showing latin
text with a LTR cropping even in a RTL label.

What I want to do is to localize my XUL based application to hebrew. The
application will have a mixture of hebrew text and technical terms in english.
By normal localization practise I will change the dir attribute of all labels to
rtl, which will result in having all english label to have ugly cropping. To
solve this I will have to go label by label and change the cropping.
What I seek is a more general solution to this problem.

Comment 3

[Simon Montagu :smontagu]

(In reply to comment #2)

> By normal localization practise I will change the dir attribute of all labels to
> rtl, which will result in having all english label to have ugly cropping.

Personally I would make an all-English label ltr anyway. You don't want C++ to
appear as ++C, for example.

Comment 4

[Mark Kaplun]

 
> Personally I would make an all-English label ltr anyway. You don't want C++ to
> appear as ++C, for example.

OK, this is worse then I feared. I simply have some dynamic labels for which the
source can be either a name entered by the user, or the DNS of a server. For
these labels I can not know in advance which "direction" they are.

I can probably write an XBL to detect if a label is bidi and change the
direction by the result, just thought that it might interest other people as
well. If you think that there is no interest in such feature, then you are
welcome to close this bug.

Comment 5

[Simon Montagu :smontagu]

OK, now I'm on the same page as you. I think what you really need is a new CSS
property |text-direction: contextual|. IMO, this is definitely worth proposing
to the CSS working group. fantasai, what do you think?

Comment 6

[fantasai]

Sounds like you're asking for "direction: auto", where 'auto' tells the UA to
use a heuristic to guess the element's direction.

Comment 7

[Mark Kaplun]

"direction: auto" sounds good to me.

Comment 8

[Simon Montagu :smontagu]

I've proposed "direction: auto" on the www-style list:
http://lists.w3.org/Archives/Public/www-style/2004May/0359.html

Comment 9

[fantasai]

I remember dbaron commenting on it being difficult to resolve 'auto' on blocks that are ancestors of blocks that contain text. Here's a slightly different proposal:

  direction: auto? && [ left | right ]

  When specified on an inline element or a block/table-cell/inline-block that
  contains only inlines, a value + 'auto' computes to either 'left' or 'right'
  according to the rules in the Unicode Bidi Algorithm.
  When specified on any other element, 'auto left' behaves as 'left' and 'auto
  right' behaves as 'right'. The computed value remains (and therefore inherits) 
  as specified.

If I specify "direction: auto left" on the body, then it behaves as "direction: left" until I get down to, e.g. a paragraph. The <body> element and any intervening <div>s don't need to check their descendant text at all. Then when I get to the paragraph element, which has inherited 'auto left', I check the first few characters of its text. If the first character is L, 'direction' computes to 'left' and inherits as 'left' into descendant inlines. If the first character is R, 'direction' computes to 'right' and inherits as 'right'.

Would that work? (dbaron?)

Comment 10

[(no longer active)]

Mass-assigning the new rtl keyword to RTL-related (see bug 349193).