From the W3C document on XSLT I see the XSLT is a language designed to transform XML documents. This seems to be a tutoral and nexus for XSLT.

From Apple’s Safari FAQ I see that Safari can perform XSLT transformations only on pages that include the XSLT program. Their example shows that the program may be included by reference but that doesn’t help. This site names several browsers as supporting XLTS but does not clarify what it means to have such support.

A security aspect of this is that when we cause a page to be presented with our additional notations, it might be necessary to make clear that this is not the original page. An expectation has arisen, or web theorists think that there is an expectation that the URL at the top of the browser window identifies the real author of the page. Such issues may cause browser builders to hesitate installing XSLT function in a way that could violate this expectation. This might account for the difficulty in figuring out where to install the code we want to write. This problem afflicted the Crit Suite project that was designed to allow one to find comments by others on a particular web page with attendant annotations.

Tyler Close says that in Firefox the XSLT feature to fetch an XML value (or an html web page by extension) via the web is limited to fetching documents from the same domain that the requesting XSLT program was fetched. This limitation seems to preclude a plan of executing XPath function in the browser of the user. Perhaps this is the reason for the limitation. If so there may be a fix, but not a quick fix.

It seems feasible to run XSLT on a server and do the transformations there. I do not know what the performance characteristics of XSLT are and this plan does not scale well.