php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #56907 <a> tag cannot be self-closing in text/html document
Submitted: 2006-03-23 10:07 UTC Modified: 2006-08-23 19:40 UTC
From: pecl-bugs-2006 at ryandesign dot com Assigned: pajoye (profile)
Status: Closed Package: PECL website (PECL)
PHP Version: Irrelevant OS: Mac OS X 10.4.7 PPC
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: pecl-bugs-2006 at ryandesign dot com
New email:
PHP Version: OS:

 

 [2006-03-23 10:07 UTC] pecl-bugs-2006 at ryandesign dot com
Description:
------------
The source code of many (most? all?) pages on pecl.php.net 
contains this near the top:

<div>
 <a id="TOP" />
</div>

That's not permissible. It must read:

<div>
 <a id="TOP"></a>
</div>

Doing it your way breaks Safari, which then considers the 
<a> tag to never have been closed, and causes all normal 
text throughout the rest of the page to be inside an <a> and 
to participate in ridiculous onmouseover effects like 
turning pink when you click anywhere on the page.


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2006-06-06 15:53 UTC] dufuz@php.net
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.
 [2006-06-15 15:31 UTC] mj@php.net
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.
 [2006-08-20 11:15 UTC] mj@php.net
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.


 [2006-08-20 21:51 UTC] pecl-bugs-2006 at ryandesign dot com
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.
 [2006-08-21 07:39 UTC] pecl-bugs-2006 at ryandesign dot com
The w3c is already aware of this bug in their validator:

http://www.w3.org/Bugs/Public/show_bug.cgi?id=1500
 [2006-08-21 08:00 UTC] pecl-bugs-2006 at ryandesign dot com
The WebKit bug has also already been submitted:

http://bugzilla.opendarwin.org/show_bug.cgi?id=5771
 [2006-08-21 17:01 UTC] pajoye@php.net
The code for pecl and pearweb are available in CVS. If you like you can provide a patch, we can then commit it shortly.
 [2006-08-21 23:00 UTC] pecl-bugs-2006 at ryandesign dot com
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.
 [2006-08-23 19:40 UTC] pierre dot php at gmail dot com
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.
 
PHP Copyright © 2001-2021 The PHP Group
All rights reserved.
Last updated: Sun Nov 28 18:03:14 2021 UTC