Bug 55420 - missing XSL support
Summary: missing XSL support
Status: RESOLVED FIXED
Alias: None
Product: konqueror
Classification: Applications
Component: khtml xml (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR wishlist
Target Milestone: ---
Assignee: Konqueror Developers
URL:
Keywords:
: 23673 44989 86984 93754 94791 98627 103218 120635 130944 132048 134937 146890 193785 205720 207894 239979 270199 (view as bug list)
Depends on:
Blocks:
 
Reported: 2003-03-02 16:16 UTC by Pete Lions
Modified: 2022-03-28 20:12 UTC (History)
20 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Pete Lions 2003-03-02 16:16:55 UTC
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.
Comment 1 Kai Lahmann 2003-06-14 20:15:52 UTC
there's no CSS, but XSL - and khtml doesn't know that. 
Comment 2 Pete Lions 2003-06-14 23:23:38 UTC
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
Comment 3 Kai Lahmann 2003-06-15 01:37:26 UTC
*** Bug 23673 has been marked as a duplicate of this bug. ***
Comment 4 Kai Lahmann 2003-06-15 02:26:13 UTC
*** Bug 44989 has been marked as a duplicate of this bug. ***
Comment 5 Dirk Mueller 2003-11-02 18:48:51 UTC
its a wish
Comment 6 Colinet Sylvain 2004-11-17 00:38:03 UTC
burn !!
Comment 7 Stephan Kulow 2004-11-23 12:00:54 UTC
*** Bug 93754 has been marked as a duplicate of this bug. ***
Comment 8 Allan Sandfeld 2004-12-09 02:15:59 UTC
*** Bug 86984 has been marked as a duplicate of this bug. ***
Comment 9 Allan Sandfeld 2004-12-10 13:26:48 UTC
*** Bug 94791 has been marked as a duplicate of this bug. ***
Comment 10 Allan Sandfeld 2004-12-16 14:08:02 UTC
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.
Comment 11 Maksim Orlovich 2005-02-05 17:47:25 UTC
*** Bug 98627 has been marked as a duplicate of this bug. ***
Comment 12 Jos van den Oever 2005-03-29 13:39:42 UTC
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.
Comment 13 Manos Batsis 2005-03-29 14:08:51 UTC
Does this bug/wish include JS hooks to control XSLT transformations from script? 
Comment 14 Jos van den Oever 2005-03-29 15:49:44 UTC
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]
Comment 15 Michael Jahn 2005-04-24 14:51:08 UTC
*** Bug 103218 has been marked as a duplicate of this bug. ***
Comment 16 Michael Jahn 2005-04-24 15:05:31 UTC
XSLT is implemented in Safari 1.3 according to Dave Hyatt:

http://weblogs.mozillazine.org/hyatt/archives/2005_04.html#007962
Comment 17 Heinrich Wendel 2005-12-05 13:09:59 UTC
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?
Comment 18 Allan Sandfeld 2005-12-05 13:50:05 UTC
No. libxslt depends on using libxml as the underlying layer. Since we don't use libxml, this path is not really available to us.
Comment 19 Ismail Donmez 2005-12-05 13:53:42 UTC
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.
Comment 20 Heinrich Wendel 2005-12-05 13:57:53 UTC
libxml and libxslt are already recommended for kde, so why can't a new feature built on it?
Comment 21 Ismail Donmez 2005-12-05 14:00:34 UTC
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.
Comment 22 Ismail Donmez 2005-12-05 14:02:41 UTC
> There is now enough man power currently. Even WebCore, JavaScriptCore
> changes can't be merged back because of this.


s/now/not
Comment 23 Thiago Macieira 2005-12-05 23:59:32 UTC
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.
Comment 24 Maksim Orlovich 2006-01-23 15:38:27 UTC
*** Bug 120635 has been marked as a duplicate of this bug. ***
Comment 25 Tim Weber 2006-06-22 00:58:06 UTC
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.
Comment 26 Maksim Orlovich 2006-07-17 03:05:18 UTC
*** Bug 130944 has been marked as a duplicate of this bug. ***
Comment 27 Maksim Orlovich 2006-10-01 06:29:53 UTC
*** Bug 134937 has been marked as a duplicate of this bug. ***
Comment 28 Maksim Orlovich 2006-10-01 14:08:35 UTC
*** Bug 132048 has been marked as a duplicate of this bug. ***
Comment 29 Harri Porten 2007-02-11 19:26:07 UTC
Wouldn't libxslt be an option for KDE 4 now that libQXml is a separate library? A reimplementation looks like a waste of resources.
Comment 30 Reinhold Kainhofer 2007-02-11 20:12:37 UTC
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
Comment 31 Maksim Orlovich 2007-06-17 18:37:42 UTC
*** Bug 146890 has been marked as a duplicate of this bug. ***
Comment 32 Matt Williams 2008-04-19 18:33:55 UTC
With the new addition of QtXmlPatterns to Qt4.4 is there any chance of Konqueror being able to parse XML documents through XSLT?
Comment 33 mario tuling 2008-06-29 19:19:58 UTC
this page also applies
http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml
Comment 34 Neil Skrypuch 2008-10-11 23:48:32 UTC
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.
Comment 35 Alberto Villa 2009-02-07 04:44:46 UTC
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?
Comment 36 Unknown 2009-04-22 13:21:44 UTC
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.
Comment 37 Maksim Orlovich 2009-05-23 18:43:19 UTC
*** Bug 193785 has been marked as a duplicate of this bug. ***
Comment 39 Maksim Orlovich 2009-08-31 00:39:38 UTC
*** Bug 205720 has been marked as a duplicate of this bug. ***
Comment 40 Maksim Orlovich 2009-09-19 18:39:15 UTC
*** Bug 207894 has been marked as a duplicate of this bug. ***
Comment 41 Maksim Orlovich 2010-05-29 17:48:52 UTC
*** Bug 239979 has been marked as a duplicate of this bug. ***
Comment 42 Christopher Yeleighton 2010-05-31 14:05:13 UTC
(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?
Comment 43 Christian Parpart 2010-07-26 14:05:27 UTC
this bug is not worth watching for another two years, especially since webkit is now going to be part of konqueror anyways.
Comment 44 Tommi Tervo 2011-04-06 07:46:47 UTC
*** Bug 270199 has been marked as a duplicate of this bug. ***
Comment 45 Ronald Buckman 2014-02-23 04:00:14 UTC
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.
Comment 46 genghiskhan 2022-03-27 11:32:20 UTC
(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?
Comment 47 Stefano Crocco 2022-03-27 12:05:01 UTC
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
Comment 48 Christopher Yeleighton 2022-03-28 20:12:54 UTC
(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.