This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
https://www.ispor.org/LogInAdmin.aspx as a sample of a page that should (I think) pass. Checking by URI fails it on "there is no attribute "bordercolor" " which is not event rendered in a view source or pasted markup. It seems like the markup being checked by URI is not the XHTML rendered by the .Net engine but maybe legacy markup. Any thoughts? Bill
This is a known bug in ASP.net. It does some browser sniffing (wrong), serves different markup based on that sniffing (wrong) and in some cases (e.g when serving to the validator), it serves invalid markup (wrong again). You can check this by switching on "show source" in the validator, and comparing this to what asp.net serves to your browser. I suggest you complain to the makers of ASP.net, and/or apply one of the configuration hacks which can be found here and there on the web, e.g.: http://weblogs.asp.net/pscott/archive/2005/04/21/403716.aspx
I don't think this is an ASP.net bug per say. I understand that is how ASP.net works. However, if the markup produced by it is valid XHTML (it is) it should validate in your tool. Just because your tool is not recognized by ASP.net does not mean the markup produced by it is invaild. You are validating markup, not frameworks. Bill You replied: This is a known bug in ASP.net. It does some browser sniffing (wrong), serves different markup based on that sniffing (wrong) and in some cases (e.g when serving to the validator), it serves invalid markup (wrong again). You can check this by switching on "show source" in the validator, and comparing this to what asp.net serves to your browser. I suggest you complain to the makers of ASP.net, and/or apply one of the configuration hacks which can be found here and there on the web, e.g.: http://weblogs.asp.net/pscott/archive/2005/04/21/403716.aspx
(In reply to comment #2) > I don't think this is an ASP.net bug per say. Call it a broken feature if you like: http://msdn2.microsoft.com/en-us/library/exc57y7e.aspx This is a FAQ, bill. Dozens of ASP.net coders before you have hit this issue, and fixed their engine to produce valid markup, even when sent to the validator. I trust you can do the same. > However, if the markup produced by it is valid XHTML (it is) it should > validate in your tool. Just because your tool is not recognized by ASP.net does > not mean the markup produced by it is invaild. You are validating markup, not > frameworks. You are contradicting yourself. Indeed, the validator just validates markup. If given invalid markup, it will mark it as invalid, without any consideration of markup. The fact that asp.net (or any other tool) sends invalid markup is not the validator's problem.
No, actually you misunderstand me. My point is that the markup returned to the browser by ASP.net is valid for the page as evidenced by the pass when direct input is used. Valid is valid, not valid only if validated by direct input. Thanks for listening. >> You are contradicting yourself. Indeed, the validator just validates markup. If given invalid markup, it will mark it as invalid, without any consideration of markup. The fact that asp.net (or any other tool) sends invalid markup is not the validator's problem.
(In reply to comment #4) > My point is that the markup returned to the > browser by ASP.net is valid for the page as evidenced by the pass when direct > input is used. it is valid, but only when it's sent to your browser, and then you copy-paste it into the validator. When asp.net sends content directly to the validator it sends something *different*, which is not valid. In other words: the content asp.net sends your browser (and which you can validate successfully) is NOT THE SAME as the content asp.net sends directly to the validator. Just "view source" in your browser, "show source" in the validator, and compare.