Hmmm . . . this is interesting: Safari and Chrome . . .

Post #333,175 by Andrew Grygus 9/26/10 10:35:33 PM Reply	Hmmm . . . this is interesting: Safari and Chrome . . . . . both have similar problems on my fish page with not properly observing [br clear="left"] tags - but are also a bit inconsistent, sometimes getting one right and sometimes not. http://www.clovegard...red/seafishv.html I tried putting in height and width dimensions on the images in one of the problem areas, but that didn't help at all. Internet Explorer and Firefox have no problems with this, always getting it right. I haven't used height and width, which are supposed to speed rendering, since the early days of my using html. I laboriously inserted the height and width dimensions for a page with a lot of images, and it took twice as long to load. Safari for Windows seems to take a lot longer to load the page than other browsers. I installed Safari for testing because, viewing some of my pages on a Mac, they didn't render correctly at all, but the Windows version has not displayed the problems I saw there.
Post #333,178 by malraux 9/26/10 11:00:10 PM Reply	What's really interesting... If I save that page locally, Safari displays it fine. Chrome displays it improperly from both locations. Both browsers use WebKit, incidentally. Except, now Chrome is displaying it fine locally. Must be a timing issue. Try adding a div around the image, name, and description, and close it just before the br clear. Regards, -scott Welcome to Rivendell, Mr. Anderson.
Post #333,181 by Andrew Grygus 9/26/10 11:23:22 PM Reply	Thanks, I'll give that a try . . . . . when I can get back to it. What I saw on the Mac was the top left photo and the whole body shifted to the right of the left column, which looked pretty bad. These failures to clear left aren't so bad. I'll have to take a look on another Mac as soon as I can. What! you only noticed one typo on that huge page? Fixed - thanks.
Post #333,182 by malraux 9/26/10 11:30:19 PM Reply	Different Scott... ;-) I didn't see the photo shifted, just everything below the second HR. Regards, -scott Welcome to Rivendell, Mr. Anderson.
Post #333,183 by Andrew Grygus 9/26/10 11:49:05 PM Reply	Were you using a Mac?
Post #333,203 by malraux 9/27/10 9:18:43 AM Reply	Yes. Regards, -scott Welcome to Rivendell, Mr. Anderson.
Post #333,185 by Andrew Grygus 9/27/10 1:21:47 AM Reply	Timing issues, huh? So these browsers achieve the high speed they boast of by simply not bothering to render anything they find inconvenient? Since I use nothing but the most basic html on my pages, this says a lot about their quality.
Post #333,210 by drook 9/27/10 9:54:09 AM Reply	Not just speed That's been part of HTML rendering since just about always. Anything a browser doesn't recognize it will ignore. Improperly nested or closed elements are essentially arbitrary. I've seen arguments saying the only way to "fix the web" is for browsers to always render strict. Of course the other side chants "strict in what you emit, liberal in what you accept". -- Drew
Post #333,317 by scoenye 9/28/10 7:09:26 PM Reply	And there are quite a few of those on that page "Improperly nested or closed elements" that is... (and even a few freshly minted ones.) There is a good chance that Safari and Chrome are indeed reacting differently to the coding errors.
Post #333,321 by Andrew Grygus 9/28/10 9:36:45 PM Reply	I've been over and over my nesting and closings . . . . . and I'm very careful with closings, applying them even thought browsers traditionally correct for them being missing. Now get this. If I move the edge of the browser window in a ways all the formatting becomes correct. If I move the edge back out, some of the fixed errors stay corrected and others revert to incorrect. I will inspect my nesting and closings one more time, but don't expect to find anything.
Post #333,325 by drook 9/28/10 10:42:48 PM Reply	Try the validator http://validator.w3.org/ Looks like your biggest problem is not quoting values. -- Drew
Post #333,328 by scoenye 9/28/10 11:01:52 PM Reply	Not so much unbalanced nesting but disallowed nesting. E.g. there are a lot of anchor constructs that contain an H2. That is block level content where only inline is allowed. (And there are also three instances where the A when missing, resulting in a NAME element). None of the warnings occur on one of the images you're floating, but as these are also embedded in anchors, it is possible that an imbalanced anchor tag causes the BR to happen at an unexpected spot.
Post #333,335 by Andrew Grygus 9/29/10 1:12:03 AM Reply	Yeah, a lot of values are not quoted . . . . . because the originals of a lot of my stuff were done before the XML spec came out requiring the quotes and they got replicated. HTML didn't require them. I've been inserting them as I go, but there's a hell of a lot of them - and I'm not using XML.
Post #333,179 by Another Scott 9/26/10 11:00:55 PM Reply	Typo - "North American. buyers"
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!