This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
I came to the site in an attempt to see if I could clean up some of my code. When I submitted the URL for your checker to go to, it resulted in showing HTML source code that did not contain any of the resulting HTML that would have been generated by my server after all PHP processes would have completed, thus spitting out straight HTML. Is there some way around this that I am not aware of or is this something that is not possible due to the fact that your checker is incapable of parsing the post-processed PHP file? Thanks Adrian Brooks
It is likely that your script expects some HTTP headers the Validator does not send, for example, the User-Agent header does not contain the string "Mozilla" as it would for most browsers. Other than that there is no difference between a browser loading your web site and the Validator doing it, so this can't be a bug in the Validator.
(In reply to comment #1) > It is likely that your script expects some HTTP headers the Validator does not > send, for example, the User-Agent header does not contain the string "Mozilla" > as it would for most browsers. Other than that there is no difference between a > browser loading your web site and the Validator doing it, so this can't be a > bug in the Validator. Wouldn't it be safe to assume though, that all necessary headers are pre- processed at my server before the file being checked as a URL submission is fully parsed for validation. See, the source code that I viewed in the validator's results is completely missing an entire array of <option> form elements that are present post- processing. Also, the validator is suggesting that the respective closing </select> tag is not present as well, and yet that is a static inclusion in the actual file, not even PHP generated, so this is where my suspicion begins to wonder whether this may actually be the result of some form of a bug. I tried it in both the current version of the checker and the new, beta version and the new beta version did yield only one failed validation, as opposed to the 26 the current one had yielded. Thanks for the reply, btw. ~Adrian
Yes, what I'm saying is that you have a bug in your script that generates correct output for some user agents and incorrect output for other user agents such as the Validator. The Validator can only process what the web server returns, and what the web server returns is totally up to the web server.
(In reply to comment #2) > See, the source code that I viewed in the validator's results is completely > missing an entire array of <option> form elements that are present post- > processing. The validator is only showing the source it received. If, for some reason, your server did not send the same document it serves e.g browsers, it's your server's faul, not the validator's. > Also, the validator is suggesting that the respective closing > </select> tag is not present as well You probably misread the validator's error here (although, since you are not giving a URI, it's hard to tell). Most likely the validator said "there should be a </select> here and there isn't". This is very different. > I tried it in both the current version of the checker and the new, beta > version and the new beta version did yield only one failed validation, as > opposed to the 26 the current one had yielded. The difference in error numbers can have many causes, very likely irrelevant to your bug report. Just check whether both versions show the same source when you check the "show source box.
(In reply to comment #4) > (In reply to comment #2) > > See, the source code that I viewed in the validator's results is completely > > missing an entire array of <option> form elements that are present post- > > processing. > The validator is only showing the source it received. If, for some reason, your server did not send the > same document it serves e.g browsers, it's your server's faul, not the validator's. > > Also, the validator is suggesting that the respective closing > > </select> tag is not present as well > You probably misread the validator's error here (although, since you are not giving a URI, it's hard to > tell). Most likely the validator said "there should be a </select> here and there isn't". This is very > different. > > I tried it in both the current version of the checker and the new, beta > > version and the new beta version did yield only one failed validation, as > > opposed to the 26 the current one had yielded. > The difference in error numbers can have many causes, very likely irrelevant to your bug report. Just > check whether both versions show the same source when you check the "show source box. Ok...I can't even begin to appologize for this...upon reading your replies, it just dawned on me that what I was supplying for my URI to the validator was missing something extremely important. Now, after modifying it to include some missing GET data...it only returns with a unclosed <tr> error. Original URL submitted: http://www.goth-greetings.com/categories.php Correct URL submission: http://www.goth-greetings.com/categories.php?destination=14 20 years as a programmer and you would think I would be able to have seen that. Sheesh. Any idea what the error that is resulting is caused by though? Sincerely appologetic, ~Adrian
Well, you have 129: <tr valign="top"> 130: </tr> which lacks a <td> or <th> element which is required for table rows. It seems you should remove the empty row.
Adrian, no worry, it happens :) Closing.
(In reply to comment #7) > Adrian, no worry, it happens :) > Closing. Yeah, I was just looking over my php code to see why its not producing that. the <td>'s are dynamically produced in the php as a result of a php browser detection class I am using to provide the proper output for NS or MSIE. So, thats on my end also. Thanks for all your patience and take care now. ~Adrian