Conclusion: Safari (Win) can't render W3C validated code.

Post #333,607 by Andrew Grygus 10/3/10 2:47:06 AM Reply	Conclusion: Safari (Win) can't render W3C validated code. Spent many hours today examining my fish page and making corrections. Seems I hadn't been watching my "<a name=" environs because there were a lot of them unclosed. Fixed and it made no difference. FireFox and Internet Exploder did fine, Chrome had a couple of things out of order and and Safari did a lousy job. Made a couple minor corrections, and Chrome did fine. Safari still screwed it up (unless I moved the margins in). Now I was ready for the validator and got 46 errors (effectively about 30). Corrected all and validated with 0 errors. Result: Firefox, Internet Explorer, Chrome: Perfect. Safari: one improvement - the second horizontal rule was placed correctly - all other errors remained (and yes, I did reload the page). Safari is also very slow at loading and rendering the page. Now - could someone have a look from a Mac and see how the page looks? When I looked at it everything below the upper left photo was shifted right and in several places "<br clear='left'>" wasn't recognized. http://www.clovegard...red/seafishv.html
Post #333,608 by Ashton 10/3/10 4:07:02 AM Reply	Interesting.. (5/08 built 2.66 GHz iMac 20", 4 GB etc.) Snow Leopard 10.6.3 Safari Version 4.0.5 (6531.22.7) When I first opened link (new window) I saw the right shift you describe. As I usually set horiz. size of browser window to <max available, I expanded to right, a tad: the right shift ceased as I moved the rt.-margin -->. Then I reduced horiz. size in increments; at any abbreviated or lengthened horiz. setting, no more right-shifts happened! Looking at w3c re BR clear="left", at http://www.w3.org/TR...ent/graphics.html (Note, they use ["] and not ['] in their example-prose; I used bold above, here ... lest I add-confusion about notation. Browsing down your page . . . Where your last sentence needs more space than image-height accommodates: all those extra sentences appear to begin under the image and at image's left margin -- per spec. as illustrated, for this command. Strange that it exhibited the glitch, was immediately 'corrected' just by moving out the rt. margin ... and right-shift never recurred. (I didn't nuke cache and try clovegarden link fresh, after this first try.) ... prefer not to nuke cache as I have n+1 pages open, some of which I don't want to have reloaded with new/today's update. hth, I.
Post #333,611 by mvitale 10/3/10 9:28:09 AM Reply	Re: Conclusion: Safari (Win) can't render W3C validated code Try the following right at the top of the page: `<div> <p> <img src="./img/sf_pompg12h.jpg" alt="Golden Pompano" align="left" hspace="8" vspace="2" border="0"> <big><big><b><big>Varieties of Fish</big></b></big></big></p> <hr size=2 noshade> <big>Here are listed both fresh water and salt water fish because the two can't be cleanly separated. Many fish move to salt water to mature and come back to fresh water to spawn and others are found both in salt and fresh water.</big> <br clear="left"><hr size=2 noshade align="left"> </div>` -Mike "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." - Benjamin Franklin, 1759 Historical Review of Pennsylvania
Post #333,612 by malraux 10/3/10 11:16:55 AM Reply	Still shifted. I don't use Safari very often at all. I may switch to Chrome because FireFox can be so freaking unstable at times. But probably never Safari. What's interesting is that both Safari and Chrome use WebKit. Regards, -scott Welcome to Rivendell, Mr. Anderson.
Post #333,614 by Another Scott 10/3/10 11:22:14 AM Reply	I was thinking that last as well. Must be something subtle.
Post #333,615 by Andrew Grygus 10/3/10 11:57:49 AM Reply	I have done the div thing mvitale suggested. Let me know if there's any difference. Incidentally, to test it still worked, I reloaded the page in Safari without noticing it was set to full screen. Aside from the usual problems there was one area that crashed, with one item overlayed over another. This was corrected by changing to a window. As I said before, if I move the margins closer together the formatting is correct. Ashton also noticed that the margin position had a significant effect.
Post #333,616 by Another Scott 10/3/10 12:04:06 PM Reply	Quick thought: Possible font substitutions? A colleague at work was having issues converting a Word document to PDF. The final document had to be no more than 3 pages, and in Word on the Mac with Preview it was getting converted to a 3 page plus one line PDF while on Word on the PC with Acrobat it was exactly 3 pages. There was some subtle difference between the line spacing in the two cases. I know that font substitutions can also cause similar subtle issues. Are the fonts exactly the same on the different browsers/platforms? Are the browsers doing any different substitutions? Cheers, Scott. (Who understands that wrapping, etc., shouldn't care about the font, but I think it sometimes matters.)
Post #333,618 by Andrew Grygus 10/3/10 12:11:04 PM Reply	Re: Quick thought: Possible font substitutions? I have changed the font on my OS/2 firefox (no problems). Otherwise, testing from the Windows XP machine Firefox, Internet Explorer, Chrome and Safari all are using whatever font they shipped with. Incidentally, the rendering engine is at least part of the problem. While Chrome has been error free when the page is loaded in a window, I reloaded in full screen mode and Silver Pomfret was out of place, otherwise all correct, so margins matter there too, just not so much.
Post #333,617 by malraux 10/3/10 12:10:51 PM Reply	Works. And you mean that div thing that I suggested that Mike repeated... ;-) Regards, -scott Welcome to Rivendell, Mr. Anderson.
Post #333,619 by Andrew Grygus 10/3/10 12:34:07 PM Reply	It doesn't work for the other formatting problems though. "<div> around Silver Pomfret and Chinese Silver Pomfret does not fix the failure to properly recognize the "<br clear='left'>"
Post #333,621 by malraux 10/3/10 12:52:05 PM Reply	Not a fix, a replacement. Regards, -scott Welcome to Rivendell, Mr. Anderson.
Post #333,620 by SpiceWare 10/3/10 12:47:30 PM 10/3/10 1:49:16 PM Reply	weird issues http://www.spiceware.org/images/cg.png This problem reoccurs multiple times going down the page. If I use a smaller width it renders correctly. Just tried WebKit (the nightly builds of Safari) and the problem is still there. I'll submit a bug ticket once my WbKit Bugzilla account gets activated. Edit: Bug 47062 https://bugs.webkit...._bug.cgi?id=47062 Edited by SpiceWare Oct. 3, 2010, 01:49:16 PM EDT Expand All History
Post #333,729 by SpiceWare 10/5/10 11:19:55 AM Reply	Somebody updated it added a keyword, NeedsReduction - This bug needs a reduced test case.
Post #333,732 by Andrew Grygus 10/5/10 12:05:46 PM Reply	Yup, and a "reduced test case" . . . . . probably won't show the problem - "bug case closed".
Post #333,733 by hnick 10/5/10 2:10:47 PM Reply	Well, if you can't fix the problem, fix the spec :-(
Post #333,734 by SpiceWare 10/5/10 2:47:41 PM Reply	I can try to reduce it but it won't be until next week as my folks are in town from Trinidad.
Post #333,739 by Andrew Grygus 10/5/10 4:58:43 PM Reply	Oh, I can reduce it very easily, but . . . . . I think instead I'll W3C certify Cabbage Greens which is much shorter and it screws that up pretty bad. Interestingly, if the margin is moved after loading, either in or out, it is instantly corrected. Several other of the vegetable pages behave the same. The crash you have shown (text running over pictures and text) rarely appears on my system even on the fish page.
Post #333,746 by Andrew Grygus 10/5/10 11:11:07 PM Reply	And here it is. Cabbage greens displays correctly in Chrome but Safari screws up the "<br clear="left"> quite badly. Again if the margins are changed even slightly it displays correctly, but if the page is reloaded at the new margins it's bad again. I'd appreciate hearing how it looks on a Mac. http://www.clovegard...red/cb_green.html
Post #333,749 by Ashton 10/6/10 2:09:06 AM Reply	On a Mac Same deal; move width slightly -- things line up, stay fixed: after moving back to original setting (as close as you can mouse.) {sigh} Safari meets my minimal demands: adequacy. Not sure if it's still faster than FF. (NoScript is like a Swiss Army knife with 1800 blades.. maybe you could protect againse all Evil, but you must tell it about each one !!! ONE !!! incremental-Evil.)
Post #333,752 by folkert 10/6/10 7:34:39 AM Reply	Display at 1149 pixels wide... and I get cascading on every Subsection. Move the right side or left side one pixel larger or one pixel smaller, everything re-renders perfectly and lines up just like you want. Weird.
Post #333,636 by drook 10/3/10 9:26:25 PM Reply	Just thought of something I think that parameter on the [br] tag is non-standard. The CSS way would be <br style="clear:both" /> -- Drew
Post #333,639 by malraux 10/3/10 10:50:07 PM Reply	Yep. BR supports class, id, style, and title attributes. Regards, -scott Welcome to Rivendell, Mr. Anderson.
Post #333,641 by scoenye 10/3/10 11:08:00 PM Reply	Standard but deprecated And in this case, the CSS variant doesn't help.
Post #333,648 by Andrew Grygus 10/4/10 12:21:46 AM Reply	I have specified doctype 4.1 transitional . . . . . which includes support for the deprecated formatting methods. Safari clearly supports this - just not as well as other browsers.
Post #333,696 by scoenye 10/4/10 10:41:59 PM Reply	One way to consistently clear it... ... is to move the BR tags outside of the enclosing paragraph. (And add enclosing P tags around the "Varieties of fish" intro paragraph.) As to why, I guess only Steve knows...
Post #333,699 by Andrew Grygus 10/4/10 11:43:54 PM 10/4/10 11:54:05 PM Reply	Re: "One way to consistently clear it... ... is to move the BR tags outside of the enclosing paragraph" Originally that's how I had it, but it caused very inconsistent spacing and a number of other serious display problems. I don't remember them all but one I do is that links didn't hit anywhere near the right place. Moving the br tags within the paragraph solved all that and there's no way I'm moving them back. Edited by Andrew Grygus Oct. 4, 2010, 11:54:05 PM EDT Expand All History
Post #333,638 by folkert 10/3/10 10:45:51 PM Reply	"Web Browser v2.30.2" or Epiphany... Has very similar results. Its based on WebKit also. Mine get more and more perverted... until I reloaded it about 5 times and then full screen the baby. From then on its perfect, until I reload again. So it IS the rendering engine in WebKit giving some weird shee.

Welcome to IWETHEY!