Improved Text Editor Capability

michaelkpate · 2015-10-27 13:52:18

philwareham wrote #296247:

Any code editor (with syntax highlighting) and text formatting bar would probably have to be separate things – since no current WYSIWYG I’ve looked at fulfils both tasks satisfactorily for me.

That, I think, makes perfect sense.

As I said on the other thread before I started this one to avoid that one getting hijacked further, what I really want in a code editor is a way to format things nicer – even if it all it did was support tabs, I would be happy. Another long pet peeve of mine – I tend to move massive portions of the page code into miscellaneous forms, which means I lose access to all the handy little tag generators. But that is actually a separate problem.

For actual content, I don’t care about tabs. But the formatting bar would be nice.

NicolasGraph · 2015-10-27 14:22:16

philwareham wrote #296231:

Another consideration we need to think about is where the formatting bar would appear in the admin side. Obviously the write body textarea is a given, but there is also excerpt, and potentially any other field that accepts textile/markdown (including the custom field proposal at v4.8).

I’d be happy to be able to use textile for images captions natively.

GugUser · 2015-10-27 17:41:36

NicolasGraph wrote #296251:

I’d be happy to be able to use textile for images captions natively.

What do you mean. This depends on how you use the tags in a page or form (or macro).

NicolasGraph · 2015-10-27 17:53:03

GugUser wrote #296255:

What do you mean. This depends on how you use the tags in a page or form (or macro).

Images captions do not use textile formating; it depends on what?
I’d be happy to use textile for images captions without smd_wrap or whatever plugin. If it would be natively possible, the formating bar could also apply there…

GugUser · 2015-10-27 18:31:14

NicolasGraph wrote #296256:

It depends on what?

Maybe we have a misunderstanding. For me, Textil is principally for the final HTML output, and CSS for the formating.

NicolasGraph · 2015-10-27 19:49:48

GugUser wrote #296257:

Maybe we have a misunderstanding. For me, Textil is principally for the final HTML output, and CSS for the formating.

See text formating to know what we are talking about here.

Last edited by NicolasGraph (2015-10-27 19:50:00)

GugUser · 2015-10-27 20:14:40

NicolasGraph wrote #296258:

See text formating to know what we are talking about here.

Yes, I know. But, with Textile, for example, with *I wish this bold*, it results in a <strong> HTML tag, <strong>I wish this bold</strong>, not in a CSS style like font-weight: bold;. And that element can be styled in various manners.

The same is with an image caption. Output that text in HTML is one thing, style it an other thing. Maybe we talk about the same thing. In German and Spanish, “formatieren” and “formatear” (in Ecuadorian Spanish) means working on the appearance. I apologize if I’m wrong, but I know it for decades so, where I work myself.

Last edited by GugUser (2015-10-27 20:24:02)

jakob · 2015-10-27 21:19:04

Although a post about a markdown editor, this post shows an editor that for me strikes a good balance between providing formatting tools and visual cues for the admin user as author and keeping things simple.

It gives authors with Word toolbar experience enough of the tools they expect and the visual cues make the “cryptic” code look meaningful instead of like lost bits of punctuation. The full-screen view and image insert option round it off nicely. The real preview might not be that important, because it’s never what you really see.

Some further background reading:

Choosing a cms from the current A List Apart. I suspect, like a lot of CMSes, txp hits some buttons and misses others. The interesting bit in this context is the section on the author experience… (but made suddenly trendy by calling it AX)
Adapting ourselves to adaptive content is an older, long but entertaining article from Karen McGrane that provides plenty of food for thought about what to chunk into smaller pieces and the problem of authors faking structure with the help of formatting tools.

GugUser wrote #296260:

Maybe we talk about the same thing. In German and Spanish, “formatieren” and “formatear” (in Ecuadorian Spanish) means working on the appearance.

I think you probably are. One way or the other, there are situations where you might want to add formatting to a small field, and other situations where you might want to strip that formatting. It might be a caption, it could also be a link description, or a category/section description in the forthcoming 4.6. The second article linked above gives some arguments for not formatting small fields but it’s long and in English…

smd_wrap was partially my fault, as Stef took a long smd_macro of mine and made it into a plugin, then ran with it and made it into the swiss army knife of a plugin that it now is. Some of its most common uses could perhaps be replaced by an additional attribute for the relevant tags (e.g. also for other description fields), for example format="textile" or ="plaintext" (for stripped textile)… and "untouched" or "auto" for unchanged. At present, however, only the body and excerpt fields are pre-processed as html, but they are also (currently) the only true long-form fields.

