| Summary: | Xforms support in Konqueror/khtml | ||
|---|---|---|---|
| Product: | [Applications] konqueror | Reporter: | eric |
| Component: | khtml | Assignee: | Konqueror Developers <konq-bugs> |
| Status: | RESOLVED UNMAINTAINED | ||
| Severity: | wishlist | CC: | pookey, porter235, robburns1, theo |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | openSUSE | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
|
Description
eric
2004-06-24 21:55:35 UTC
A little FYI: http://www.w3.org/MarkUp/Forms/ Mozilla just starts to announce their work on it a bit bigger :) From the looks of it WhatWG thinks XForms is a webserver technology and WebForms will be the browser part. Well they have no idea what they are talking about then ;) XForms is most certianly a browser client technology. If you would like any clarification of that, read the specification at http://www.w3.org/MarkUp/Forms/. (as posted in comment #1) Yes, but it's a technology that is very depend on being implemented in both the server and the client. Therefor it can make sense to proxy it.. If this method wins then browsers wont actually have to implement it as such. Btw. did I mention that XForms is most horrible interdepending standard I've ever seen? Sorry, i do not understand why it depends on being implemented on server side any more than current HTML forms do? Just because the Web Forms 2.0 guys think what XForms should be implemented server side, it doesn't mean that the rest of the world does. processing XForms server side is a hack, full stop. :) consider the case of XML data islands, or other client side web applications. In these cases, there may be no "server" other than to post XML to and from, as the application may well use XML and XSLT for form rendering while the server purely understands XML or any other arbitary data format. web browsers are not just used for browsing the web you know, dispite their name ... just because opera don't want to add xforms to their product, it doesn't mean konq should, does it? (which is what the entire web forms thing is about, anyway) and yes, i do know the xforms spec well :) I hope the issue of implementing XForms will get more serious consideration than some of the above comments imply. First, XForms follows best practice standards by clearly separating model-view-and controller. It also finally rationalizes the separation between client/desktop and server: something impossible with existing HTML forms This reduces superfluous communication between client and server and creates a better experience for end-users. It does accomplish all this in a way that depends on existing impelemented standards. One commenter posted that XForms is the "most horrible interdepending standard" ever seen. Well It depends on XML, HTTP, XPath, XML Schema Definnition, XEvents and other W3C standards. Most of these are already supported or will receive widespread support in the near-term. Which specific dependncies in XForms are a problem? Why would KHTML want to eschew these dependent standards? As for WhatWG, they do not seem to have any substantive proposals. Instead they largely amount to a tutorial for using existing forms and in their advocacy against XForms act as a generator of FUD on adoption of improved W3C standards. Dear user, KHTML (and KJS) was a long time more or less unmaintained and got removed in KF6. Please migrate to use a QWebEngine based HTML component. We will do no further fixes or improvements to the KF5 branches of these components beside important security fixes. For security issues, please see: https://kde.org/info/security/ Sorry that we did not fix this issue during the life-time of KHTML. Greetings Christoph Cullmann |