Problem with the Mozilla Firefox Browser

[Cogito]

I have several pages of links (in a foreign language) that look good
with IE and Opera. Recently I discovered the Mozilla Firefox browser
and was surprised to see that some of the graphic bullets are
displayed in the wrong side of the text. All the lines of code for the
links are identical. Why is it happening?

http://users.bigpond.net.au/blackbox/anz/anz.html

 

[Els]

I have several pages of links (in a foreign language) that
look good with IE and Opera. Recently I discovered the
Mozilla Firefox browser and was surprised to see that some
of the graphic bullets are displayed in the wrong side of
the text. All the lines of code for the links are
identical. Why is it happening?

http://users.bigpond.net.au/blackbox/anz/anz.html

First thing I see when clicking on it, is Hebrew text. This is
written from right to left, so you're probably making use of
<rtl> and <ltr> elements?

Then I want to "enter", but you have a problem with the frames,
see this screendump from Firebird.
http://locusmeus.com/temp/anz.jpg

The "bin"-link top right corner, right frame, is the only link I
can click, and leads to the NZ map.

 

[Jim Higson]

I have several pages of links (in a foreign language) that look good
with IE and Opera. Recently I discovered the Mozilla Firefox browser
and was surprised to see that some of the graphic bullets are
displayed in the wrong side of the text.

Isn't the language right-to-left? In which case it'd be correct to have the
bullets on the right.

It's the same in Konqueror (and presumably Safari)

 

[Jim Higson]

First thing I see when clicking on it, is Hebrew text. This is
written from right to left, so you're probably making use of
<rtl> and <ltr> elements?

Then I want to "enter", but you have a problem with the frames,
see this screendump from Firebird.
http://locusmeus.com/temp/anz.jpg

Screenshot from my computer (Firefox 0.93, Linux) - looks fine to me
http://users.aber.ac.uk/jqh1/foxy.png

 

[Els]

First thing I see when clicking on it, is Hebrew text. This
is written from right to left, so you're probably making
use of <rtl> and <ltr> elements?

Okay, I have now looked in IE and Firefox (not Firebird), and
I see your problem.
You're talking about for instance the links
on this page:
homepage -> click on "Australia" (hoping you read Hebrew!) ->
then click on "Telefon" ->
the links in the main frame:
Telstra (right side)
Optus (wrong side)
Virgin "
Vodafone "
Orange "
Three "

Right?

Haven't figured out (yet) why it's like that, at first sight I
see no reason either.

 

[Cogito]

Okay, I have now looked in IE and Firefox (not Firebird), and

I see your problem.
You're talking about for instance the links
on this page:
homepage -> click on "Australia" (hoping you read Hebrew!) ->
then click on "Telefon" ->
the links in the main frame:
Telstra (right side)
Optus (wrong side)
Virgin "
Vodafone "
Orange "
Three "

Right?

Haven't figured out (yet) why it's like that, at first sight I
see no reason either.

Yes, this is the problem. Most bullets appear on the right with the
text to their left, as should be and as is the case with IE and Opera.
With Firefox, most links are ok, but some, for unknown reason, have
the icon on the left of the text.

 

[Cogito]

Screenshot from my computer (Firefox 0.93, Linux) - looks fine to me
http://users.aber.ac.uk/jqh1/foxy.png

You need to click on one of the links that are on the right in order
to get to the problematic page.

 

[Els]

Yes, this is the problem. Most bullets appear on the right
with the text to their left, as should be and as is the
case with IE and Opera. With Firefox, most links are ok,
but some, for unknown reason, have the icon on the left of
the text.

Well, those 'some' are all English, and the only English ones
that have the bullet on the right side, are those following
Hebrew ones. (AFAICS)

I guess Firefox somehow detects the used language by the
character. I know there's some mentioning of the left to right
and right to left use in the specs, maybe you can find the
reason in there?

What would happen if you substitute the English ones with
Hebrew ones? Would the bullet switch place? I think it would,
actually.

Interesting stuff, I might have a look at it again later.

 

[Els]

Well, those 'some' are all English, and the only English
ones that have the bullet on the right side, are those
following Hebrew ones. (AFAICS)

I guess Firefox somehow detects the used language by the
character. I know there's some mentioning of the left to
right and right to left use in the specs, maybe you can
find the reason in there?

What would happen if you substitute the English ones with
Hebrew ones? Would the bullet switch place? I think it
would, actually.

Interesting stuff, I might have a look at it again later.

Okay, investigated a little.

Haven't studied it in depth, but this link:
http://www.w3.org/TR/CSS21/visuren.html#direction
explains why it's like that. The Hebrew characters indeed have
a natural rtl direction, and the English ones have it ltr.

