Notice the new graphic at the top of the forums?



Well, that signifies a change for our websites. http://www.aatraders.com and profiles.aatraders.com are now merged into one site. Check out the new graphics by clicking either of the links.

Enjoy

Like the new layout. Any chance that the user databases will ever be merged? I logged on from the main page and figured I'd still be logged on when I came to the forums, but it didn't work that way.

I just realized that there are probably a number of players using different user names on the forums and profile site, so merging the databases could be more of a hassle than it's worth. Oh well, it's no big deal.

You might want to get Moz 1.7 as I think it may be more stable. The site looks just fine in Opera and IE. We aren't doing any kind weird div tags just straight HTML there.

Moz 1.7 doesnt display it right. Neither does FB 0.8.

Its due to the 192 HTML errors in the page.

Sorry, but you are wrong.

I and most other people do not consider empty ALT tags on images an error. Alt TAGs may be more W3C compliant but they are an un-needed and uneccessary extra being sent to the browser.

I ran a validator on the site and





Out of 35 tables on the page there was one error and that was caused by the hit counter java script. The page is almost 100% HTML 4.0 compliant on all commands except for a couple or so that are supported by IE/NS/Opera.

If you want to check yourself here you go. Sorry but there is nothing wrong with the web page that would cause the problem they are having. Mozilla STILL has rendering problems and Firebird 0.8 is using Mozilla 1.6 core. So that is why you see the same problem on both of those browsers.

Doctor HTML

And here is another site check and the results...

Site Report Card

The warnings are all missing alt tags.

As I said you are wrong.

I'll admit, I'm glad I took the time to look through it, because it isn't in the HTML exactly. Its in the CSS.

But lets deal with the html question first.

Validate from the people that write the specs - they'll help the most.

http://validator.w3.org/check?uri=http% ... +Europe%29

That will show you the non-trivial errors you have, including not having a character encoding, not escaping javascript correctly (or declaring it correctly), and using attributes that aren't allowed. (leftmargin/marginheight should be handled in css).

However, the problem is simply two lines in the css:



Its due to the fact that in the html, you are defining a container that will not fit the dimensions you are giving an element contained in it - namely the form field. (actually its much more complicated, because you are mixing fixed and relative widths, relative positioning and multiple nested tables)

If you remove both lines, in IE, Moz-1.7, and FB-0.8, it displays identically.

This is the second time I've pointed out that you had issues in html/css that were causing problems for mozilla, and were not in compliance, but you pointed at mozilla as the cause.

I'm trying to contribute and help you fix your errors. Pointing fingers at the browser when you don't understand the issue isn't helpful.

The results from the W3C validator are clear - there are non-trivial errors, and the results from that change are clear - the problem isn't Mozilla's rendering engine, its your html/css.

LOL! Sorry but it is still a failure of those browsers.

The sad thing is the W3C validator is very out of date and generates a ton of false errors and that makes it highly unreliable. It really fails horribly when it comes to any java scripting.



It died on an & and an = and shouldn't have. It also logged the l in layout on links like the above as an error. That's just one of many places it died.

The validator at W3C needs some serious work and there are far better HTML 4.0 validators out there (as I have shown you) that do not generate false positives like the W3C does. If you want to use it even though it is seriously flawed then so be it but you can't use it for justifying anything. But good try.

We're gonna have to disagree on this one.

As I said, you are placing a non-relative size inside a container that is smaller than that size, so the browser tries to determine how to lay it out.

If you remove those two lines, it looks the same in *all* browsers, so how is it not an error in your code? Better, what good are those two lines doing, since removing them maintains the look in the other browsers, and fixes it in Mozilla?

It almost seems as if you are trying to engineer the page to NOT work in Mozilla(?!).


On the contrary, it was just updated one month ago, and is updated daily! Its not failing on your javascript - you are failing to declare your javascript correctly, and failing to do character encoding properly. If you do it correctly you can have the benefits of html compliance.


No - it should have logged those errors, and it explains why! & is not an url-safe entity - they should be url-encoded. In fact, in other places in your document, you correctly handle them! They should be presented as

It even links you to a page on how to fix the issue (http://www.htmlhelp.com/tools/validator ... s.html#amp), which explains not only how to fix it (change them to , which you can do with php's urlencode() or htmlentities()), and why its a problem - & denotes the beginning of an html entity.

Even the php manual itself chimes in on the issue:


Not just the w3c saying it. Its an honest, real problem in html compliance.

The reason it chokes on your javascript is that you similarly don't create your javascript correctly.

First and foremost, javascript must be declared like so:

In order, the script TYPE is text/javascript - You don't define the script type at all - you just give it a language:


And then you fail to comment out the script itself - which means that browsers that cannot parse javascript, like lynx, google's bot, and most validators - will attempt to parse it. Simple change, big benefits.


Its not seriously flawed, nor are they false positives. Your own validators bring them up as well - just lowering their values to warnings, when they are in fact errors.

The W3c wrote the standards, they know quite well what is correct HTML and whats not. But thats really beside the point, you continue to point the finger elsewhere when I'm giving you concrete fixes for problems in your own code that will help users use your site better.. why not make the change?

No need to set a height or a width at all - if you remove those two lines, its consistent across browsers, and looks extremely similar (if not identical) to the current rendering in IE.

Mozilla and Firefox do not implement CSS style sheets properly. All container boxes, of which the form happens to be, can have a height and width set but by default the containers are set to overflow. This means that if the data inside the form container is larger than the height and width it WILL expand to show it.

IE and Opera do this as they should.

FORM is a block level element.

You have a block-level, non-replaced element in normal flow. The rules for that are listed here: http://www.w3.org/TR/REC-CSS2/visudet.html#q6.

To save time, the critical piece is:

Since your WIDTH specification exceeds the width of the containing block, you have violated the rule "The constraints must hold between the other properties".

The browser CORRECTED YOUR ERROR, and put the content outside the containing block. (Technically, its a floated replaced element, making its value equal to the element's intrinsic width, which is possible outside the containing element - by floating it).

IE and Opera show that page in quirks mode - because its not compliant, and so it works around your errors to the best of its abilities.

But this is all ignoring the primary point:

There is a fix, that doesnt break the look on any other browser, that is html and css compliant, and you are arguing over it.

If you dont want people browsing with Mozilla, just say so, but don't blame the browser - its not at fault here.

GAWD! Would you both just stop... Damn Testoserone is flowin a bit high.

Instead of pointing out flaws in each, what is the best fix so we can fix it and move on to bigger and better things

Remove these two lines in the css:

width: 140px;
height: 20px;

Thats it. Looks the same in IE as it did with the lines included, and fixes the issue in FB/Moz.