Form problem

I have code like below on a few of my pages. Every few months someone tells me that nothing happens when he clicks on either button (no focus issue?). Works for most people. Works fine in all browsers I have tested. Have not been able to pin down exactly where and when it fails. Last time user said he was using Chrome, though it has worked in Chrome for me.

All other code on those pages works fine even when these submits do not work.


<FORM ACTION = '/catalog/computer.htm' METHOD = 'post' TARGET = '_TOP'>
<BR>
<INPUT TYPE = 'submit' VALUE = 'I am a computer'>
</FORM>

<FORM ACTION = '/forms/human.htm' METHOD = 'post'>
<BR>
<INPUT TYPE = 'submit' VALUE = 'I am human'>
</FORM>


What am I missing here?

 

That's some mighty fine HTML 3.2 you have there... unfortunately that's likely your problem. Some UA's might also choke on those extra "spaces for nothing" around your = signs.

Though with that rubbish TARGET attribute in there, if there is a parent it could be updating that and not the viewed page. That attribute was deprecated in '98 for a reason, and the fact that it's back in HTML 5 doesn't fix the fact it's an indication of inaccessible junk coding -- in this case probably framesets?

 

It was a practice that in the mid '90's a lot of developers did to try and make the code more "legible". Typically it was the C programmers -- the types who put their { on a line all by itself -- who disliked the idea of so little whitespace.

It was deprecated / made invalid in 4 strict the same time quotes around attribute values were made mandatory, though most older UA's still support it. I know from experience that all browsers descended from Konqueror -- so Safari and Chrome-likes -- have a buggy implementation of parsing that where it just up and decides not to work willy-nilly. I've never been able to quite figure out the how/why of when it fails, I just know it SOMETIMES does.

Again, this is why 25 year old markup practices are a BAD idea. Support for them is slowly fading and/or just plan neglected.

But what do I know? I consider the mere presence of single quotes around attribute values to be an indicator that someone's not qualified to write back-end code... since the know-nothings who insist on using double-quote strings in languages like PHP seem to love vomiting up HTML that way... just so they can use the slow memory wasting inlined variables to avoid going ', variable, ' with single quotes.

 

Have you checked your website to see if there are any JavaScript error on the Page?

 

1) Did not know that single quotes would be a problem since it seems to be common that either are correct to avoid double nested quote errors. Recently discovered that square brackets in FoxPro are also legitimate quote delimiters in FoxPro, but not likely anywhere else.

2) The upper casing is a holdover from my Applesoft and FoxPro programming and did not know it could be a problem.

3) Ditto for the extra spaces around '=' etc.

4) Page is a stand alone page and not part of a frameset.

5) Page was coded about 20 years ago and works well most of the time. Around 10 complaints in 20 years about this problem, so it is not a critical issue.

6) Current issue is odd since visitor cannot get form to focus in his Chrome browser when he accesses the page from my website, but when I email him the exact same link, it works as expected. I would think that it would always work/fail regardless of source.

7) There is no javascript to gum things up.

8) Page is generated by FoxPro so it has not changed in decades.

That said, I will look into these notes to see if any of them are causing problems. If so, I will change FoxPro to correct them.