4 ms·

Is this only interesting because of the desktop angle and how little code it takes with GTK/Python, or are Webkit and HTML5 making browser-based WYSIWYG editors

Is this only interesting because of the desktop angle and how little code it takes with GTK/Python, or are Webkit and HTML5 making browser-based WYSIWYG editors better somehow too?

jacobolus 17y ago
Well, if actually implemented by browsers, HTML5's contentEditable makes in-browser editors better. I’m not sure whether there are compatible implementations in all the major browsers yet... so you might not be able to rely on it for web apps.
- tdonia 17y ago
  designMode is already implemented/used by a lot of rich text editors. Usually, they have an iframe with designMode turned on, capture the code generated and then run a clean up process to fix inconsistencies. That said, it's no panacea - the current implementations are not consistent at all - the code generated in designMode by the rendering engine can become quite ugly pretty quickly. Hopefully with the HTML5 execution there will be a bit more attention and care for this as it is really useful and a core part of Tim Berners-Lee's original vision - every page, editable.
  - axod 17y ago
    designMode is absolutely horrible though. When you press enter in the edit box, some browsers add a <br> tag, some start a new <p> tag, etc etc. It's a complete mess. Also the API is ridiculous. editableDocument.execCommand("Bold", false, null); execCommand? seriously?
    - olavk 17y ago
      I wrote an article for Opera about designMode and contentEditable: http://dev.opera.com/articles/view/rich-html-editing-in-the-browser-part-1/ http://dev.opera.com/articles/view/rich-html-editing-in-the-... You are right it is messy. The API as apparently modelled over the IOleCommandTarget which is a Microsoft API for document-toolbar integration. They probably never expected it to become a cross-platform standard.
      - axod 17y ago
        Thanks, useful article. I hope one day they standardize that stuff into a usable DOM API.
    - euroclydon 17y ago
      Yeah, I just assumed I was missing something. document.execCommand() has an invisible argument that is the selected rendered HTML???
cturner 17y ago
I thought it was interesting for this reason. At the moment we have a lot of documentation systems which are suitable for distributed teams to use. An organisation with several sites and teams spread across locations and timezones will tend to use a wiki. But wikis are not fabulous for the editing experience. They're OK, but users keep steering towards Microsoft Word because they like the desktop-feel editing experience far more. Alas, Word sucks because it only runs on Windows, it's expensive, it's lock-in, it uses pessimistic locking (if a user has it open, another can't open it to edit - fabulous when your colleague leaves it open over a weekend), and because its formatting is too flexible. Word documents degrade to the level of your least competent staff member. These libraries appear to offer a decent foundation for writing a desktop-oriented rich text editor that gives a Word-like editing experience but which mandates styles and integrates with an arbitrary remote system and stuff like that. That's what I saw in it, anyway. I had a go at such a project about a month ago using wxpython and the rich text component in that, and it isn't the right tool for the job - the component is too monoithic and it's impractical to limit functionality, or to extract the content. It's inelegant that it outputs to HTML rather than a pure document format like docbook, but it's probably close enough to be good enough.

Is this only interesting because of the desktop angle and how little code it takes with GTK/Python, or are Webkit and HTML5 making browser-based WYSIWYG editors better somehow too?

jacobolus 17y ago

Well, if actually implemented by browsers, HTML5's contentEditable makes in-browser editors better. I’m not sure whether there are compatible implementations in all the major browsers yet... so you might not be able to rely on it for web apps.

tdonia 17y ago
designMode is already implemented/used by a lot of rich text editors. Usually, they have an iframe with designMode turned on, capture the code generated and then run a clean up process to fix inconsistencies. That said, it's no panacea - the current implementations are not consistent at all - the code generated in designMode by the rendering engine can become quite ugly pretty quickly. Hopefully with the HTML5 execution there will be a bit more attention and care for this as it is really useful and a core part of Tim Berners-Lee's original vision - every page, editable.
- axod 17y ago
  designMode is absolutely horrible though. When you press enter in the edit box, some browsers add a <br> tag, some start a new <p> tag, etc etc. It's a complete mess. Also the API is ridiculous. editableDocument.execCommand("Bold", false, null); execCommand? seriously?
  - olavk 17y ago
    I wrote an article for Opera about designMode and contentEditable: http://dev.opera.com/articles/view/rich-html-editing-in-the-browser-part-1/ http://dev.opera.com/articles/view/rich-html-editing-in-the-... You are right it is messy. The API as apparently modelled over the IOleCommandTarget which is a Microsoft API for document-toolbar integration. They probably never expected it to become a cross-platform standard.
    - axod 17y ago
      Thanks, useful article. I hope one day they standardize that stuff into a usable DOM API.
  - euroclydon 17y ago
    Yeah, I just assumed I was missing something. document.execCommand() has an invisible argument that is the selected rendered HTML???

cturner 17y ago

I thought it was interesting for this reason. At the moment we have a lot of documentation systems which are suitable for distributed teams to use. An organisation with several sites and teams spread across locations and timezones will tend to use a wiki. But wikis are not fabulous for the editing experience. They're OK, but users keep steering towards Microsoft Word because they like the desktop-feel editing experience far more. Alas, Word sucks because it only runs on Windows, it's expensive, it's lock-in, it uses pessimistic locking (if a user has it open, another can't open it to edit - fabulous when your colleague leaves it open over a weekend), and because its formatting is too flexible. Word documents degrade to the level of your least competent staff member. These libraries appear to offer a decent foundation for writing a desktop-oriented rich text editor that gives a Word-like editing experience but which mandates styles and integrates with an arbitrary remote system and stuff like that. That's what I saw in it, anyway. I had a go at such a project about a month ago using wxpython and the rich text component in that, and it isn't the right tool for the job - the component is too monoithic and it's impractical to limit functionality, or to extract the content. It's inelegant that it outputs to HTML rather than a pure document format like docbook, but it's probably close enough to be good enough.