The document is bidirectional:

<quote>
For the 'direction' property to affect reordering in inline-
level elements, the 'unicode-bidi' property's value must be
'embed' or 'override'.
</quote>

And here's part of the solution:
<quote>
Please note that in order to be able to flow inline boxes in a
uniform direction (either entirely left-to-right or entirely
right-to-left), more inline boxes (including anonymous inline
boxes) may have to be created, and some inline boxes may have
to be split up and reordered before flowing.
</quote>

Sounds like you'll need some extra coding
Why don't you avoid the problem altogether and write those
English brandnames in Hebrew too? Makes more sense too, imho.

 

[Els]

Haven't studied it in depth, but this link:
http://www.w3.org/TR/CSS21/visuren.html#direction
explains why it's like that. The Hebrew characters indeed
have a natural rtl direction, and the English ones have it
ltr.

The document is bidirectional:

<quote>
For the 'direction' property to affect reordering in
inline- level elements, the 'unicode-bidi' property's value
must be 'embed' or 'override'.
</quote>

And here's part of the solution:
<quote>
Please note that in order to be able to flow inline boxes
in a uniform direction (either entirely left-to-right or
entirely right-to-left), more inline boxes (including
anonymous inline boxes) may have to be created, and some
inline boxes may have to be split up and reordered before
flowing. </quote>

Sounds like you'll need some extra coding
Why don't you avoid the problem altogether and write those
English brandnames in Hebrew too? Makes more sense too,
imho.

Or use the simple html solution:
http://locusmeus.com/temp/rtl.html

Be aware of the order of the stuff inside the spans.
That's why I put the span tags (start and end tag of the span
element) between the lines instead of at the end and the
beginning. In a rtl environment the elements also get read the
other way round, so this way I avoid the mix-up between the
end or the beginning of a line.

 

[Cogito]

Or use the simple html solution:
http://locusmeus.com/temp/rtl.html

This last html solution is the one I understand best and it works.
Why does it work well with IE and Opera? Perhaps Firefox is not as
smart?

Thank you very much for the efforts that you have put in.

 

[Els]

This last html solution is the one I understand best
and it works. Why does it work well with IE and Opera?
Perhaps Firefox is not as smart?

Or maybe Firefox is too smart ;-)

Thank you very much for the efforts that you have put in.

You're welcome.

 

[Toby Inkster]

Or maybe Firefox is too smart ;-)

IE is lucky. It is stupid, doesn't try to do the right thing, but somehow
happens to stumble on the right solution anyway.

Firefox is fairly smart. It tries to do the right thing, but fails.

Opera is smart. Opera ASA have recently been trying to crack the Middle
Eastern and Asian markets so bidi support has recently improved in leaps
and bounds. Thus it gets things right.

A good analogy would be leap years.

A stupid calendar implementation just ignores them altogether and when
calculating how many days were in the year 1900, will say 365. It will be
right.

A better calendar implementation says that every 4 years is a leap year,
so it will say there were 366 says in the year 1900. It is a better
algorithm but it will fail in this specific case.

The best calendar implementation says that every 4 years is a leap year
except every 100 years, except again every 400 years. It will calculate
that there were 365 days in the year 1900.

The stupid implementation fails more often than the better implementation,
but there are certain times when it succeeds where the better one fails.

 

[C A Upsdell]

A good analogy would be leap years.

A stupid calendar implementation just ignores them altogether and when
calculating how many days were in the year 1900, will say 365. It will be
right.

A better calendar implementation says that every 4 years is a leap year,
so it will say there were 366 says in the year 1900. It is a better
algorithm but it will fail in this specific case.

The best calendar implementation says that every 4 years is a leap year
except every 100 years, except again every 400 years. It will calculate
that there were 365 days in the year 1900.

The stupid implementation fails more often than the better implementation,
but there are certain times when it succeeds where the better one fails.

And a clock that is broken is perfectly correct twice every day: whereas a
clock that is working is almost never perfectly correct.

 

[WebcastMaker]

And a clock that is broken is perfectly correct twice every day: whereas a
clock that is working is almost never perfectly correct.

Actually it depends on HOW it is broken. If is is does not function,
then you are correct, however,if it just keeps inaccurate time, then you
are wrong.

 

[Toby Inkster]

Actually it depends on HOW it is broken. If is is does not function,
then you are correct, however,if it just keeps inaccurate time, then you
are wrong.

If it spins around at very high speed it could be perfectly correct a
hundred times per day!

 

[WebcastMaker]

If it spins around at very high speed it could be perfectly correct a
hundred times per day!

Which still makes my statement correct.