[Feature] Use FMTTYPE to flag if description contains markdown codes

[rogercreagh]

Earlier on there was a discussion about allowing/defaulting markdown codes in descriptions. Also the possible use of STYLED-DESCRIPTION ( rfc9073 ) to allow HTML versions.

Here is a simple non-breaking enhancement to flag the presence of markdown codes in the description text.
If markdown codes are present at a FMTTYPE=text/markdown parameter to the description.

eg DESCRIPTION;FMTTYPE=text/markdown:This is your description text

This shouldn't break any existing applications out there, but would allow me to tell when loading an entry from the server to determine whether to show a markdown editor or a plain text one for the description, and whether to bother to parse the description for markdown codes when displaying it (less of an issue since it is easy enough to always parse for markdown)
And correspondingly it would allow jtxBoard to be able to parse markdown and show the markdown editor according to the content fmttype rather than relying on a global setting.

I'm pretty sure that other applications will simply ignore, but preserve, the format type parameter if they don't know what to do with it (that's how I read the spec, but I could be wrong)

[patrickunterwegs]

But how would the app determine whether there is markdown text or not?
Jest because markdown is enabled doesn't mean that there's markdown text and the other way round...

[rogercreagh]

With a new item if the markdown editor is in use (app setting) then set FMTTYPE=text/markdown, otherwise don't

• Subsequent display on any app respecting the format type parameter uses it to parse markdown or not
• Subsequent display on any app not respecting the fmttype parameter displays as plain text
• Subsequent editing using an app which respects the fmttype parameter uses the appropriate editor but may allow the user to toggle the editor. When the edit is saved (or autosaved) the FMTTYPE is updated to reflect the current status
• Subsequent editing on an app that doesn't respect or recognise the parameter will edit as plain text and not change the parameter when saving. So markdown text on that app would be edited as plain text but the original app would still recognise it as markdown

Of course an app might be created to always assume markdown in which case it should always set FMTTYPE=text/markdown

Perhaps we should go one step further and also use FMTTYPE=text/plain rather than omitting the fmttype. This would allow an item to be explicitly locked to plain text unless the user changed it while editing - either by changing an app setting or by some other mechanism - I'd quite like the setting to only apply to the current item, which using fmttype would allow.

[patrickunterwegs]

Personally I frequently use the options to switch between plain text and markdown formatted text, depending on the context and what is faster for editing. I want to keep this idea.
The idea of adding markdown was to allow a minimum of formatting options that wouldn't break the standard and ensures compatibility with other apps.

I don't see the need and the use of that additional field. Either it would restrict the user to stick to the initial setting after saving once, or it would give the user the full flexibility, but then we would end up in the same situation as now, just that there might be an FMTTYPE that in reality doesn't say anything about the content as again it could just be plain text without tags or text with tags shown as plain text.

But we can keep this in the discussions.

[rogercreagh]

Personally I frequently use the options to switch between plain text and markdown formatted text, depending on the context and what is faster for editing. I want to keep this idea.

I don't have a problem with that - I'd still want the ability to switch, but I'd like it to have a current mode (markdown/plain) stored with the item rather than as a more global setting. I often find that I've switched to plain text for a particular item and then I open an item with markdown embedded and I have to switch back to markdown.

I suppose since you have not got a wysiwg editor in jtx for markdown you are more used to it. My everyday markdown editor is Typora which is brilliant because it is wysiwyg.

It just seems to me that the encoding should be a property of the item and not of the application and FMTTYPE would allow that.

[rogercreagh]

just that there might be an FMTTYPE that in reality doesn't say anything about the content as again it could just be plain text without tags or text with tags shown as plain text.

Hang on a mo. That is like saying that you don't see the point of distinguishing between html and plain text. HTML is just plain text with some character combinations being recognised as formatting instructions <bold> rather than content < bold>. The same is true of markdown, just that markdown has no easy unambiguous way of stripping its tags so it is even more important to flag the intention of the creator.

The fact that you haven't got a wysiwg editor and you happen to be familiar with markdown codes doesn't mean that it is ok to create a situation where someone displaying your carefully crafted text using a different app has no way of knowing what you intended by all those hashes and dashes.

Its like going back to the early days of wordprocessing and it is just plain ugly to look at. FMTTYPE absolutely does say something about the content - it says how it is to be formatted. That's the point.

[rogercreagh]

The idea of adding markdown was to allow a minimum of formatting options that wouldn't break the standard and ensures compatibility with other apps.

But it does break the standard which is plain text only unless a different format type is specified. Plain text means that it should be displayed exactly as the characters are written. Plain text does not mean that some bits of the ascii string should be interpreted as text and other bits as format instructions. Neither html nor markdown is plain text in this sense although they both only use ascii alphanumeric and punctuation characters.

It exactly doesn't ensure compatibility with other apps as they have no way of telling how to display the text.

[patrickunterwegs]

For now I don't want to focus further on formatting and content types for the description field. Users should be able to put whatever they want. I'd say if users need a notebook with good WYSIWYG editing capabilities, there's other apps that might do a great job with that. With jtx Board I want to focus on the structured approach with some basic formatting options that can be switched on or off.

I don't see a point in storing an information that the content is markdown-text when anyway I can switch markdown interpretation on and off (whereas I only might want to turn it off when I explicitely want to see the plaintext, otherwise for plaintext with markdown on it wouldn't make a difference in most cases). I see the current way as the much more user friendly way.

