Report new bug | New search | Development Roadmap Status: Open | Feedback | All

Bug #7183 <a> tag cannot be self-closing in text/html document
Submitted: 2006-03-23 15:07 UTC
From: pecl-bugs-2006 at ryandesign dot com Assigned: pajoye
Status: Closed Package: Web Site
PHP Version: Irrelevant OS: Mac OS X 10.4.7 PPC
Roadmaps: (Not assigned)    
Subscription  


 [2006-03-23 15: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:
That's not permissible. It must read:
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.

Comments

 [2006-06-06 19:53 UTC] dufuz (Helgi ├×ormar)
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 19:31 UTC] mj (Martin Jansen)
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 15:15 UTC] mj (Martin Jansen)
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-21 01: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 11: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 12: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 21:01 UTC] pajoye (Pierre-Alain Joye)
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-22 03: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 23:40 UTC] pajoye
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.