New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HTML editor breaks XHTML content while auto-converting to HTML #31

Closed
brevilo opened this Issue Feb 25, 2014 · 11 comments

Comments

Projects
None yet
3 participants
@brevilo

brevilo commented Feb 25, 2014

XHTML is listed among the seemingly supported file types and is set to be editable by the HTML editor by default. However, as soon as I open a standard XHTML file in 1.7.4 on OS X it get's auto-converted to HTML. In fact, the editor comments out the XML declaration, strips the DOCTYPE declaration and it even strips the HTML, HEAD and BODY tags, leaving behind a rather incomplete HTML fragment. Is that intentional?

Example: the following...

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
 <title>XHTML 1.0 Strict Example</title>
 </head>
 <body>
 <p>Hello World!</p>
 </body>
</html>

... gets transformed into (empty lines are in the original output!):

<!--?xml version="1.0" encoding="UTF-8" ?-->



 <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
 <title>XHTML 1.0 Strict Example</title>


 <p>Hello World!</p>



Upon saving the HTML viewer returns the following error:

This page contains the following errors:

error on line 12 at column 1: Extra content at the end of the document
Below is a rendering of the page up to the first error.

XHTML 1.0 Strict Example Hello World!

Ideally, the HTML editor shouldn't convert XHTML to HTML at all. If that isn't possible it should at least return something that can still be digested by the HTML viewer ;-)

Thanks

@uggrock

This comment has been minimized.

Show comment
Hide comment
@uggrock

uggrock Feb 26, 2014

Member

What we have in tagspaces is not a pure xhtml editor. If you need a xhtml editor you can switch to editorText for xhtml files in the options, which is not wysiwyg but a pure source code editor, based on codemirror.

Member

uggrock commented Feb 26, 2014

What we have in tagspaces is not a pure xhtml editor. If you need a xhtml editor you can switch to editorText for xhtml files in the options, which is not wysiwyg but a pure source code editor, based on codemirror.

@brevilo

This comment has been minimized.

Show comment
Hide comment
@brevilo

brevilo Feb 26, 2014

You are

I am?


As I said in the description, ideally it should support WYSIWYG for XHTML as well. In case that's not feasible the HTML editor should at least do the conversion right, given that it's currently set as the default editor for XHTML.

FYI, in the example above I just opened and saved the XHTML file - no editing whatsoever...

So, this issue is partially meant as a bug report but also partially as an enhancement request.

Cheers

brevilo commented Feb 26, 2014

You are

I am?


As I said in the description, ideally it should support WYSIWYG for XHTML as well. In case that's not feasible the HTML editor should at least do the conversion right, given that it's currently set as the default editor for XHTML.

FYI, in the example above I just opened and saved the XHTML file - no editing whatsoever...

So, this issue is partially meant as a bug report but also partially as an enhancement request.

Cheers

@uggrock

This comment has been minimized.

Show comment
Hide comment
@uggrock

uggrock Feb 26, 2014

Member

Please ignore "You are" it was for another topic ...

BTW, thank you for your interest in TagSpaces !

Member

uggrock commented Feb 26, 2014

Please ignore "You are" it was for another topic ...

BTW, thank you for your interest in TagSpaces !

@brevilo

This comment has been minimized.

Show comment
Hide comment
@brevilo

brevilo Feb 26, 2014

Sure, np. I really like it so far! It will hopefully replace Evernote eventually (can't wait for WebDAV over HTTPS support!).

brevilo commented Feb 26, 2014

Sure, np. I really like it so far! It will hopefully replace Evernote eventually (can't wait for WebDAV over HTTPS support!).

@uggrock

This comment has been minimized.

Show comment
Hide comment
@uggrock

uggrock Feb 26, 2014

Member

For the html editor I am using https://github.com/HackerWins/summernote , which has a sleek UI and works nice in some basic usecase, but is also a little unstable ... In particular it has some issue with the way node-webkit saves files ... And it was for sure not build as a xhtml editor ...

Member

uggrock commented Feb 26, 2014

For the html editor I am using https://github.com/HackerWins/summernote , which has a sleek UI and works nice in some basic usecase, but is also a little unstable ... In particular it has some issue with the way node-webkit saves files ... And it was for sure not build as a xhtml editor ...

@uggrock

This comment has been minimized.

Show comment
Hide comment
@uggrock

uggrock Feb 26, 2014

Member

What is your usecase for the webdav support, If you need files to be synced between devices, you can still use dropbox, owncloud or bittorrentsync, which are all working nice with tagspaces ... ?

Member

uggrock commented Feb 26, 2014

What is your usecase for the webdav support, If you need files to be synced between devices, you can still use dropbox, owncloud or bittorrentsync, which are all working nice with tagspaces ... ?

@brevilo

This comment has been minimized.

Show comment
Hide comment
@brevilo

brevilo Feb 26, 2014

I'm already using an external WebDAV sync client (Dropbox and bittorrentsync don't use WebDAV). It would just be ideal to have WebDAV directly integrated to get rid of that external dependency. If you need to rely on such an external tool, you need to find one that supports all the OS that TagSpaces nowadays supports. WebDAV is the common denominator (standard) in terms of cloud data synchronisation that's supported by most private hosting companies and not tied to a particular service provider like Dropbox - a very important selling point for people concerned about privacy.

FYI, we might get off topic here. Shall we move this to a dedicated issue?

brevilo commented Feb 26, 2014

I'm already using an external WebDAV sync client (Dropbox and bittorrentsync don't use WebDAV). It would just be ideal to have WebDAV directly integrated to get rid of that external dependency. If you need to rely on such an external tool, you need to find one that supports all the OS that TagSpaces nowadays supports. WebDAV is the common denominator (standard) in terms of cloud data synchronisation that's supported by most private hosting companies and not tied to a particular service provider like Dropbox - a very important selling point for people concerned about privacy.