Additionally the FMTTYPE is mentioned for the STYLED-DESCRIPTION field, but not for the DESCRIPTION field. I didn't see any clear hint that the FMTTYPE parameter is also suggested for the DESCRIPTION.

[rogercreagh]

I can see that we're going to have to agree to differ on this one.

A final point: DESCRPITION property does allow

  ; and MAY occur more than once.
  ;
  (";" other-param)
  ;
 )

and FMTTYPE is a registered IANA param so is allowed. Aplications can ignore it but must preserve it and the value.

So you could simply add a ;FMTTYPE=text/markdown: always to your DESCRIPTION property and ignore it for now. It wouldn't matter if another app displayed your text without markdown using a markdown formatter and jtxB would still operate the same.

As a second step you could then read the parameter when getting a component and use it to set markdown display and editing on and off, still allowing your user to locally change the your setting.

As a third step you could then change the parameter value as appropriate when saving the item
Thus with a simple step one youcould have your cake and I could eat it. Without steps two and three jtxB would not be respecting the value I sync'd back to it, simply assuming that my plain text was markdown, but at least myJoomla component, and Nextcloud native VJournal app (starting work on it now), and a planned linux desktop VJournal app would play nicely together...

Step 1 please - it should be easy

[patrickunterwegs]

Hey @rogercreagh ,
I really would like to support your ideas, but in this case I really see more disadvantages than advantages:

• Yes, the DESCRIPTION field does allow other params, but the FMTTYPE is not clearly defined there, so other application developers wouldn't naturally use it unless they follow the discussion or another implementation that did it like that
• As users can paste anything in the description field, it would just be wrong add the FMTTYPE when it cannot be ensured that it the content is of this type, so it's better to leave it undefined
• If the entry has its origins in another app, it is not clear what jtx Board would do in such a case. Add the FMTTYPE anyway when the description is changed? That would also be wrong.
• Now it's a clear user choice if the text should be formatted based on markdown tags or not. When there is an FMTTYPE defined according to your idea the user choice gets overwritten. This would be confusing for the user and this is also something that I personall don't want.
• In my actual work (I mean the one I can actually live of) I have to use tools like Jira where the behavior is the same: I can switch between visual editing or text editing. This setting is just saved and when I edit again, the previous editing mode opens again. And also there I could just use text editing all the time without any markdown tags. It's a behavior that I like and it makes sense to me.

So yes, the change would be minimal, but it opens up problems and goes towards a direction I don't want to go anyway...

[rogercreagh]

Ok