Problem with TinyMCE in Chrome

[Joss]

There are a growing number of JQuery HTML5 editors out there that are worth looking at.

Aloha has already been mentioned and the Developer is really up for getting it into other systems and can be pretty helpful.

Redactor is nice, but it is not free.

wysihtml5 is a straight forward choice and there is a version for Bootstrap that would be interesting if the admin was using Boostrap.

Mercury is an amazing editor, but would need a bit of thought as visually it works as a top browser bar. It works on rails, but can be used without at well.

There are a lot of others out there.

I think it depends what you want, really. If you are using textarea fields and only want very basic formatting, then these JQuery editors are very good indeed.

But, if you want all singing and dancing, which is fine for a personal site, then CK and TinyMCE are still the ones.

Offering a selection would certainly be useful!

joss

[antknight]

This is $%^&ing me off

[Soma]

Calm down, it happens in other iframe based editor too. Annoying that Chrome didn't fix it yet.

[alan]

I've *never* seen what antknight screeh-shotted there and Chrome is my go-to browser. Is it because I use OS X maybe?

antknight, if you use OS X too, have you tried using Canary to see if it's fixed there perhaps?

[onjegolders]

I've *never* seen what antknight screeh-shotted there and Chrome is my go-to browser. Is it because I use OS X maybe?

antknight, if you use OS X too, have you tried using Canary to see if it's fixed there perhaps?

Hi Alan, I get it Chrome for OS X too

[antknight]

Tried Canary, still does it

[alan]

[diogo]

[quotamos]Calm down, it happens in other iframe based editor too.[/quotamos]

But some "other" iframe based editor has already a nice solution http://ckeditor.com/demo#div

[mindplay.dk]

Doesn't just happen in editors either - it's a general problem with iframes. I guess transparent updates are both good and bad? I just hope they fix this soon...

[Joss]

Hi Mindplay

I have long been thinking about a new kind of WYSIWYG editor based on structured snippets, rather than raw markup. I.

With an HTML5/Jquery WYSIWYG editor, I suppose it would not be too hard to replace the normal buttons entirely, and just have exactly what you are suggesting.

I suppose you could sort of test your concept with TinyMCE.

Remove all the buttons and only have "styleselect"

Then create a pile of styles.

I know that isn't snippets, but it might give an idea of what it is like to work in that way.

Going the JQuery/HTML5 editor route actually kills two birds with one lump of code - it would be nice to see one integrated into PW anyway.

One thing about snippets is that I think it is important to see what is happening. So, if for instance a snippet is creating a text block, in the editor, it should show a dotted border (even if the final does not have one), so you can see what the constraints are.

Also, everything should be artificially padded so it is easy to select within them.

But none of that is difficult - just slight style variations for the editor version of the snippet.

Joss

[mindplay.dk]

I actually did attempt to build something, twice, last time a few years ago.

My first attempt was based on lightweight WYSIWYG with very limited capabilities, e.g. h1-h6/bold/italic/links, not much else. It had drag-and-drop reordering of the sections, and a "template" drop-down for each section. It was not much use in practice.

My second attempt was based on Markdown, which can be processed on both client and server-side. This had a single, floating (semi-transparent) form for the Markdown, and would render the HTML in the background, on the fly. It would detect placeholders on the Markdown content - so if you entered "{photo}", for example, a "photo" item would show up on a list of all the placeholders in the content. You would then click on a placeholder in that list to edit it, and you could then substitute it with, say, an image, a table, or some other piece of content - each type of content would have it's own editor. I loved that idea, but clients don't understand Markdown, or don't like it.

Content-editable is now fairly ubiquitous, so I think something in between those two ideas would soon be feasible - a very simple, lightweight, in-place editor with basic formatting, draggable sections and containers and so forth, some of which would have custom UI for uploading images, populating tables, etc.

I'm sure it's not a small can of worms to open up though.

[mindplay.dk]

Sounds like the bug has been fixed in Chrome, and we're just waiting for an updated release now.

