The importance of valid HTML
The need for standards compliant HTML is documented all over the internet with the primary reason of speed and cross browser compatibility. There are, after all, reasons the standards have been created. The idea behind them is that you can take the code which is fully standards compliant and run it in any browser and it will look the same. Okay we all know that that's not actually the case, and different browser engines render things slightly differently. It's one of the main reasons why the web development community hates Internet Explorer; it seems to have its own way of doing things which is different to everyone else.
Bitching about IE aside, I came across another reason to have standards compliant code this week, and a problem I have seen previously, forgotten about and had to research again, so I am here to share the wisdom I have recently rediscovered, and also have it somewhere I can easily find it again.
I was working on some legacy code to add an enhancement to a specific area which would allow a complex form to have elements added dynamically to them based on previously selected values. The majority of these elements were check boxes, though I believe the issue would be the same for other elements. The problem I had was that although the elements were successfully being added to the screen, could be called and manipulated by jQuery and were very much visible and interactive, they were not being passed through as part of the form submit.
The elements were where they should have been within the form structure; the code to build them was from a generic builder which worked fine in other areas for a similar purpose; everything appeared to be correct, so the digging online commenced.
Turns out that this was a fairly common problem. Although the rest of the form functioned fine, and had done for years before, the structure was illegal (both in terms of standards, and I think people should be arrested for writing it like it was). Here is a very much shortened and massively anonymised version of the form:
The form would take values from field1 and / or field2 and then dynamically gather check boxes which would be displayed and available within the dynamicArea table cell. That was fine, and the check boxes would appear, as I have stated, but the check boxes would submit. It doesn't look like there would be a problem. The boxes were being added within the form tags and everything was opened and closed correctly, so what could the issue be?
As it turns out, the form tag is not valid within a table as structured in the code above. Sure the form elements which are in the code above currently - the two text fields - will submit their values, but anything added dynamically would not. The simple fix for this one is to move the open and close form tags to outside of the table structure, and everything work. As they say in the industry, it's magic. the valid code for the form above would be:
It's a very simple solution, and one very important reason why the structure and standards of HTML should be followed. The two examples of code both render identically, so there's no easy way of telling if it's valid or not from looking at the output, but the way they function is very different. Standards are there for a reason, and they should be followed in order to make maintenance and future development as easy as possible for yourself, or whoever picks it up after you.
