User Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en; rv:188.8.131.52) Gecko/20120308 Camino/2.1.2 (like Firefox/3.6.28) Build ID: 20120308211433 Steps to reproduce: Went to http://9to5mac.com/ with Camino Version 2.1.2 (184.108.40.206 20120308211433) on Macbook Pro. Actual results: Text overlap occurs with Camino that does not occur with Chrome, Safari, Omniweb. Size of header text also appears inappropriately small compared to these other browsers. 9to5mac.com just updated their site this weekend to enhance viewing on all screen sizes. This may be a useful test site for you. Expected results: No text overlap. Headers should be appropriate size.
Compare against Firefox 3.6.28 and see how that looks. Comparing Gecko against Webkit isn't really a valid comparison.
Camino 2.1.2 (220.127.116.11 20120308211433) on Mac Mini same issue. Also render fine with Opera. Renders fine with Firefox 5.01. I do not have Firefox 3.6.28.
Firefox 3.6.28 can be downloaded here: ftp://ftp.mozilla.org/pub/mozilla.org/firefox/releases/3.6.28/mac/en-US/ Other versions of Firefox aren't really a valid comparison because they use a vastly different Gecko rendering engine.
This is another case where the Gecko 1.9.2 HTML parser shows its age :-( The HTML5 parser that ships with Safari 6, Firefox.latest and Opera 12 recovers from errors, but Camino can't. And 9to5mac.com should really pay some attention to the quality of their markup. Feel free to complain to that site. In the current situation, there is nothing Camino can do. Won't fix, but should really be 'can't fix' in the current situation.
Again, I suppose we could kick this to Tech Evangelism, but is it really worth it? (How bad *is* the markup? I didn't look.)
I just reported it because it looked like Camino was the only browser that I saw this with and I thought it might point to a fundamental rendering issue that might be import to know about. If Camino is considered an end-of-life product that would change everything (I use it as my default on G5 and Intel Macs so I hope that is not the case). But rendering pages with overlapping text and images seems like it might point to a fundamental problem in page rendering. Unless Camino is an EOL product, it would seem that this would merit sorting out and fixing. Perhaps 9to5mac is doing something in a non-standards-compliant way that is being forgiven by the other browsers, but if that is the case, Camino is the singular case that breaks.
> it would seem that this would merit sorting out and fixing See http://caminobrowser.org/blog/2011/#mozembedding and philippe's comment above.
OK, I understand the situation better now. I did report this issue to the 9to5mac webmaster yesterday. It appears that they and others would need to continue to test on Camino (Firefox 3.6) to assure good handling of their site(s) on these browsers. They will have to decide whether or not such effort would improve their code generally versus addressing a legacy rendering idiosyncrasy. That said, I don't know if this bug report is worth further attention by the Camino volunteer developers, and perhaps it should be closed now. That is your call. I greatly appreciate the responsiveness to this and all the great work of the team.
The developers at 9to5mac.com should validate their markup ; that would go a long way to fix the issues that appear in Camino. I'm fairly sure that IE 8 / Windows will show the same problems (that might not be a target market for that site though…). The errors I saw when I looked earlier today (in the snippet I inspected): <header> something <article> something </article> <header> something <article> something </article> They are missing the closing </header> tag (required). In a browser with an HTML5 parser, that 'knows' those elements, there is error recovery (that is all documented in the HTML5 spec. This doesn't happen with Camino / Gecko 1.9.2; that parser doesn't know about those elements. The result is that the subsequent blocks are nested - it shows as a 'stairs' effect.  http://validator.w3.org/check?uri=+9to5mac.com&charset=%28detect+automatically%29&doctype=Inline&group=0&ss=1