NicolasGraph · 2015-10-27 22:33:45

GugUser wrote #296260:

Output that text in HTML is one thing, style it an other thing.

Who talked about style? I didn’t.
Of course, if I want to style the entire caption, I can use CSS. But if I want to add a link, or apply an italic style only on a word I need HTML… or Textile.

Destry · 2015-10-28 10:50:03

jakob wrote #296265:

Although a post about a markdown editor, this post shows an editor that for me strikes a good balance between providing formatting tools and visual cues for the admin user as author and keeping things simple … It gives authors with Word toolbar experience enough of the tools they expect and the visual cues make the “cryptic” code look meaningful instead of like lost bits of punctuation.

Exactly what I’ve been trying to describe all along.

I don’t care how it’s done (CodeMirror, Luck Charms, or dental floss), I’ll leave that to the experts, but the result is desirable if the code economics can be found. Other systems are doing it, so it must be possible, and they must be working by the same give and take.

The full-screen view and image insert option round it off nicely. The real preview might not be that important, because it’s never what you really see.

Yep. Btw, I forget to mention that spf_writer has a “full-screen” toggle.

jakob wrote #296265:

The second article linked above gives some arguments for not formatting small fields but it’s long and in English…

Reminds me of a world that is probably far of the radar of most people in this community, a world with a lot more money (in the millions of $$) riding on content projects, and which functions around component content management systems (CCMS) and the DITA standard. Absolute and strict separation from content and presentation. Formatting is never applied to text. Rather every input field takes raw text, metadata is applied to it, then XML transformations output different formats and constructs of the information depending on audience, language, medium, etc.

I only mention that because the DITA proponents always jump into conversations in my other circles (CSF, STC, etc) whenever the topic of peewee publishing systems like WP (and Textpattern) and their markup woes come up. Devotees/workers in/of the two camps never really see eye-to-eye, but it’s because they come from completely different worlds and have different publishing needs. Not everybody needs a million-dollar CCMS solution (but big players certainly do). Likewise, little blog engines (sorry) have their place in things too, and may have different situations for allowing (or not) formatting in other text fields besides the body and excerpt fields. Image captions, as Jakob mentioned, being a good example.

gaekwad · 2015-10-28 14:15:47

Destry wrote #296281:

DITA

Dang. That takes me back. I used to use that daily at my previous proper job – back when it was a pure IBM thing.

michaelkpate · 2015-10-28 14:17:01

jakob wrote #296265:

Choosing a cms from the current A List Apart. I suspect, like a lot of CMSes, txp hits some buttons and misses others. The interesting bit in this context is the section on the author experience… (but made suddenly trendy by calling it AX)

I thought the first comment was interesting:

I have competely given up pushing Markdown to clients. It has, without exceptions, resulted in users finding the whole CMS experience un-intuitive. Even though I can make a very good technical argument for using it. Currently I avoid defining any wysiwyg-fields whenever possible. But when styling is needed I will allow a small set of WYSIWYG buttons (bold, italic, linking, headings). For example when an author wants to add an internal link to a body text it is hugely more reliable to provide a WYSIWYG tool with the ability to browse the site structure than first teach Markdown and then teach how to form internal links. – mscore

Textpattern CMS

Textpattern CMS support forum

#61 2015-10-27 13:52:18

Re: Improved Text Editor Capability

philwareham wrote #296247:

#62 2015-10-27 14:22:16

Re: Improved Text Editor Capability

philwareham wrote #296231:

#63 2015-10-27 17:41:36

Re: Improved Text Editor Capability

NicolasGraph wrote #296251:

#64 2015-10-27 17:53:03

Re: Improved Text Editor Capability

GugUser wrote #296255:

#65 2015-10-27 18:31:14

Re: Improved Text Editor Capability

NicolasGraph wrote #296256:

#66 2015-10-27 19:49:48

Re: Improved Text Editor Capability

GugUser wrote #296257:

#67 2015-10-27 20:14:40

Re: Improved Text Editor Capability

NicolasGraph wrote #296258:

#68 2015-10-27 21:19:04

Re: Improved Text Editor Capability

GugUser wrote #296260:

#69 2015-10-27 22:33:45

Re: Improved Text Editor Capability

GugUser wrote #296260:

#70 2015-10-28 10:50:03

Re: Improved Text Editor Capability

jakob wrote #296265:

jakob wrote #296265:

#71 2015-10-28 14:15:47

Re: Improved Text Editor Capability

Destry wrote #296281:

#72 2015-10-28 14:17:01

Re: Improved Text Editor Capability

jakob wrote #296265:

Board footer