WYSIWYG editors like TinyMCE, or alternatives

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)

mrdale · 2015-07-02 00:40:41

Yeah I really try to take the power out of editors hands,who will inevitably break style in horrendous ways if they have the option. And we’re not even talking about sloppy markup. I would not want them telling me more about “what type of content it is, because categories, sections, status custom fields can do all of that.

In general you want styles to be consistent, but specifically via context have variations.

In my experience If you put enough information about the kind of content you’re presenting in the containing div, you can style different areas of your site, different contexts and different categories, etc, differently by using descendant selectors.

So you may end up with:

<txp:article>
  <txp:variable name="article_type"> 
    <txp:if_article_list>list<txp:else/>individual</txp:if_article_list>
    <txp:wet_if_sticky>sticky<txp:else/>live</txp:wet_if_sticky>
    <txp:rvm_if_priveledged>verified<txp:else/>unverified<txp:rvm_if_priveledged>
    <txp:if_first_article>first<txp:else/>
       <txp:if_last_article>last<txp:else/>following<txp:if_last_aricle>
    </txp:if_first_article>
  </txp:variable>

  <div class="<txp:variable name='article_type'/>"> 
    <h2><txp:title/><h2>
    <txp:body />
    <aside><txp:excerpt /></aside>
  </div>
</txp:article>

I’m sure a lot of people do this, but it allows for a great deal of contextual styling, and you’ve actually taken the burden of styling out of your editors hands.

whaoh… I think I’m way off topic.

joebaich · 2015-07-02 02:41:43

gaekwad wrote #292461:

Most people don’t care about Textpattern, the same why George Bush didn’t care about black people.

So most people DO care about Textpattern, is that your contention? Please don’t respond, it’s a rhetorical comment on my part.

That aside, I do like the promise of Imperavi Redactor. One needs to be skeptical about continued development and support of any OS projects so I note that it’s most recent update was 5 days ago, so far so good.

Last edited by joebaich (2015-07-02 02:50:03)

gaekwad · 2015-07-02 13:55:46

joebaich wrote #292475:

So most people DO care about Textpattern, is that your contention? Please don’t respond, it’s a rhetorical comment on my part.

Oh, Joe – don’t leave me hanging like this. I’m the white Kanye, I think that’s what it must be.

That aside, I do like the promise of Imperavi Redactor. One needs to be skeptical about continued development and support of any OS projects so I note that it’s most recent update was 5 days ago, so far so good.

Oh, that’s nice – great find!

Last edited by gaekwad (2015-07-02 13:55:59)

hcgtv · 2015-07-02 20:12:39

Was hanging out at the FluxBB forums and came across WysiBB, a very light BBCode toolbar. I downloaded it, it uses jQuery, which we already have in our install.

The code looks very clean and could be easily adapted to provide an end user Textile toolbar for writing articles.

I’m old hat at Textile, but for a new user, a toolbar would be a nice improvement.

Textpattern CMS

Textpattern CMS support forum

#13 2015-07-01 23:25:05

Re: WYSIWYG editors like TinyMCE, or alternatives

mrdale wrote #292464:

#14 2015-07-01 23:58:25

Re: WYSIWYG editors like TinyMCE, or alternatives

#15 2015-07-02 00:03:52

Re: WYSIWYG editors like TinyMCE, or alternatives

mrdale wrote #292468:

#16 2015-07-02 00:40:41

Re: WYSIWYG editors like TinyMCE, or alternatives

#17 2015-07-02 02:41:43

Re: WYSIWYG editors like TinyMCE, or alternatives

gaekwad wrote #292461:

#18 2015-07-02 13:55:46

Re: WYSIWYG editors like TinyMCE, or alternatives

joebaich wrote #292475:

#19 2015-07-02 20:12:39

Re: WYSIWYG editors like TinyMCE, or alternatives

Board footer