Some article explains a bit more:
http://forums.mozillazine.org/viewtopic.php?f=25&t=297285 The first empty DIV closes itself with the trailing slash. This is allowed in XML (XHTML is XML), but it is not allowed in HTML. If your document (1) has an XHTML doctype declaration at the beginning of the document, (2) has the proper namespace declaration, and (3) is being served with the proper mime type by the server (application/xhtml+xml), there is no difference between those two empty DIVs. However, if you miss any of those three criteria, your document is not going to be rendered as XML, and you will not get the results you expect. With the wrong mime type sent by the server, the document will be rendered as HTML. In HTML, <div /> syntax will be read as an opening div tag, and the browser will expect a closing tag. The XHTML compatibility guidelines advise you not to use the minimized tag syntax for compatibility reasons. Even if Firefox renders your XHTML properly, older browsers that only understand HTML will choke and die on the DIV that is not properly closed in HTML. Read 4.3 and 4.6 here. -----Original Message----- From: Robby Pelssers [mailto:[email protected]] Sent: Wednesday, November 25, 2009 4:58 PM To: [email protected] Subject: RE: cocoon 3: xslt and pickup java scripts: Firebug I've seen this behavior for other tags as well... For instance with empty <div> tags In that case subsequent tags are sometimes treated as children of the empty preceding <div> tag. Kind regards, Robby -----Original Message----- From: Jos Snellings [mailto:[email protected]] Sent: Wednesday, November 25, 2009 4:51 PM To: [email protected] Subject: Re: cocoon 3: xslt and pickup java scripts: Firebug Hi ! Here is what Firebug has to tell: when an xhtml serializer is selected, this is the output: <script src="/thesaurus/js/jquery.js" type="text/javascript"/> <script src="/thesaurus/js/jquery_cookie.js" type="text/javascript"/> <script src="/thesaurus/js/jquery_treeview.js" type="text/javascript"/> <script type="text/javascript"> $(function() { $("#tree").treeview({ collapsed: true, animated: "medium", control:"#sidetreecontrol", persist: "location" }); }) </script> --------------------------------------- Firefox sees only the first javascript. By the way: in het xslt rule the script tags are: <script src="/thesaurus/js/jquery.js" type="text/javascript"></script> but these are converted to single elements <script/>, and it looks as if Firefox has a problem. ------------------------------------------------- A DOM inspection confirms this: It looks as if the subsequent script tags are regarded as sub-elements of the first script tag. I haven't tested with other browsers. Is this to be considered as an issue? Fact is that the produced xhtml is valid and *should* work. Kind regards, Jos On Wed, 2009-11-25 at 13:16 +0100, Jos Snellings wrote: > I was about to do that, it really points in the direction of firefox. > I will let you know > > > On Wed, 2009-11-25 at 12:44 +0100, Reinhard Pötz wrote: > > Jos Snellings wrote: > > > Hello ! > > > > > > I have a strange observation to share: > > > "when multiple javascripts are included in an XSLT transformation, to > > > land in the <head> of an html page, it is observed that some are never > > > fetched, by FireFox 3.5.5 (Ubuntu)." > > > > > > I clarify: exerpt 1: from sitemap, pipeline for static resources: > > > <map:pipeline type="async-caching"> > > > <map:match pattern="images/{name}.jpg"> > > > <map:read src="presentation/images/{map:name}.jpg" > > > mime-type="image/jpeg" /> > > > </map:match> > > > <map:match pattern="images/{name}.gif"> > > > <map:read src="presentation/images/{map:name}.gif" > > > mime-type="image/gif" /> > > > </map:match> > > > <map:match pattern="css/{name}.css"> > > > <map:read src="presentation/style/{map:name}.css" > > > mime-type="text/css" /> > > > </map:match> > > > <map:match pattern="css/images/{name}"> > > > <map:read src="presentation/style/images/{map:name}" > > > mime-type="image/png" /> > > > </map:match> > > > <map:match pattern="js/{name}.js"> > > > <map:read src="presentation/javascript/{map:name}.js" /> > > > </map:match> > > > > > > ---------------------------------------------------------------------------------- > > > <xsl:template match="/"> > > > <html> > > > <head> > > > <title> Herein Thesaurus </title> > > > > > > <link rel="stylesheet" type="text/css" > > > href="/thesaurus/css/herein.css"/> > > > <link rel="stylesheet" type="text/css" > > > href="/thesaurus/css/jquery_treeview.css"/> > > > > > > <script type="text/javascript" > > > src="/thesaurus/js/jquery.js"></script> > > > <script type="text/javascript" > > > src="/thesaurus/js/jquery_cookie.js"></script> > > > <script type="text/javascript" > > > src="/thesaurus/js/jquery_treeview.js"></script> > > > > > > <script type="text/javascript" > > > src="/thesaurus/js/thesaurus.js"></script> > > > > > > <script type="text/javascript"> > > > > > > $(function() { > > > $("#tree").treeview({ > > > collapsed: true, > > > animated: "medium", > > > control:"#sidetreecontrol", > > > persist: "location" > > > }); > > > }) > > > > > > </script> > > > </head> > > > --------------------------------------------------------------------------------------------------------- > > > I detailed the log to debug level for the cocoon output, and, to my > > > amazement, I find that the pipeline does not react at all: javascripts > > > jquery_treeview and jquery_cookie are never fetched. > > > > > > ---------------------------------------------------------------------------------------------------------- > > > Observation: when I place the same html under the form of a static html > > > page, all the scripts are nicely fetched. > > > > > > > > > What could be the cause of this - admittedly strange - phenomenon? > > > Anybody observed a similar test case? > > > > > > Reinhard, as you make heavy use of rich client javascripting, do you > > > know about this? > > > Am I overlooking something essential? > > > I see no reason why the result of a xslt transformation would behave > > > different, so obviously I am. > > > > This sounds like some browser caching issue. > > Have you used Firebug to track down the problem? > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
