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 checked for a similar bug. I see comment about fragment reporting, but all of those show the source has valid broken fragments.) If you run the CGI verison (or my local Linux 4.2.1 version w some patches) on this example page http://www.amd.com/us-en/Weblets/0,,7832_11104_11105,00.html Get the same result. Shows 3 broken fragments. (not just list 3 found fragments) But if click on the fragments on the CGI results screen, the link works (it is a link#frag). I have checked the source. (you can view source as well) Seems to be a reptative error. Please advise. Is this an error. If yes, any idea what is happening during the broken $f check.
The target document for the fragments, http://www.amd.com/us-en/Weblets/0,,7832_11104_11106,00.html , has a XHTML doctype declaration which causes the link checker to parse the document in XML mode, which is case sensitive. The target document uses quite a few uppercase tag names, also in the "consumer" case: <A name="consumer"></a> "A" is not a valid XHTML element, and therefore the no anchors are searched within its attributes. Changing "<A" to "<a" could work around this particular problem, but the document source looks like it could use more thorough XHTML fixes (eg. starting with lowercasing a lot of things) to prevent other future surprises.