WYSIWYG editors like TinyMCE, or alternatives

Bloke · 2015-07-01 10:22:14

Looking at integrating TinyMCE or equivalent into a project (custom code, not Textpattern, sadly) for building product descriptions. I’d prefer a markup system, but I’ve been overruled as the user base are “familiar” with the awful HTML that things like TinyMCE traditionally spit out.

Haven’t used it in years. Has it improved in recent revisions and can it play nicely with stylesheets and classes, or does it still insist on adding inline style rules? For example, can it be configured to apply class="relaxed" to paragraphs or lists when you use the ‘centre justify’ button, instead of adding style="text-align:center;" to the elements directly?

If so, is it easy to configure it to work with classes? Presumably there’s some config system on instantiation that governs what tools are shown and what each does. The docs aren’t that enlightening as far as I can make out. Can the admin-side preview (as you create the markup) read my style rules if they’re included in the page, so it can render the display as close as possible to how it’s going to look on the public site? Or am I stuck with one of the built-in themes for the editor textarea itself?

Failing that, are there alternative WYSIWYG (ish) systems I should consider which do work with stylesheets? Any recommendations? Thanks in advance.

EDIT: Oh, and as a side note, is there any tool that’ll strip crappy inline styles from previous versions of TinyMCE HTML output so I can import the existing product description HTML without the extra cruft and re-mark them up with the classes upon save? There are online tools that do things to varying levels of success, but they only handle one file at a time. We have 55000 products to do. Maybe I should just find/write a bash script to blitz the DB column that contains the HTML using a regex!

EDIT 2: I got excited at the name of this plugin, but it just appears to add support for using markdown-style tags in your textarea. I notice there’s also a BBCode plugin, Quite why you’d want to include a markup helper inside a WYSIWYG editing tool is beyond me, but perhaps it just adds flexibility. Presumably it’s not beyond the realms of possibility to write a Textile plugin too, or to configure the textpattern plugin to recognise Textile shortcuts. Hmmm…

Last edited by Bloke (2015-07-01 10:34:06)

philwareham · 2015-07-01 11:11:32

Howz about this or if you are feeling brave this

Bloke · 2015-07-01 11:27:06

Interesting, thanks. I like the look of Markitup, but others here are not impressed because the editing and preview are separate steps. Honestly, I quite like that separation (and it can auto-update) but unless it can be configured to preview in-place I don’t think management’ll go for it.

Alloy is a different approach again. Unobtrusive, which I think is neat, taking up no additional screen estate. And drag ‘n drop image support is a boon. I’ll tinker and see how customisable it is.

In the meantime, if anyone has any other recommendations (or examples of where you’ve tweaked an off-the-shelf tool like Markitup / TinyMCE to do something brilliant) it’d be greatly appreciated, thanks.

gaekwad · 2015-07-01 12:27:30

ckeditor.com

Bloke · 2015-07-01 12:56:28

Of all the three presented so far, CKEditor tentatively seems to tick all the boxes. Gonna play with it now, thanks.

gaekwad · 2015-07-01 12:58:41

See also: textpattern.org/plugins/1160/joh_admin_ckeditor

Last edited by gaekwad (2015-07-01 12:58:54)

jakob · 2015-07-01 13:17:12

What about a half-way house variant: textile markup with something like rah_textile_bar in combination with syntax highlighting.

Last time I asked about this, I started looking at similar things based on markdown like hallojs or sofish … and I think there were some other ones too. With an edit area of the kind seen in siteleaf or stackedit, you might be able to get people to write good markup and understand it’s effect without needing an HTML “preview” that doesn’t relate to the actual output.

Bloke · 2015-07-01 13:50:08

jakob wrote #292440:

What about a half-way house variant

See, I’m with you there totally. Sadly, trying to convince the “but it doesn’t look like Microsoft Word so nobody will understand how to do it” people at the top is like trying to tell Michael Bay that story is more important then explosions.

I like some of those resources you linked to, thank you. StackEdit’s linked pane approach is neat (and I like the way it degrades on small screens). I do question the mechanism for insertion in places. If I click the bullet icon for example, it opens up a bullet list for typing. But if I selected three rows of text separated by line breaks, and then hit the button I’d expect it to create a bulleted list out of them. Instead it drops me to the next line ready for me to create my list. Not very helpful, but that’s their design decision.

