This bank website 'should' have a global navigation area around the initial login form. Only the core login
form is rendered in Safari. Compare to the correct rendering in Opera or IEWin 5.5sp2. There are further
errors deeper within the site, affecting core functionality, but may be related to the same issue. This is the
easiest to reproduce without an account with the bank.
In a local copy of the page, if I remove the <!doctype ... > tag, the page renders perfectly. This problem
did not exist prior to the Safari build prior to OS 10.4.3 update. Latest nightly build as of 10/27 still has
Page renders incorrectly in Camino 0.8.4 and Firefox 1.5rc3 as well, but renders correctly with Opera 8.02
Created attachment 4837 [details]
Screenshot of what the page should look like
Correct Rendering was from Opera.
Created attachment 4838 [details]
Screenshot of Safari (incorrect) rendering
The DOCTYPE used is <!doctype html public "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3c.org/TR/html14/loose.dtd">, which doesn't exist. (the correct URL would be "http://www.w3.org/TR/html4/loose.dtd").
So this site is trying to use a non-existent version of HTML ; I'd classify that as an evangelism bug. Also note that Firefox's rendering (126.96.36.199) is the same as Safari's.
(In reply to comment #3)
> The DOCTYPE used is <!doctype html public "-//W3C//DTD HTML 4.01
> Transitional//EN" "http://www.w3c.org/TR/html14/loose.dtd">, which doesn't
> exist. (the correct URL would be "http://www.w3.org/TR/html4/loose.dtd").
> So this site is trying to use a non-existent version of HTML ; I'd classify
> that as an evangelism bug. Also note that Firefox's rendering (188.8.131.52) is the
> same as Safari's.
Yes, there also appears to be a problem related to the way the comments are included (long ----- seperators) ... attempts to get them to fix this got the usual "sorry, we only code for IEWin" ... unfortunate that IEWin actually renders the page as intended. So, I guess I have to keep Opera around for this site, as it's the only Mac browser I've seen that works with this.
See also: http://ln.hixie.ch/?start=1137799947
Replacing the DOCTYPE with a real HTML4 Transitional DOCTYPE doesn't fix the problem, which means that this is indeed a regression which appeared after the acid2 comments parsing fix (removing the DOCTYPE makes Safari switch to quirks mode, where that fix is not applied).
Note that SGML comment parsing is gone from HTML5.
Comment parsing in strict mode in HTML5 is defined in:
Simply removing all of the comment lines where the number of '-' chars are > 2, the page renders correctly, so I'm assuming that the issue is in the comment parsing. I will work on a reduction to get a small test case for this.
Created attachment 6406 [details]
Minimal Test Case
Small test case showing missing rendering after a malformed comment line (I think ;-). Should display 2 lines of text. the second line does not render when the comment is left in the code. Remove the comment, and the text renders fine.
Interestingly, if I remove the SCRIPT line in the HEAD section, the page renders correctly as well. What the heck is that all about??
I don't think this is a regression. downgrading priority. Ping me if you find out that it is. This was also seen at http://www.clintonlibrary.gov/. <rdar://problem/4464323>
Created attachment 7191 [details]
Screenshot of minimal test page in Safari 1.3.2
Here is a screenshot of Safari 1.3.2 (Panther 10.3.9) rendering the minimal test page that Ken submitted . The test page renders correctly. So, it appears that the bug is a regression.
I can also confirm that this is a regression since 10.3.7 (that's what I have installed besides 10.4.5). I don't think there is any reason to doubt the reporter's words that it happened between 10.4.2 and 10.4.3.
Please note that the usbank.com page has changed, and no longer has this problem.
Alexey is correct; the USBank home page has been fixed for proper commenting. However, deeper within that site, there are several pages with the problem still there (yes, I've let them know which ones ;-).
The minimal test case is still valid, and correctly represents the problem on the USBank site.
Created attachment 8013 [details]
revert SGML comment parsing fix
This patch reverts one change made for acid2, <http://weblogs.mozillazine.org/hyatt/acid6.txt>. The local copies of acid2 are updated to the current version (no SGML comment parsing, some additional whitespace); fast/parser/comments.html results now match WinIE.
See also: bug 8626.
This looks great to me, but Hyatt should review. I hope he gives it a prompt review+!
Comment on attachment 8013 [details]
revert SGML comment parsing fix
Committed as revision r14106.
See also bug 9357.