Continuing my Firefox “quality” rants: I just found the willpower to completely redesign my AJAX framework, going from IFRAMEs to jQuery AJAX calls (replacing straightforward and quite elegant XSL transformations with pages of convoluted JavaScript code) to work around the bugs in FF3.0, only to find out that FF3.5 is even worse and introduced numerous additional “features”.
For example, FF3.5 requires an explicit </script> tag within an XHTML document with proper DOCTYPE. The following document was validated with W3C XHTML validator …
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> <title>Test</title> <script src="… source URL … " type="text/javascript" /> </head> <body id="body"> </body> </html>
… but it does not load the script in FF3.5.
Before anyone starts telling me that it’s not so hard to include the closing </script> tag in your source – try telling that to the database with native XML support where I’m storing snippets of the code. I had to convert the field from XML to TEXT (and lose all XML goodies I might eventually get) just to avoid the elimination of the explicit closing tag.
May I make a quick suggestion to the FF developers: maybe, just maybe, you might want to consider supporting existing web applications in parallel with adding new features that not too many people can use (because no other browser supports them yet).
Posts
8 comments:
One trick I've used to get around self-closing tags is to put whitespace beetween the opening an closing tag. XML parsers treat whitespace as significant, but HTML browsers do not. This prevents your XML parser from automatically closing the tag for you, and makes browsers like Firefox happy.
Thanks for the workaround. I was thinking along the same lines (BTW, XML parsers might decide to drop the whitespace unless you use xml:space), but I hate to develop workaround for specific browsers, more so when the bugs are really stupidities ... not to mention that the developers of the particular browser we're discussing tout its standard compliance versus some other browsers.
FF 3.5 is only following the recommendation in the XML specification that only elements declared EMPTY should use the empty element tag (see section 3.1).
I have to say that looking through all your comments about Firefox's XSL/XML support is counter to anything I've run into so far as I am in the process of doing something similar to you, client side XSLT. Where you've complained things don't work, I find it only works in FF.
So I'm wondering if somehow your using asp stuff is causing you problems because I have, as yet, to have any issues with FF, Opera or Chrome for a relatively large e-commerce site I'm building.
Hi Rob!
I'm able to reproduce every error I've encountered with plain XML/XSLT text files, so the problems are definitely not back-end related.
It's true, though, that I'm always trying to squeeze the most out of the platforms/technologies I'm using, sometimes in quite unexpected ways. The script tag problem described above is a typical one: not many people would consider caching pre-generated XHTML document in an XML field in a relational database.
@Anonymous: thanks for the pointer to XML specs. However, you should read it carefully; it says:
"Empty-element tags may be used for any element which has no content, whether or not it is declared using the keyword EMPTY."
... which makes empty SCRIPT tag perfectly valid.
Have you filed a Bugzilla entry for this?
@Hand: No. Guilty as charged.
Seeing how the XSLT bugs are stuck in limbo for years, I am not sure that would be the best use of my time.
Post a Comment