Go to main content

Textpattern CMS support forum

You are not logged in. Register | Login | Help

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

michaelkpate
Moderator
From: Avon Park, FL
Registered: 2004-02-24
Posts: 1,323
Website

Re: Improved Text Editor Capability

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.

Offline

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

NicolasGraph
Plugin Author
From: France
Registered: 2008-07-24
Posts: 860
Website

Re: Improved Text Editor Capability

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.


Nicolas
Follow me on Twitter and GitHub!
Multiple edits are usually to correct my frenglish…

Offline

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

GugUser
Member
From: Quito (Ecuador)
Registered: 2007-12-16
Posts: 1,429

Re: Improved Text Editor Capability

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).

Offline

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

NicolasGraph
Plugin Author
From: France
Registered: 2008-07-24
Posts: 860
Website

Re: Improved Text Editor Capability

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…


Nicolas
Follow me on Twitter and GitHub!
Multiple edits are usually to correct my frenglish…

Offline

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

GugUser
Member
From: Quito (Ecuador)
Registered: 2007-12-16
Posts: 1,429

Re: Improved Text Editor Capability

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.

Offline

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

NicolasGraph
Plugin Author
From: France
Registered: 2008-07-24
Posts: 860
Website

Re: Improved Text Editor Capability

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)


Nicolas
Follow me on Twitter and GitHub!
Multiple edits are usually to correct my frenglish…

Offline

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

GugUser
Member
From: Quito (Ecuador)
Registered: 2007-12-16
Posts: 1,429

Re: Improved Text Editor Capability

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)

Offline

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

jakob
Admin
From: Germany
Registered: 2005-01-20
Posts: 3,937
Website

Re: Improved Text Editor Capability

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.


TXP Builders – finely-crafted code, design and txp

Offline

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

NicolasGraph
Plugin Author
From: France
Registered: 2008-07-24
Posts: 860
Website

Re: Improved Text Editor Capability

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.


Nicolas
Follow me on Twitter and GitHub!
Multiple edits are usually to correct my frenglish…

Offline

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

Destry
Member
From: Haut-Rhin
Registered: 2004-08-04
Posts: 4,460
Website

Re: Improved Text Editor Capability

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.

Offline

Board footer

Powered by FluxBB