Accepted, Not Yet Planned

The idea of supporting a standardized data format for headless approaches aligns with our plans.

However, the core of the system, publishing, and the exposed APIs are based on an existing stack and standards (XML, XHTML, JSON, etc.).

In the latest versions of the Content Delivery APIs, implementers can further manipulate and transform responses over the GraphQL end-point.

This idea is marked as not planned, meaning it may still be a useful and interesting idea, but we don't have immediate plans to adopt a new field type based on mark-down. We may consider mark-down-like keyboard shortcuts if interesting to editors.

Feel free to comment or vote according to how you feel about markdown as a Content Manager-side storage format for rich text.

Add a markdown field

Adding a markdown field will make the lives of content editors and developers much easier imho.

Markdown also allows for custom plugins. Which delivers a specialized way of handling content in markdown fields.

A markdown field could show live preview of how the content could look like using a js parser (Also XPM ;)). 

Parents
  • Markdown is desperately needed as an alternative to RTF. I would store RTF as a multiline text field and use a string datatype instead of XML such as with the RTF.

    The reason Markdown is so important is because multi-channel implementations should not have a content model with HTML in the field values since HTML is specific to the website channel only and isn't easily rendered in other channels such as a native mobile app.

    Markdown as a string can be parsed and converted to HTML for the website channel or XAML for the native mobile app channel for example.

    Could easily be built as a GUI extension on multiline text Fields as an alternative to extending the core field types.

Comment
  • Markdown is desperately needed as an alternative to RTF. I would store RTF as a multiline text field and use a string datatype instead of XML such as with the RTF.

    The reason Markdown is so important is because multi-channel implementations should not have a content model with HTML in the field values since HTML is specific to the website channel only and isn't easily rendered in other channels such as a native mobile app.

    Markdown as a string can be parsed and converted to HTML for the website channel or XAML for the native mobile app channel for example.

    Could easily be built as a GUI extension on multiline text Fields as an alternative to extending the core field types.

Children
No Data