Ticket #4576 (confirmed Bug)

Opened 4 years ago

Last modified 13 months ago

CKeditor work wrong with contentType="application/xhtml+xml"

Reported by: Jura Owned by:
Priority: Normal Milestone:
Component: General Version: 3.0.1
Keywords: Cc: chris@…, tleach@…, danya_postfactum

Description

If site content served with contentType="application/xhtml+xml" CKeditor replaces some characters on special symbols.

For example: test

will be replaced in output onto: ¤es¤

i.e. 't' will be replaced on ¤

Attachments

XhtmlTest.php (2.0 KB) - added by alfonsoml 4 years ago.
Test page with XHTML header

Change History

comment:1 Changed 4 years ago by Jura

  • Keywords contentType application/xhtml+xml removed
  • Milestone CKEditor 3.x deleted

comment:2 Changed 4 years ago by garry.yao

  • Keywords Pending added

Unable to reproduce with

 <meta http-equiv="content-type" content="application/xhtml+xml; charset=utf-8" />

comment:3 Changed 4 years ago by fredck

Can you please provide a sample page to be used for testing it?

comment:4 Changed 4 years ago by Jura

To reproduce the bug your server should set HTTP Response Header: Content-Type: application/xhtml+xml; charset=UTF-8

i.e. CKeditor should be served as application/xhtml+xml HTML META tag does not set Content-Type for client browser, it is description only.

comment:5 Changed 4 years ago by alfonsoml

  • Keywords Confirmed added; Pending removed

This error happens in Opera. Both Firefox and Safari fail to create the instance if application/xhtml+xml is used, they have issues for example with document.write for the loader scripts and .innerHTML

It does require a lot of work (if possible at all) to change all the code as these problems are present just by trying to load the instance, there might be other problems while trying to use all the features.

Changed 4 years ago by alfonsoml

Test page with XHTML header

comment:6 Changed 3 years ago by Chris_Graham

  • Cc chris@… added

This is a duplicate of #2807, which was set to cantfix. But I don't think that's the case. We used to use a modified Xinha that worked fine. Instead of innerHTML, we modified Xinha to use our equivalent setInnerHTML/getInnerHTML function pair that does the work instead. It's available in themes/default/templates/JAVASCRIPT.tpl in ocPortal (http://ocportal.com/), and I'm happy to donate the code if it helps. document.write has to be avoided unless you're writing into an HTML document. Iframes are allowed in XHTML, just not in the XHTML-strict doctype - so that's just a grammar issue, not a practical execution issue. contentEditable was never an issue to us either. If the frame itself is loaded as HTML rather than XHTML I think you can probably get away with only editing a portion of your code.

comment:7 Changed 3 years ago by alfonsoml

You must understand that this is a very low priority as very few sites use real XHTML, so your best chance to see this fixed is to start working on the current problems with the knowledge that you used in Xinha and then propose here the patches that should be applied.

Obviously it's possible to create an editor based on XHTML, the problem is to keep support of all the features and browsers without breaking the things.

comment:8 Changed 3 years ago by alfonsoml

  • Cc tleach@… added

#6758 has been marked as dup.

comment:9 Changed 20 months ago by bradmac

Hey guys, I don't think this should be considered unimportant much longer. Major browsers do not correctly interpret self-closing tags in an XML'ish way without the xhtml content type, making life difficult for those of us with a CMS based product.

comment:10 Changed 15 months ago by wwalc

  • Cc danya_postfactum added

#10020 has been marked as dup

comment:11 Changed 13 months ago by j.swiderski

Accordnig to http://blog.whatwg.org/xhtml5-in-a-nutshell XML MIME type is not yet supported by the Internet Explorer 9. IE10 needs checking.

Note: See TracTickets for help on using tickets.
© 2003 – 2012 CKSource – Frederico Knabben. All rights reserved. | Terms of use | Privacy policy