Editing in place on the front side for authorised users is also something I’d like to explore, but the way the pages are built up means content comes from many fields, interspersed with static text and markup. This ain’t no proper CMS, it’s custom-code-tastic. That means it might be confusing to have elements of the page editable while other parts are not, and I don’t know how to then “save” that content back to the DB in a suitable manner. Think: page built up from about thirty custom fields and you won’t be far wrong.

I’d dearly love to have the DB store two versions of content: one raw with markup and one rendered HTML like we do in Txp. The Chief says that’s a waste of space, which is a fair comment when dealing with 50K+ products on an already bursting server.

I don’t think Markdown or Textile is that hard to learn when supported by a suitable toolbar, but I fear I’ll lose that battle. Ultimately, it comes down to me making recommendations and them saying “but it’s not like what we already have”. So I’m kind of trying to find something that resembles a traditional Word-style WYSIWYG editor, but which allows more creative freedom over what markup is actually generated behind the scenes so we have greater control at tweaking layout through CSS. Maintaining the current product line-up with inline styles created by thirty different people is head-bangingly irritating.

Zanza · 2015-07-01 15:43:18

For what it matters, I’d like to see Alloyeditor implemented as a plugin. I’m using msd_minibar, and that’s fine for me, but clients consistently want to see the direct effect of their action, not the underlying code. :( It’s an already lost battle, I fear.

jakob · 2015-07-01 16:14:38

This ain’t no proper CMS, it’s custom-code-tastic

My apologies, I oversaw that this isn’t a textpattern project.

FWIW, I’d make a decision based on the extent of formatting you think they will really need for only the fields that need it – usually long-form content.

gaekwad · 2015-07-01 16:32:38

Bloke wrote #292442:

See, I’m with you there totally. Sadly, trying to convince the “but it doesn’t look like Microsoft Word so nobody will understand how to do it” people at the top is like trying to tell Michael Bay that story is more important then explosions.

Most people don’t care about Textpattern, the same why George Bush didn’t care about black people. Most people don’t know Textile, nor do they care about learning it. I’ve spent a few days consulting for a local electrician’s office and it’s been eye-opening to work in a field when tech should get the job done and not present any challenges.

mrdale · 2015-07-01 21:33:50

I have to jump in and say… why would any casual site editor want or need to be introduced to markup. Imagine the following scenario…

You’re doing a site editing orientation for a customer and you come to editing content part of the discussion, would you rather say…

Ok, here’s the fun bit. You get to learn and remember an arcane proxy language to format bold, italics, make headers make links, make lists. Here’s a cheat sheet, print it out and put it next to your screen. or…
OK, just type text in here and style it like you would in any application you have ever used to produce text.

Seriously? What are the compelling benefits to #1 and all the many, many, many times you’re going to have to explain it.

In my time with TinyMCE installed on sites I’ve only seen a few issues that relate to people cutting and pasting content from Word or the Web.

That being said, I’m all for simplicity and clean content markup, so a wywiwyg editor should be able to do that at this point. Front side editing is also something I’ve lusted after for years.

Bloke · 2015-07-01 23:25:05

mrdale wrote #292464:

why would any casual site editor want or need to be introduced to markup.

I hear ya. I can totally see why casual business users won’t mess with markup and prefer the heady days of Word Processors with their interminable button bars (now converted to badly laid out ribbon bars that are responsible for a steady stream of swear words as the tool you want is not where you want it). But…

just type text in here and style it like you would in any application you have ever used to produce text.

Yeah, simple on the surface, but sidestepping the fact that every editor does things slightly differently, lest we forget those are the bad old days too. I spent years in industry fighting this exact kind of crap. Why? Because invariably somewhere down the line the company would change hands or rebrand and all documents would need to be revisited and renewed. Fresh logo. Fresh font style. Fresh corporate voice with 4cm margins, no more, no less say the Marketing department.

I’d visit the corporate shared drive where some 4000 such documents exist and load up the first one — a technical manual in Microsoft Word — that needs reformatting to the shiny new spec. This is where I find the author has:

helpfully bolded segments by highlighting them with the mouse and hitting B on the toolbar. Internally, Word stores that as an inline style against the selected text.
wanted to use a fixed-width font for indicating some command input. So every time, they’ve highlighted the command and used the Font dropdown to change to Console, or used the Format Painter to “copy” the style over. Behind the scenes, it dutifully does that: copies them. As in, multiple instances of the same thing.
wanted spacing above the first paragraph of every section so they highlighted the first paragraph and changed the lead-in to 6pt. Or maybe 8pt sometimes. Occasionally 4pt because they forgot the size they used the week before.

And so it goes on. Unpicking these documents and reformatting them takes HOURS per doc. Microsoft introduced Styles in Word ’97 to get round the problem, allowing you to define a style and apply it anywhere you want with a pair of keystrokes or clicks. Styles can be based on styles (i.e. cascading) and the whole thing was utterly simple and, dare I say it, sensible. To change a document format, just like separating data from display on the web, requires only changing the Style definitions in use. Yet to this day only about 1% of users actively employ them (my estimate). Why? Because the damn button bar is there, wooing them with its one-click ease. Cliiiick meeeee. Cliiiiiiiiiick meeeeeeee.

This is what I call The Hidden Cost of Content and I’ve been trying to teach people about Styles in Word for nearly two decades. Very few get it.

Now, a markup system like Textile doesn’t get you away from this because it’s still employing inline markup that may or may not be desirable. Adding classes helps, but it’s more typing, more to remember.

That’s why I want to find a middle ground. A WYSIWYG editor that allows me complete control to add styles and classes behind the scenes, NOT inline style rules. When users make a bulleted list I want it to be <ul class="features">. When they centre text I want it to render Content here. When bolding I want Content here to be spat out. Yahde yahde.

Then the tool becomes truly useful: no markup system, and a familiar buttony interface, with the benefit that future style changes can be made in one place: the Stylesheet.

Oh document Nirvana, where art thou? Looks like CKEditor is closest so far.

mrdale · 2015-07-01 23:58:25

Sure… I get that. I’ve scraped a million documents of all their crap markup, but…

I think the real issue is to design the site environment well enough, separating content from presentation cleanly enough so that your styles work for basic html tags. Then simply don’t allow editors to do silly things by not using the kitchen sink version of the plugin.

When I set up a site with tinyMCE I only allow h1-h6, p, blockquote, em, strong ul, li and provide a measn for an inline image.

Like I said 90% of the time I get pretty clean markup, because I’ve reduced choices pretty intelligently. When a customer of mine asks why can’t I have fruity text I say because it’ll make the design look ugly.

In your scenario, highlighting text that has been bolded, wouldn’t it be better and cleaner to use css for your style rules instead of adding inline css to the content directly… that way when someone else down the road wants to use content they see it semantically. eg…

<p>I am <strong>highlighted</strong> in <em>some</em> crazy way</p>

instead of

<p>I am <span class="highlight">highlighted</span> in <span class="fruity">some</span> crazy way</p>

Personally I find the latter far less portable and universal, and actually a little guilty of the same kind of thing that Microsoft Word Disco Writer Edition is guilty of.

But maybe I’m mistaken.

Bloke · 2015-07-02 00:03:52

mrdale wrote #292468:

I am highlighted in some crazy way...

instead of

I am highlighted in some crazy way...

Yeah, crap example on my part, sorry. I’d use  and  too. They’re waaaaaay better than  and  any day as they’re less specific and can thus be marked up in more ways without confusing everyone when the tag doesn’t match up with its implementation. Semantics and all that.

Had to debug a site once where they’d used .left as a class name, but someone had changed the site layout during a redesign and made the rule definition contain float: right. Argh! That was the day I swore to never use non-semantic names for my classes.

EDIT: Just been reading up on BEM actually. Wordy syntax, but interesting idea. Seems to fly in the face of reuse so you have to be very careful to only apply it to places where the element or modifier can only occur inside the given block. Still not sold on the idea overall. I mean, who can say that the block container I design for the site now won’t have its parts bust out to different containers in a future iteration? Then the rules break and you need to start again. Having low-specificity from the get-go gives most flexibility at the expense of not gleaning document hierarchy from CSS class names. But my argument is… why should it? Seems like in doing so you’re back tying presentation to display again. Hmmmm. But I digress.

Last edited by Bloke (2015-07-02 00:10:17)

Textpattern CMS

Textpattern CMS support forum

#1 2015-07-01 10:22:14