That's valid accourding to the w3c checker, so I think Safari is broken if anything.

IIRC you can close tags like that in HTML if you don't have any content to put in but I might be wrong on that, but heck our page even validates with XHTML 1.1, which is very strict.

I still think we should try to make live as pleasant as possible for Safari users.  Can someone with the most recent version of Safari confirm that this problem is still there?  If so, I'll look at fixing it.

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.

The problem is still observed with the current version of Safari 2.0.4 (419.3) in Mac OS X 10.4.7 and also in OmniWeb 5.5b3 which also uses Apple's WebKit.

I have researched the cause of the problem extensively today and can now say with certainty that it is the PECL web site which is in error, and the solution I provided in March should be applied, or you should serve your pages with the application/xml or application/xhtml+xml content type. Documents served as text/html (as the PECL web site is) may not self-close anchor tags, or any other tag whose content definition in the XHTML spec is not EMPTY. See this Firefox/Mozilla bug:

https://bugzilla.mozilla.org/show_bug.cgi?id=203398

See the XHTML spec, appendix C, section 3:

http://www.w3.org/TR/xhtml1/#guidelines

I'd recommend changing the anchor tag to explicitly close, not self-close, since perhaps this is problematic for Internet Explorer on Windows, and since Mozilla does not particularly recommend using application/xhtml+xml anyway:

http://www.mozilla.org/docs/web-developer/faq.html#accept

Yes, there is a slight difference in behavior between Gecko and WebKit: when Gecko encounters the opening table tag, it decides to automatically close the anchor tag which had been left open, while WebKit does not do this, which is why the problem is evident in Safari and OmniWeb and not in Firefox. Whether this constitutes a WebKit bug is open to debate, since the document is not entirely valid based on its content type, so I don't know if one can expect the browser to exhibit any specific behavior. But when the OpenDarwin web server is responding again I will check if a WebKit bug has already been entered about this.

As to the w3c validator validating the site, I will see about submitting this to the w3c validator mailing list so that they can display an error for this situation instead of giving it a pass.

The w3c is already aware of this bug in their validator:

http://www.w3.org/Bugs/Public/show_bug.cgi?id=1500

The WebKit bug has also already been submitted:

http://bugzilla.opendarwin.org/show_bug.cgi?id=5771

The code for pecl and pearweb are available in CVS. If you like you can provide a patch, we can then commit it shortly.

So they are. Thanks for the pointer. Here are the patches:

http://www.ryandesign.com/tmp/pear-7183-pearweb.patch
http://www.ryandesign.com/tmp/pear-7183-peclweb.patch

I created these by searching all files for this regular expression:

<a\s+(id|name)[^>]+/>

then correcting by hand. I have not tested the changes, because I don't know how to make these web sites function on my own server, but the changes are fairly straightforward.

This bug has been fixed in CVS.

In case this was a documentation problem, the fix will show up at the
end of next Sunday (CET) on pecl.php.net.

In case this was a pecl.php.net website problem, the change will show
up on the website in short time.
 
Thank you for the report, and for helping us make PECL better.

Thanks for the patch, commited. It will show up with the next update.