Closed Bug 249828 Opened 17 years ago Closed 12 years ago

walla.co.il - Text and images overlap in article pages

Categories

(Tech Evangelism Graveyard :: Hebrew, defect)

Product:
Tech Evangelism Graveyard
Component:
Hebrew
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: bugzillamozilla, Unassigned)

References

(
URL
)

Details

(Keywords: top500)

Attachments

(4 files, 1 obsolete file)

Layout comparison: Mozilla 1.7, 1.6 and IE6
46.31 KB, image/png
Details
Somewhat reduced testcase
935 bytes, text/html
Details
Outlined screenshot of the last testcase
7.82 KB, image/png
Details
Same testcase, dir="rtl" in the class="wp-0-b w3" div
964 bytes, text/html
Details 
Walla.co.il article pages look fine in Mozilla 1.6, but show broken layout in
1.7, which is why it's probably not a Tech Evangelism issue.

I'll soon attach a screenshot that compares an article page in Mozilla 1.7, 1.6
and IE6

Prog.
The attached screenshot shows that a regression in Mozilla 1.7 had caused some
text and images to overlap. I've verified this to happen in both OS X and
WinXP.

I'll try to create a reduced testcase later on, or at least find the build
where this regression occurred. I'm not sure I'll manage to do it though, so if
someone more skillful can help I'll greatly appreciate it.

Prog.
We really do need that reduced testcase (please file layout bugs without
testcases as UNCONFIRMED).
Keywords: qawanted
I've reduced most of the extraneous code in the page. It still links to
external CSS though, I hope that's not too much of a hassle.

Prog.
Boris, please see comment #3.

Prog.
The layout of the testcase is correct.  The div has to be wider than its parent
cell, since it has padding and width:100%.  Then it should overflow to the left,
since the direction on the cell is rtl.

Mozilla 1.6 had some code that kept the div from being wider than the cell
(which is wrong in itself and caused very wrong rendering in some cases).  But
that's been fixed since 1.6.
Assignee: nobody → hebrew
Component: Layout → Hebrew
Product: Browser → Tech Evangelism
QA Contact: core.layout → hebrew
Version: Trunk → unspecified
i sent them the evangelism letter, i hope. after submitting it i got a page with
code :/
Adding dir="rtl" to the class="wp-0-b w3" div fixes the original page and the
testcase. It doesn't break in IE.

Boris, is this a sufficiently correct "fix"? 

Tsahi, if it is, can you please follow up your letter to walla with this suggestion?

Thanks,

Prog.

> Boris, is this a sufficiently correct "fix"? 

Not sure.  I based my comments on the testcase, not on the page, and the
testcase has no such div...
I'm referring to this div (taken from the original testcase):

  <div style="padding: 8px 12px 0px; text-align: justify;"
  class="wp-0-b w3">Test2 Test2 Test2 Test2 Test2 Test2 Test2 Test2
  Test2 Test2 Test2 Test2 Test2&nbsp; Test2<br>

To this, I've added dir="rtl" and the page seems to look fine.

Prog.
That's very odd.. direction is inherited, so adding that attr should have had
absolutely no effect...
Attached file Walla article, with the same change (obsolete) — 
The only other change I introduced into this file was to replace a relative
link to a CSS file, with a global one.

Prog.
prog, comparing your last attachment and another article from euro.walla.co.il,
it's obvious to me that you used Composer rather than a text editor to work on
this. the code of the article i looked at is completely messed up, with no
<head></head> tags, no <tbody> tags, and certainly no doctype declaration. and
no indentation too.

on top of that, your attachment still displays the same problem, of the right
nav bar outside the page borders. something that, btw, i didn't see in other
articles in the sports or Euro sections. in fact, the problem reported in this
bug occurs only in the news section of the site, so you might want to see what's
different in it from the other sections.
Thanks for the sharp eye Tsahi, you are correct. I did use Composer.

Still, the only difference between attachment 153276 [details] and attachment 153384 [details] is
the addition of dir="rtl". Does anyone have any idea why it fixes the problem?

Prog.
Attachment #153385 - Attachment is obsolete: true
Two approaches for fixing this issue, which can be taken in parallel:

1. Fix Mozilla code

It seems that their site works on IE6, not because it expands container TD to
accomodate the DIV+padding, but rather because, in quirks mode, it considers
block's width == content+padding+margin, so when the DIV says width:100%, that
100% includes the padding.

