Version: (using KDE KDE 3.1) Installed from: Compiled From Sources Compiler: gcc 3.2 OS: Linux When rendering an XML page which loads an XSL stylesheet which in turn loads a JavaScript the Konqueror browser has a problem even if everything is W3C compliant. This can also be replicated by loading the relevant files from the local harddisk. There are no debug messages. How to replicate: open www.biketraveller.org with Konqueror and compare the display with a different Browser. How to download the relevant source files: All XML, XSL and JavaScripts can be downloaded in a tarball from www.biketraveller.org/dvd The filename is XML2XSL2JAVA.tar.bz2 Move the image folder inside the html folder to restore the links correctly.
there's no CSS, but XSL - and khtml doesn't know that.
Subject: Re: missing XSL support Kai True, and I should have checked first. I will modify the pages and check for the user utilising Konqueror. Please close the associated bug report and ignore that this message was send using a Redmont tool - I am working this weekend (even at 2300 hours local) and though we always generate a release of our SW for Linux (currently requiring glibc 2.2 and Kernel v. 2.4+, check http://www.kcml.com/download/download.html) our bosses are lagging behind and demand the use of alternative mail clients. Greetings from Switzerland Peter Lins Neuch
*** Bug 23673 has been marked as a duplicate of this bug. ***
*** Bug 44989 has been marked as a duplicate of this bug. ***
its a wish
burn !!
*** Bug 93754 has been marked as a duplicate of this bug. ***
*** Bug 86984 has been marked as a duplicate of this bug. ***
*** Bug 94791 has been marked as a duplicate of this bug. ***
They claim XSLT have been implemented in WebCore. Doesn't seem to be in WebCore-146 though. Maybe we will see it in a later release.
*** Bug 98627 has been marked as a duplicate of this bug. ***
Bug http://bugs.kde.org/show_bug.cgi?id=94791 has been marked as a duplicate of this bug. Its useful to note that that bug has a good description of what's wanted, namely that the xml-stylesheet processing instruction for xslt stylesheets is supported. This simply means that the page that contains this instruction should be passed through an xslt transformation before rest of the content is displayed.
Does this bug/wish include JS hooks to control XSLT transformations from script?
I think not. The JS hook would be a separate wish. Both the xml-stylesheet processing instruction and the ability to perform xsl transformations from javascript are features that are supported in Mozilla and IE. On 3/29/2005, "Manos Batsis" <manos_lists@geekologue.com> wrote: [bugs.kde.org quoted mail]
*** Bug 103218 has been marked as a duplicate of this bug. ***
XSLT is implemented in Safari 1.3 according to Dave Hyatt: http://weblogs.mozillazine.org/hyatt/archives/2005_04.html#007962
As stated above Safari 1.3 has implemented xslt through libxslt. The source code can be found either at http://www.opensource.apple.com/darwinsource/tarballs/other/ or at http://webkit.opendarwin.org/building/checkout.html. Anybody working on porting this to khtml?
No. libxslt depends on using libxml as the underlying layer. Since we don't use libxml, this path is not really available to us.
Anyone needing immediate XSLT support in konqi for their own site(s) etc should check http://goog-ajaxslt.sourceforge.net/ . It works fine in konqi and in other browsers.
libxml and libxslt are already recommended for kde, so why can't a new feature built on it?
Pazartesi 5 Aralık 2005 14:57 tarihinde, Heinrich Wendel şunları yazmıştı: [bugs.kde.org quoted mail] There is now enough man power currently. Even WebCore, JavaScriptCore changes can't be merged back because of this.
> There is now enough man power currently. Even WebCore, JavaScriptCore > changes can't be merged back because of this. s/now/not
khtml doesn't use libxml: $ ldd /usr/local/kde3/lib/libkhtml.so | grep -c xml 0 We're not about to link to it now, in order to load yet another XML parser into memory.
*** Bug 120635 has been marked as a duplicate of this bug. ***
What about, as a temporary workaround, add some kind of configuration option to specify a binary through which the current page will be piped when an <?xml-stylesheet?> directive is encountered? Users who need the XSL feature could build a little shell script around their Saxon or whatever. Konqueror would supply the binary with the URL of the current page as a parameter (or environment variable), the page on stdin and use the output on stdout as the new source code of the page.
*** Bug 130944 has been marked as a duplicate of this bug. ***
*** Bug 134937 has been marked as a duplicate of this bug. ***
*** Bug 132048 has been marked as a duplicate of this bug. ***
Wouldn't libxslt be an option for KDE 4 now that libQXml is a separate library? A reimplementation looks like a waste of resources.
Am Sonntag, 11. Februar 2007 schrieb Harri Porten: > Wouldn't libxslt be an option for KDE 4 now that libQXml is a separate > library? A reimplementation looks like a waste of resources. Didn't the konqueror devs already say that they don't want to use libxslt, as that drags in libxml and thus yet another xml library? Anyway, Frans Englich is currently develloping Patternist, which is a Qt4-based XSL-T (2.0), XPath, XQuery implementation. The homepage states that it is supposed to go directly into Qt, so once that happens, we'll have XSLT support natively. Cheers, Reinhold
*** Bug 146890 has been marked as a duplicate of this bug. ***
With the new addition of QtXmlPatterns to Qt4.4 is there any chance of Konqueror being able to parse XML documents through XSLT?
this page also applies http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml
Konqueror 4.1.2 is out now and it appears to link against libQtXml.so, libxml2.so and libexpat.so, but XPath still doesn't seem to work (I didn't try XSLT or XQuery, though). Is there any progress on this? It'd be very nice to have, especially since both Firefox and IE support it already.
there is an update from frans englich: http://englich.wordpress.com/2008/09/10/xsl-t-and-qt/ "I merged the development branch for XSL-T into our main line, heading for Qt 4.5. The idea is that Qt will carry an XSL-T 2.0 implementation" will this bring in support in konqueror too?
I'd also like to see XSLT support in Konqueror - IE, Opera, FF, Safari, everyone supports it, and it's a great way to build a website in my opinion.
*** Bug 193785 has been marked as a duplicate of this bug. ***
Some status: http://www.confuego.org/archives/24-Prototypical-XSLT-support-for-Konqueror.html
*** Bug 205720 has been marked as a duplicate of this bug. ***
*** Bug 207894 has been marked as a duplicate of this bug. ***
*** Bug 239979 has been marked as a duplicate of this bug. ***
(In reply to comment #23) > khtml doesn't use libxml: > > $ ldd /usr/local/kde3/lib/libkhtml.so | grep -c xml > 0 > > We're not about to link to it now, in order to load yet another XML parser into memory. How about creating a fork of libxslt that would link against libexpat instead?
this bug is not worth watching for another two years, especially since webkit is now going to be part of konqueror anyways.
*** Bug 270199 has been marked as a duplicate of this bug. ***
This bug prevents Konqueror users from using KHTML to easily view how members of the United States House of Representatives voted, at the official U.S. House of Representatives web site. The URI is http://clerk.house.gov/evs/2014/index.asp . If, a KHTML user clicks on a number corresponding to a roll call vote, an unparsed XML page will be displayed. This bug is also in QtWebKit 2.2.x in Qt 4.8. It was fixed in QtWebKit in the version in Qt5 and in QtWebKit 2.3.x . However, QtWebKit 2.3 is not part of a full Qt4 package and therefore is not available in distributions that have Qt4 in one package such as Slackware Linux.
(In reply to Christian Parpart from comment #43) > this bug is not worth watching for another two years, especially since > webkit is now going to be part of konqueror anyways. XSL is important. Is this fixed already?
I'd say it is since switching to QtWebEngine. Unfortunately, most of the test pages listed in this bug report or duplicated ones either don't exist anymore or have changed and don't use XSL anymore. The only bug report which gives instructions on how to reproduce the issue without relying on an external page is https://bugs.kde.org/show_bug.cgi?id=239979, and it seems to work both with WebEnginePart and WebKitPart
(In reply to Stefano Crocco from comment #47) > I'd say it is since switching to QtWebEngine. I would say there was no switch but a choice. WebKit has problems (bugs pending for years) that KHTML does not have.