http://code.google.com/p/chromium/issues/detail?id=143354

[mindplay.dk]

Still thinking about starting a template-based content editor...

First thing required for something like that would be a template engine for the actual templates, that works on both the client (JS) and server side (PHP).

I poked around and see two options that look viable:

Twig for PHP and the TwigJS port for Javascript.

Mustache for PHP and the Javascript port.

I guess Twig is more of a traditional template engine style, where logic is placed in the templates - whereas Mustache is simpler but has less functionality and almost no syntax, but any moderately complex logic has to be implemented in the view-model itself, which may not be suitable for this. Users in general may be more comfortable with a more traditional template engine, anyhow.

I've never used either Mustache or Twig myself, so... thoughts?

Know any other engines with both PHP and JS implementations?

[Pete]

Lemonstand optionally uses Twig (PHP by default like PW but nowhere near as simple as PW ) and from what I saw it looks pretty straightforward so that would be the one I'd go for.

That's my limited experience/input

[mindplay.dk]

I was leaning towards Twig, so I took a closer look - I'm not sure what the status of TwigJS is, and I wrote and asked the author. But I don't see any of the standard filters, functions, etc. in the codebase, which looks very, very small...

Perhaps Mustache does have what is needed - essentially, a simple JSON view-dictionary gets mapped to a view, which may be enough for simple templates, which may be all that is required for a template-based article editor. Perhaps more complex functionality could (or should) be running exclusively on the server-side anyway, in order to guarantee that it's consistent. There are after all things we can't do on the client-side - for example, uploading and resizing an image has to involve the server-side. Mainly, the point of re-rendering the templates on the client-side is for performance, so that they can be re-rendered in real-time while editing the content/data.

The simplicity of Mustache is also appealing in terms of learning curve - developers won't use this, if it involves a lot of proprietary syntax, I think. It has to be easy to set up and must be able to integrate with just about anything. Even if it uses templates and real-time client-side rendering while editing, the eventual output must be HTML, same as if you were using a traditional WYSIWYG editor...

[mindplay.dk]

Here's another option, JSON-template - this has Javascript, PHP and other implementations. It doesn't look like these implementations have seen much maintenance in the past couple of years though. (?)

[apeisa]

Not sure I follow this very well, but why not use pure html & css? You could use data-attributes to hold additional metadata that is required.

[mindplay.dk]

Not sure I follow this very well, but why not use pure html & css? You could use data-attributes to hold additional metadata that is required.

Separation of markup (design) and content - something you do not normally get from a WYSIWYG.

So, for example, you might have a template called "paragraph with zoomable image" which would have an input for the content, an input for an image file, and a text-input for an image description. It might render the image with a zoom-button, nice framing, and the image description, and have the paragraph content float neatly around it. Today, your site may use a particular template and markup for that - next year, when your site is redesigned, the markup may change and existing articles can be re-rendered.

Same goes if you discover a bug in the markup of a template - all your articles can be re-rendered.

For comparison, imagine you discovered your WYSIWYG is generating bad table or image markup. Not easy to back-fix when all of your articles have their content baked into markup. Or imagine you decide articles should use h2-tags instead of h1-tags for the article headline. The arguments for micro-templating in articles essentially are the same as for templating in general - separation of content and markup.

[mindplay.dk]

Author of TwigJS confirms that it is, quote, "full of bugs"

JSON-template doesn't look viable, and after thinking more about Mustache, I don't think that will work - it doesn't support any kind of manipulation or filtering of the content it outputs, only via lambdas, which would need to be implemented consistently on both the client and server-side, but besides the content passed to a lambda, it doesn't look like you can actually pass arguments to those, so not much use.

Not sure where to go from here...

[mindplay.dk]

I came across this article, which highlights a number of issues with Joomla - it still seems to me that the root cause of most of these issues is WYSIWYG, and that basically any CMS suffers from many of the same issues.

