COBOLdinosaur

I am not sure the problem is directly related to the php. The validator throws 14 errors including invalid tag endings and duplicate ids. So you probably want to spend the effort getting the markup right. That may or may not solve the problem, but as long as you have those errors the page is not stable, and with such a weak doctype as xhtml transitional, it is not going to be very reliable.

Structurally the form is already inside the div. I don't see code for the click event that is supposed to fire it, but unless there is some kind of class change, the div is going to return to its original state and assume the same commputed values it atarted with as soon as the event ends. If you want two stages, you will probably need two events; but the actual problem is not apparent because that code looks to be incomplete as there is nothing firing the event.

Yes just use block elements with a CSS property of float:left and they will position that way, assuming that the specific width you give them can fit in the available space. The width must be specified for the floats to work.

Cd&

That is called favicon. You addit to your pages this way:

<link rel="shortcut icon" type="image/x-icon" href="../images/favicon.ico"/>

You just need to create image you want to use and name it favicon.ico

Without the markup, the CSS could be doing anything. It would be easier to do a diognostic if you post the link to the page.

If you are using a free host then they are probably framing the site ti insert ads. instead of using the url to validate. Copy your code and then use the direct input option of the validator a paste your code in the textatra.

You already have it in xmlhttp.responseText

If you want to use it in further scripted processing then just move it to a variable and proceed from there.

Then it is the abudance of errors that have made it impossible for the browser to comprehend what it is that you expect it to render.

If the div is floated, position absolute, or position:fixed, then it would be outside of the normal flow and it parent (in this case the body) would not respond as if the div is contained within it.

However the most like cause is the markup itself. The validator reports 222 errors and a number of them are serious structural defects:

http://validator.w3.org/check?uri=http%3A%2F%2Fyaragalla.blogspot.in%2F&charset=%28detect+automatically%29&doctype=Inline&group=0

I suggest you try fixing the structural errors, so that you at least have a valid stable platform to work on.

You need clear:both for the table. The float on the nav bar continues to apply untile you explicitly end it by using clear both on a following element.

It pushes way out to the right because you do not have a width or max-width specified for the body.

Going to HTML5 will still give backward compatibility for the most part, but when you validate, you will get errors and/orwarnings about depeciated, obsolete, or modified tags/attributes. Those can be corrected over time and converting the local obsolete attributes to CSS replacements will generally be transparent. You should get rid of the obsolete/depreciated attributes not just to make maintenance easier, but also for efficiancy. When a modrtn browser encounters an obsolete attribute, it has to execute extra code to convert it to CSS, as the older attributes are no longer understood by the rendering engines or the renderObjects that need to fire for paint operations.

BTW, if you have not fixed the errors because it looks like too much work, I wonder why you are making so much additional work during both development and maintenance) by using all the inline styles instead of rationalizing the sytling and using a stylesheet.

Browsers have to parse the code and the code to do that is unique to each browser. They find the same errors as the validators. There is a myth that browsers ignore errors. The fact is that for every error they have to execute extra code during parsing to do serialization to the specifications. No doctype makes it even worse because that puts some browsers in quirks mode and they follow a different set of rules for parsing and rendering, even without quirks mode there is no guarantee that all browsers are going to use the same default doctype. The bottom line is that when there are errors the page will fail at some point in one or more browsers because the parsing engine quessed wrong and the rendering engine cannot resolve what it finds during the layout and initial paint steps; so it just puts out what it can.

In extreme, but rare cases the build up of errors is such that parsing results in code that that will generate an uncausght exception when it is referenced by the renderObject of the affected element. That will crash or hang the browser.

Not validating, or ignoring validation errors is a certain path to failure at some point, and the longer it is ignored the more work it is to fix; plus trying to use diagnostic tools on a page that badly malformed is not going to yield and helpful information.

That sort of looks like a question, but there is so little information it it that I do not know what you want. You might find if you give some detail and explain what you need, that people try to help. But do not assume we know anything about your problem, the context it is in, and the technologies you are using, because we can only go by what you tell us. In other words we cannot see into your mind to determine what you are thinking

Let me see if I understand this. You wrote smoe code that didn't work the way you wanted it to so instead of fixing it and finding what was causing the problem you decided to try hacking away with an invalid structure that also does not work so now you are looking for a way to get the hack to work instead of looking for a solution for the valid code that does not work.

This is a strange planet.

If you need alternate code for ie8 then use the microsoft hack... oops workaround:

<!--[if lt IE 9]>	<sript src="Whatever-hack-you-need.js"></script>	<![endif]-->

Then you just load a script or alternate stylesheet to override the code that works for modern browsers.

The first step in trying to get third party code to work is to open a problem ticket with the vendor. If the vendor is not providing the support, then you have a theme that should be discarded. If a vendor is not willing to support their product, then you need to look elsewhere for third party code.

Without a link to the site, there is no way of knowing if the problem is solvable. Most of the time with these things there is load time scripting to set styles that is almost impossible to get around. It is poor design to modify styles that way, but most of the themes do not anticipate that a developer might want to do something outside the normal limits of their software.

When you put part of the markup outside of the body, you should probably not expect them to act like they are part of the page in all browsers. I suggest you use a valid structure as a starting point. There is no point trying to debug code when such obvious errors exist.

Opera, and especially Opera Mini are well be hind in compliance o the standards. The best you can do is find workarounds and polyfills for the things that don't work. The best source for that informations is http://html5please.com/ where you can get the latest cross-browser support information and the best available workarounds for lame browsers.

If you want to enhance or actually enhance the image you could create an alternate version of it with the enhancement and the then use the alternate version in a swap, but you would need to use javascript for that. You could also highlight bu increasing the dimensions and bringing it forward with a z-index value.

The nav will not set margins to auto based on that code because you have not specified a width. The browser cannot calculate the values for the margins unles it has a width specified that it can use in the calculation. Plus the position absolute overrides everything to do with position and is just aboute the worst posible property to use on a page that you want to be responsive.

It is possible that the height is being constrained by its parent element. Without a more complete structure which would be available if you posted a lin, it is not possible to do a detailed diagnostic.

Yeah the tutorials recommendd by ingolme are a start. However HTML is not a programming language. It is just a markup to define the structure of a page. If you are going to do web pages you won't be able to do much with just HTML except very static and plain pages. You will also want to learn CSS, and probably javascript. You will also need to understand somw server side language to do anything really useful.