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.
(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?
> > 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.
(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.
> 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.
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?
Sounds like you're asking for "direction: auto", where 'auto' tells the UA to use a heuristic to guess the element's direction.
"direction: auto" sounds good to me.
I've proposed "direction: auto" on the www-style list: http://lists.w3.org/Archives/Public/www-style/2004May/0359.html
Status: UNCONFIRMED → NEW
Ever confirmed: true
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?)
Mass-assigning the new rtl keyword to RTL-related (see bug 349193).
Component: Layout: BiDi Hebrew & Arabic → Layout: Text
QA Contact: zach → layout.fonts-and-text
You need to log in before you can comment on or make changes to this bug.