I quickly jotted down some notes here which captures in more detail what I've been trying to say in this thread...

[ryan]

Good points in your notes. I wrote a somewhat related article several years ago, some of which might still be relevant (and some not). I think HTML is totally fine for an editor as long as it's used as just markup, and not style. I mean basic things like, this is a headline, this is a list item, this is a blockquote, etc. That means essentially using it within the same limitations as an LML, but with the Word-like interface that clients refuse to do without. This is how we've got TinyMCE configured by default ... not so impressive to look at, but also not too dangerous. It's when you start getting into "this should be this size" and "that should be this color", and so on (style), that it becomes a problem… at least for anything scalable. And the issue with wysiwygs like TinyMCE and CKEditor is that they do both. So you have to put a lot of restraints upon it. But the temptation of eye candy, impressing the client, and giving in to their demands can make the broad capabilities of these editors a curse. Companies even win project contracts by these capabilities because they are such eye candy… "You'll be able to edit your web site just like you edit your Word docs" is an unfortunate selling point. The fact that you can do some fancy (but ultimately not so good) things with it means that the danger is always there. Joomla has obviously crossed the line here. But you are right, the big picture is that it's the nature of wysiwyg and not Joomla. I would prefer an editor that had less grey area. 

[apeisa]

My only gripe with current editors are image placement. Many times that cannot be avoided or predefined.

[diogo]

I know this is not why you posted this here, but just wanted to make a comment on that article you linked to. On the article it sounds like all the fault of the terrible things that happens to websites after they are delivered are from the client, when it couldn't be farther from the truth. You can't give a box full of tools to someone, and tell them to use only the hammer.

here you have this nice toolbox, there is this super shiny saw, and all these fancy screwdrivers with lots of shapes, but pleeeeeease make sure you only use the hammer. I had a lot of work with this, and I don't want you to ruin everything, ok?

[mindplay.dk]

You can't give a box full of tools to someone, and tell them to use only the hammer.

That's the point!

Moreover, you don't give a hammer to a 2-year old and let him loose on your furniture

Or to use another analogy, we're currently giving the client a full workshop, when maybe all he needs is a couple of tools.

"With great power comes great responsibility", and so on - your clients probably aren't web designers or web developers, if they were, they wouldn't need you.

And I would add to this growing list of arguments: WYSIWYG is probably the most common component in any and all CMS - it's the one tool that the client (most commonly) uses to edit the majority of the content on their sites. What I mean is, the majority of user-managed content in any CMS, is probably input via WYSIWYG. Yet, it's one of the most neglected features of any CMS - for the most part, we just pick an existing WYSIWYG and drop it in, with some configuration, or some minimal CMS-specific extensions for uploading/images, etc.

I think we can do better than this?

@ryan I skimmed through your article, and basically, it looks like you've had many of the same thoughts I'm having.

WYSIWYG has been around for so long, it's hard to challenge it. WYSIWYM failed. Markdown (et al) found other niche uses, but couldn't replace WYSIWYG either. I have attempted at least 3 different things in the past, none of which were adequate. I can't seem to let the idea go though - there must be a better way.

By the way, the idea I'm hatching is actually a variety of WYSIWYG - I'm not saying a content editor shouldn't show you what you get, I definitely think it needs to do that, for clients to understand and connect with what they're creating. I'm saying a content editor can be richer, more structured, and more user-friendly - it should be able to drive meaningful decisions, produce beautiful, consistent output, and, well, all the shit you don't get from an HTML WYSIWYG

[ryan]

By the way, the idea I'm hatching is actually a variety of WYSIWYG - I'm not saying a content editor shouldn't show you what you get, I definitely think it needs to do that, for clients to understand and connect with what they're creating. I'm saying a content editor can be richer, more structured, and more user-friendly - it should be able to drive meaningful decisions, produce beautiful, consistent output, and, well, all the shit you don't get from an HTML WYSIWYG 

Not sure what all this entails in terms of tangible things, but I'd love to see this.