This is an explicit IE6 quirk in their Compat mode ("Quirks mode"). Should we
emulate it?
Read "Fix the Box Instead of Thinking Outside It" at
http://msdn.microsoft.com/library/en-us/dnie60/html/cssenhancements.asp

Hixie is against this. He says they're *removing* this quirk from Opera.

2. Evangelism

Walla should change their code, so that the TD would have the padding, not the
DIV. That should solve the problem.

> Should we emulate it?

No.  We're not emulating this quirk.
(In reply to comment #7)
> i sent them the evangelism letter, i hope. after submitting it i got a page with
> code :/

i got an automated confirmation on that, so they probably got it.
Keywords: qawanted, regression
Summary: Regression: Text and images overlap in walla.co.il article pages → Text and images overlap in walla.co.il article pages
the right navigation bar of the article in th URL field is now in place, so i
would guess they fixed this problem. they still have problems in the left bar,
where the text overlaps the article text and images.
I don't know what they changed, but they didn't do the only change which makes 
sense - and that's to set the padding on the TD rather than on the DIV. This 
change will fix the problem for good. 
I've sent them a message (via the "Write Us" form), presenting myself as a 
Mozilla and Firefox developer responsible for issues with Hebrew sites. I've 
requested to speak to them by phone. If they won't call me back during the 
first days of next week, I'll call them voice myself. 
if you call them, tell them about some other problems they have too:
1. impossible to submit talkbacks to articles
2. chat is blocking mozilla
3. shopping.walla.co.il is using an ugly monospaced font for mozilla, while IE
uses variable width.
4. the "thank you" page you get after sending them a message contains code
instead of html, but you probably noticed that already.
5. in walla mail, you can't select all the messages in the folder with the
checkbox at the top of the folder (or at least, i assume that's what it's
suppose to do. i can check that if you like).

probabley other problems too.
Conforming summary to TFM item 10 at 
http://www.mozilla.org/projects/tech-evangelism/site/procedures.html#file-new
Summary: Text and images overlap in walla.co.il article pages → walla.co.il - Text and images overlap in article pages
*** Bug 260017 has been marked as a duplicate of this bug. ***
*** Bug 239515 has been marked as a duplicate of this bug. ***
one way or another, it appears like new articles in walla are now displayed
correctly. the one in the URL still looks bad though.
Keywords: top500
(In reply to comment #25)
> one way or another, it appears like new articles in walla are now displayed
> correctly. the one in the URL still looks bad though.

I still have problems with Walla.

Check this page:

http://news.walla.co.il/?w=//657271

This is how it looks in Opera:

http://img61.exs.cx/img61/9353/opera5ej.jpg

This is how it looks in Firefox:

http://img61.exs.cx/img61/5457/ffox4ak.jpg


(In reply to comment #26)
> (In reply to comment #25)
> > one way or another, it appears like new articles in walla are now displayed
> > correctly. the one in the URL still looks bad though.
> 
> I still have problems with Walla.
> 
> Check this page:
> 
> http://news.walla.co.il/?w=//657271
> 

i probably checked that with mozilla 1.7.3 or so. i currently don't have access
to seamonkey because of problems with my PC, so i can't check. at some point
there were some updates to gecko in the aviary branch, that were ported to
seamonkey only with mozilla 1.7.5, but i doubt if that is the reason. can anyone
check it with mozilla 1.7.3?
*** Bug 279708 has been marked as a duplicate of this bug. ***
*** Bug 310094 has been marked as a duplicate of this bug. ***
*** Bug 316172 has been marked as a duplicate of this bug. ***
Here's a quick userContent.css hack for those interested (works in Firefox 1.5 and above, of course):

@-moz-document domain(walla.co.il) {
    .wp-0-b {width: auto !important;}
    .wp-1-b {width: auto !important;}
}
(In reply to comment #31)
> Here's a quick userContent.css hack for those interested (works in Firefox 1.5
> and above, of course):
> 
> @-moz-document domain(walla.co.il) {
>     .wp-0-b {width: auto !important;}
>     .wp-1-b {width: auto !important;}
> }
> 

I've created a Greasemonkey script based on this CSS, hosted at http://userscripts.org/scripts/show/2244
Issue no longer valid. :)
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Product: Tech Evangelism → Tech Evangelism Graveyard
You need to log in before you can comment on or make changes to this bug.