Subject: [xsl] Guidelines for client-side XSLT (WAS Re: [xsl] XSL 2.0 and .NET and VB)|
From: "Manfred Staudinger" <manfred.staudinger@xxxxxxxxx>
Date: Sat, 30 Jun 2007 01:31:39 +0200
On Fri, 29 Jun 2007 14:16:16 -0600, Jirka Kosek <jirka@xxxxxxxx> wrote:Agreed.
> I don't think that current browsers are able to incrementally display > page which was generated client-side from XML using XSLT. You have to > wait till XML is downloaded and DOM is constructed, then you have to > wait till XSLT transforms DOM into another DOM and only after that you > can see something rendered. For slower connections this could be very > annoying.
Sorry, Jirka, but you haven't show any evidence that suggests its slower to render a document via XSLT than it is using the SGML parser, just that you seem to think that the process of parsing the XML and XSLT to then process the XML with the XSLT is somehow going to result in slower processing of the page.
Is this correct? If yes, then I'm sorry, but you are wrong.
Please read through my entire post again and recognize the fact that I specifically made mention to that fact that this is only 50% of the total solution.
Agreed again. However, AFAIK we have no repository or Wiki, where Jirka and others can lookup reliably how to do it. Instead, rumors are used as a base for design decisions (see above). To give you an example:
whether or not that client supports XSLT. In the case of Google, I would send them a prerendered (or potentially dynamically rendered) HTML file.
Google is perfectly happy with XML, it uses the text for indexing and the anchor elements to find other pages, maybe XML again. Same with Yahoo, only MSN does not spider XML, but this will come soon I think.
If you could propose a place for such a factual base about client-side XSLT, I would be happy to contribute.