FYI, we might get off topic here. Shall we move this to a dedicated issue?

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Feb 27, 2014

Collaborator

the implementation of the html editor in 1.7.5, works only with the body tag of the html/xhtml document. So now you should be able to have a proper xhtml output. The only question if everything produced in summernote is xml/xhtml conform...

Collaborator

ghost commented Feb 27, 2014

the implementation of the html editor in 1.7.5, works only with the body tag of the html/xhtml document. So now you should be able to have a proper xhtml output. The only question if everything produced in summernote is xml/xhtml conform...

@brevilo

This comment has been minimized.

Show comment
Hide comment
@brevilo

brevilo Feb 28, 2014

Ok, the good news is: editing XHTML content as HTML (using .html as file suffix/type) now works in principle as the content itself is retained. However, the editor converts singular XHTML tags like <br /> into their HTML equivalent <br> which is invalid XHTML. This isn't a problem as long as such a file is interpreted as HTML. As soon as you interpret it as XHTML though, this will be reported as an error. So, the default editor for XHTML shouldn't be the HTML editor as it eventually introduces invalid XHTML tags such that the XHTML viewer will complain.

Bottom line:

  • keep the HTML editor/viewer for HTML files
  • keep the XHTML viewer for XHTML files
  • use the plain text editor for XHTML files

I'll file an enhancement request with the summernote project and let them know about the XHTML incompatibility.

brevilo commented Feb 28, 2014

Ok, the good news is: editing XHTML content as HTML (using .html as file suffix/type) now works in principle as the content itself is retained. However, the editor converts singular XHTML tags like <br /> into their HTML equivalent <br> which is invalid XHTML. This isn't a problem as long as such a file is interpreted as HTML. As soon as you interpret it as XHTML though, this will be reported as an error. So, the default editor for XHTML shouldn't be the HTML editor as it eventually introduces invalid XHTML tags such that the XHTML viewer will complain.

Bottom line:

  • keep the HTML editor/viewer for HTML files
  • keep the XHTML viewer for XHTML files
  • use the plain text editor for XHTML files

I'll file an enhancement request with the summernote project and let them know about the XHTML incompatibility.

@brevilo

This comment has been minimized.

Show comment
Hide comment
@brevilo

brevilo Feb 28, 2014

Speaking of upstream issues: the HTML/XHTML editor doesn't add any line breaks, say, after </p>, </div>, <br> or <hr> tags for instance. That makes the generated code hard to read in code view. It's also interesting to see that, e.g., <br> tags added by the WYSIWYG editor get enclosed in <div> (HTML editor) or <p> (XHTML editor) tags. This should be improved. Is this something you can do or does this have to be done upstream at summernote?

brevilo commented Feb 28, 2014

Speaking of upstream issues: the HTML/XHTML editor doesn't add any line breaks, say, after </p>, </div>, <br> or <hr> tags for instance. That makes the generated code hard to read in code view. It's also interesting to see that, e.g., <br> tags added by the WYSIWYG editor get enclosed in <div> (HTML editor) or <p> (XHTML editor) tags. This should be improved. Is this something you can do or does this have to be done upstream at summernote?

@uggrock

This comment has been minimized.

Show comment
Hide comment
@uggrock

uggrock Nov 30, 2014

Member

The requested features should be reported to summernote...

Member

uggrock commented Nov 30, 2014

The requested features should be reported to summernote...

@uggrock uggrock closed this Nov 30, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment